[PATCH] media input infrastructure:tw686x: Fix of possible inconsistent memory deallocation and/or race condition by implementation of custom video_device_release function in tw686x driver

Possible inconsistent memory deallocation and/or race conditions were detected specifically with respect to remaining open handles to the video device handled by the tw686x driver. This patch addresses this by implementing a revised independent instance of the video_device_release function

tw686x driver (again, sorry; I respect it as a good driver!)

Hi Hans, I recall us agreeing that a custom function to free the last resources attached to the video device would be preferable. So may I clarify, in your words, what bug I may be fixing? I please need a description to report to patchwork and to my mentor.. Also I’m getting confused reactio

Re: [PATCH] media input infrastructure:tw686x: Added custom function for video device release functionality in tw686x driver

Hi Mark, On Fri, 26 Jul 2019 at 17:41, Mark Balantzyan wrote: > > Signed-off-by: Mark Balantzyan > Reported-by: kbuild test robot > --- > This patch adds a custom function for releasing the video device for the > tw686x video device driver. > > drivers/media/pci/tw686x/tw686x-video.c | 23 +++

Re: tw686x driver (continued)

Hi Mark, On Wed, 24 Jul 2019 at 09:25, Mark Balançian wrote: > > Hi Ezequiel, > > (sorry didn't include linux-media in first email) > I'm not sure yet if I have my supervisor's permission to declare our > tool as open source, but I'll tell you the possible code paths that I > think may be leading

Re: tw686x driver (continued)

Hi Hans, On Wed, 24 Jul 2019 at 10:08, Hans Verkuil wrote: > > On 7/24/19 2:25 PM, Mark Balançian wrote: > > Hi Ezequiel, > > > > (sorry didn't include linux-media in first email) > > I'm not sure yet if I have my supervisor's permission to declare our > > tool as open source, but I'll tell you t

[PATCH] media input infrastructure:tw686x: Added custom function for video device release functionality in tw686x driver

Signed-off-by: Mark Balantzyan Reported-by: kbuild test robot --- This patch adds a custom function for releasing the video device for the tw686x video device driver. drivers/media/pci/tw686x/tw686x-video.c | 23 ++- 1 file changed, 18 insertions(+), 5 deletions(-) diff --

[PATCH] Added custom function for video device release functionality in tw686x driver

Signed-off-by: Mark Balantzyan Reported-by: kbuild test robot --- This patch adds a custom function in tw686x-video.c to provide a release mechanism for the driver for the tw686x video device. drivers/media/pci/tw686x/tw686x-video.c | 23 ++- 1 file changed, 18 insertions(+

Re: [PATCH] media input infrastructure:tw686x: Added Added custom function to set vdev->release in tw686x driver

/linux/commits/Mark-Balantzyan/media-input-infrastructure-tw686x-Added-Added-custom-function-to-set-vdev-release-in-tw686x-driver/20190727-005525 base: git://linuxtv.org/media_tree.git master config: mips-allmodconfig (attached as .config) compiler: mips-linux-gcc (GCC) 7.4.0 reproduce: wget

Re: [PATCH] media input infrastructure:tw686x: Added Added custom function to set vdev->release in tw686x driver

971f52ee8453346 Mon Sep 17 00:00:00 2001 From: Mark Balantzyan Date: Wed, 24 Jul 2019 14:01:30 -0700 Subject: [PATCH] media input infrastructure:tw686x: Added custom function to provide dev->dma_ops->free for vdev->release in tw686x_video_init() in tw686x driver ---  drivers/media/pc

Re: [PATCH] media input infrastructure:tw686x: Added Added custom function to set vdev->release in tw686x driver

Hi Mark, On Wed, 24 Jul 2019 at 12:10, Mark Balantzyan wrote: > This commit needs to be thoroughly explained in order to make sense. > Signed-off-by: Mark Balantzyan > --- > This patch adds a custom function to release video device in assignment to > vdev->release membe

[PATCH] media input infrastructure:tw686x: Added Added custom function to set vdev->release in tw686x driver

Signed-off-by: Mark Balantzyan --- This patch adds a custom function to release video device in assignment to vdev->release member in tw686x driver. drivers/media/pci/tw686x/tw686x-video.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/me

Re: tw686x driver (continued)

On 7/24/19 3:31 PM, Mark Balançian wrote: > On Jul 24, 2019, at 6:08 AM, Hans Verkuil > wrote: >> >> What tw686x_video_free() does really should be done in the release function >> of the video_device: vdev->release is currently set to video_device_release, >> but that sh

Re: tw686x driver (continued)

On 7/24/19 2:25 PM, Mark Balançian wrote: > Hi Ezequiel, > > (sorry didn't include linux-media in first email) > I'm not sure yet if I have my supervisor's permission to declare our > tool as open source, but I'll tell you the possible code paths that I > think may be leading our tool to think w

Re: tw686x driver (continued)

TBH though, I’m not sure about the tw686x_init going to the error: label though, so am curious as to your thoughts on this as well. It was just something I thought might be occurring due to the fact that the error trace in our tool ends in tw686x_memcpy_dma_free (i.e. dma_ops->free). Please se

Re: tw686x driver (continued)

Hi Ezequiel, (sorry didn't include linux-media in first email) I'm not sure yet if I have my supervisor's permission to declare our tool as open source, but I'll tell you the possible code paths that I think may be leading our tool to think what it's thinking. First off, it detects a write ac

Re: tw686x driver (continued)

ification team to detect race conditions in the kernel. Using our tool, we > detected a possible race condition with the tw686x driver. Can you describe how is this race condition possible ? E.g. what are the possible code paths and what would be the problem? Also, is the tool open source? > E

tw686x driver (continued)

the kernel. Using our tool, we detected a possible race condition with the tw686x driver. Even if there’s the slightest thing I’d like to please patch it as I really need this for my enrolled program. In any case, if interrupt handing isn’t given dedicated functions that are called before

Re: Question about TW686X driver

On Tue, 23 Jul 2019 at 12:02, Mark Balançian wrote: > > I see. I guess then my issue would be help in seeing how > tw686x_memcpy_dma_free alone does any required interrupt handling, since > there are also functions tw686x_irq and tw686x_audio_irq for interrupt > handling as well? However, in my

Re: Question about TW686X driver

Hey Mark, I'm glad you are having fun with the driver. On Tue, 23 Jul 2019 at 11:45, Mark Balançian wrote: > > Hello all, > > My name is Mark and I am working on contributing to the open-source Linux > project. > > I would please like to know more about the TW686X d

Re: tw686x driver

On 03/10/2016 08:16 AM, Krzysztof Hałasa wrote: > Hans Verkuil writes: > >> Heck, if you prefer your driver can be added to staging first, then >> Ezequiel's >> driver commit can directly refer to the staging driver as being derived from >> it. > > Ok, I guess it's fair enough for me. Would yo

Re: tw686x driver

Hans Verkuil writes: > Heck, if you prefer your driver can be added to staging first, then Ezequiel's > driver commit can directly refer to the staging driver as being derived from > it. Ok, I guess it's fair enough for me. Would you like me to send a patch with paths changed to staging/? How

Re: tw686x driver

Hans Verkuil writes: > Sorry, I meant V4L2_FIELD_INTERLACED support. Very few applications support > FIELD_TOP/BOTTOM, let alone SEQ_BT. Well, that's doable, though not in SG mode. It still doesn't require memcpy() of uncompressed video. > I don't get it. Getting your driver in staging is much

Re: tw686x driver

On 03/04/2016 01:37 PM, Krzysztof Hałasa wrote: > Hans Verkuil writes: > >> I have two drivers with different feature sets. Only one can be active >> at a time. I have to make a choice which one I'll take and Ezequiel's >> version has functionality (audio, interlaced support) which matches best

Re: tw686x driver

Hans Verkuil writes: > I have two drivers with different feature sets. Only one can be active > at a time. I have to make a choice which one I'll take and Ezequiel's > version has functionality (audio, interlaced support) which matches best > with existing v4l applications and the typical use cas

Re: tw686x driver

On 03/04/2016 07:11 AM, Krzysztof Hałasa wrote: > Hans Verkuil writes: > >>> Staging is meant for completely different situation - for immature, >>> incomplete code. It has nothing to do with the case. >> >> It can be for anything that prevents it from being mainlined. It was (still >> is?) >> u

Re: tw686x driver

Hans Verkuil writes: >> Staging is meant for completely different situation - for immature, >> incomplete code. It has nothing to do with the case. > > It can be for anything that prevents it from being mainlined. It was (still > is?) > used for mature android drivers, for example. What is prev

Re: tw686x driver

On 03/03/16 15:22, Krzysztof Hałasa wrote: > Hans Verkuil writes: > >> There is no point whatsoever in committing a driver and then replacing it >> with another which has a different feature set. I'm not going to do >> that. > > Sure, that's why I haven't asked you to do it. > Now there is no an

Re: tw686x driver

Hans Verkuil writes: > There is no point whatsoever in committing a driver and then replacing it > with another which has a different feature set. I'm not going to do > that. Sure, that's why I haven't asked you to do it. Now there is no another driver, as Ezequiel stated - there is just one dri

Re: tw686x driver

On 03/03/16 13:41, Krzysztof Hałasa wrote: > Hans Verkuil writes: > >> When a driver is merged for the first time in the kernel it is always as >> a single change, i.e. you don't include the development history as that >> would pollute the kernel's history. > > We don't generally add new drivers

Re: tw686x driver

Hans Verkuil writes: > When a driver is merged for the first time in the kernel it is always as > a single change, i.e. you don't include the development history as that > would pollute the kernel's history. We don't generally add new drivers with long patch series, that's right. That's because

Re: tw686x driver

On 03/03/2016 07:51 AM, Krzysztof Hałasa wrote: > Hi Hans, > > Hans Verkuil writes: > >> So lessons learned: >> >> Krzysztof, next time don't wait many months before posting a new version >> fixing >> requested changes. > > Actually, this is not how it happened. > > On July 3, 2015 I posted t

Re: tw686x driver

Hi Hans, Hans Verkuil writes: > So lessons learned: > > Krzysztof, next time don't wait many months before posting a new version > fixing > requested changes. Actually, this is not how it happened. On July 3, 2015 I posted the original driver: http://www.spinics.net/lists/linux-media/msg91474