From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MALFORMED_FREEMAIL, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14165C32751 for ; Wed, 31 Jul 2019 21:32:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E03D0206B8 for ; Wed, 31 Jul 2019 21:32:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="YNHkNtgB" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729853AbfGaVcw (ORCPT ); Wed, 31 Jul 2019 17:32:52 -0400 Received: from mail-pl1-f194.google.com ([209.85.214.194]:39262 "EHLO mail-pl1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726125AbfGaVcw (ORCPT ); Wed, 31 Jul 2019 17:32:52 -0400 Received: by mail-pl1-f194.google.com with SMTP id b7so31089209pls.6; Wed, 31 Jul 2019 14:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=N9gPxJSS+drGx3gkBDyyqIUQ628VPY96K/YYURGM20I=; b=YNHkNtgBwrh6nbpMkE8s3S3DSkUREUY/zJ2lSMLIGS/mcdDXEu61HGn0u5lfYe3SdE 6Go5On1veg0XK8WJi7hoYXZsPxNh6JX/ZFzk1LCQZezGU+hn7E8ciqMiM9d7WnhBcwQj nDiRLpMV4Zq/V35AdaeT1sCJXmtALheS2q/h34dZDk1FD0d4udGXjbhjiVXFkebOUkwp tC/WiopiafnP5mBCYfGZRFa6iihOMplq97v1Opz9zqHRdPf67wWlmGbpxJxtNgt7Te6H GmKh7Hrtxj49Gps3mFuGfssRxNEXAT2EnQFktBFA4a51QQRptYLap9SIcJAHb3vhMmkb WHhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=N9gPxJSS+drGx3gkBDyyqIUQ628VPY96K/YYURGM20I=; b=XBc3O3OuayndMfKq5gw+uarNizVhl3NSbYQ7w/sJuCnzJgv9JAOtKyHcdyNXN17hUQ opaxwjTkHYw+/1mPxTuwq5LNRC3z22IfCCtkO0DBuohV6yCue4NNR9ozenOd7YT4xoyI qromiBcEnEJPp/aVlVO0ls0oBgAbuFJCFpa3RpJU51MDUKF3amUMGefcWPGfYsRpE4Ke ObeKXjdorMRCkhDvtjefK1IQOkMSFEwHs+ZPS4R2lo/ObZMM1mpS1nlMgNSRBlyTG78h 3az5yw/GHZ2qD0hyR576MTvws+r9cNiqcJ9hQ57dANT+vLlFz2eLD6wEc2iKinaJasOi QN/A== X-Gm-Message-State: APjAAAUrKYtNfp3gzm5FU1GmjYh5tIs00EW/7NXnau2D2J+NFUHivT2R CAn+e+UC02v2JNtxP9bfPSpp/J0XgBY= X-Google-Smtp-Source: APXvYqwtPtb7EptjDKSGnhnZQetheDAKXUj8SLRER2Ll27IMu2RKc7zxzE2dlBUODNwFvzF3lXVDfA== X-Received: by 2002:a17:902:6b85:: with SMTP id p5mr118280098plk.225.1564608771566; Wed, 31 Jul 2019 14:32:51 -0700 (PDT) Received: from [192.168.1.4] (d206-116-172-62.bchsia.telus.net. [206.116.172.62]) by smtp.gmail.com with ESMTPSA id i7sm2309345pjk.24.2019.07.31.14.32.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jul 2019 14:32:50 -0700 (PDT) From: Mark Balantzyan X-Google-Original-From: Mark Balantzyan Date: Wed, 31 Jul 2019 14:32:46 -0700 (PDT) To: Hans Verkuil cc: Mark Balantzyan , ezequiel@vanguardiasur.com.ar, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] media input infrastructure:tw686x: Fix of possibleinconsistent memory deallocation and/or race condition by implementation of custom video_device_release function in tw686x driver In-Reply-To: <40d14e23-636e-ed8a-6608-99427f5b8169@xs4all.nl> Message-ID: References: <40d14e23-636e-ed8a-6608-99427f5b8169@xs4all.nl> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Hi Hans, all, Sorry for the poor patching, I am a student and as you may tell still new to this system. At the time of the patching, I wasn't fully informed of all the requirements that go into such things, and am still learning. Would it be alright if I submit a report instead? In order to, I am (still, sorry) trying to understand the issue at hand. How in fact may the release() callback be overridden (by a tw686x-specific function) to free the dma memory and call video_device_release()? To my understanding at the time, this was merely a re-implementation of video_device_release with said requirements and subtraction of extra features from tw686x_video_free().. This release() callback is called by the V4L2 framework when the last user of the device closes its filehandle, so that's a good point to free all the memory. Doing it earlier (as the current code does) runs the risk that someone might still access that memory, and you don't want that. Yes, I definitely don't want that. :) Thank you, Mark