Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp631414ybk; Wed, 20 May 2020 08:09:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3nZASwUCgclbkX126Eub46v8129+XoQHIn2aGM/XoDdG2IBmxm9P39M0GHSAXo6CspJtg X-Received: by 2002:a17:906:f06:: with SMTP id z6mr2252922eji.105.1589987344951; Wed, 20 May 2020 08:09:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589987344; cv=none; d=google.com; s=arc-20160816; b=ZTvmHM+Gt7vCErN8IRwG+A6ZRVWUU4pj5TqDfM8iBa983M4ppLTfU7rlsfYmM3DL4L dl5+PnHtiZeEgEAUYKNT838fBt6j1FHJPDTcG5KY2mgYW4nDdsZArQcB4fZGH3Cr+a3J p16htcGXewLXuakVQ5Y9ULQsb0UZJSmIGhw5R8TwI4WqTlZZnHozSaqE4S6KfUJGm4Vw omghRsfyHpfei3SvEruRftkpTQihLYlpvZ+6Mk+V2+TGXIEx9LTKiHp6de5QRBxQYCeL 8nm/a6etawO+JdoePTxW6CMjOBtjuArKH4xA21sJ0mqKpZC2OBAb2FOJL0M+CJ2qM9aU wcyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=+gDCGjMZWEdVRUtQZYVp+UsS6eran4MdaLZDqVTRgpg=; b=Y5y/zCGJdaw992UXHixF4z4cLtY+oi/3MH6LWjZd+FsZuTfTttPX1W5ClPcXDjRbJc 1iByqAWFYO+4LwV0Ooicdfof66wGO/vY2K/lmwjlIBe7NPz+XshWkEbURLBRx4C2bfaX 4MFMq8RZDBTKFIyaK1Y8hzJR93rQyiO9k35GbgwzVkisVC9Jyp3FxTWWeL1uXMkUYoX8 3Q9Q9WyDsx52UrUd9Qp+eqJhE2xpbpZjU0dvnB7QSDvy5KPUk+08igEgC1VIEaeueKqb +ww9nArjN2E0YdD6/N2fVaTUhHncYXHZwaTmSZqY2ACD7JIyGi45JO5gzsuXKQYKKBQi kvVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=G0+brP9d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t6si1826169ejs.212.2020.05.20.08.08.42; Wed, 20 May 2020 08:09:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=G0+brP9d; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726775AbgETPGv (ORCPT + 99 others); Wed, 20 May 2020 11:06:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33844 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726486AbgETPGu (ORCPT ); Wed, 20 May 2020 11:06:50 -0400 Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8FA21C061A0E for ; Wed, 20 May 2020 08:06:50 -0700 (PDT) Received: by mail-ua1-x944.google.com with SMTP id a37so1385395uad.0 for ; Wed, 20 May 2020 08:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+gDCGjMZWEdVRUtQZYVp+UsS6eran4MdaLZDqVTRgpg=; b=G0+brP9dlZpegWEIl+cnjiVVn5DswkuPLM+7RKlGLuvwQ7VXzZwOVqSjLeLkymu8K3 tfV/Kao2rLHgzpU+kGExrnVNJPZGH06uyjiJH9y6H7/aSp1gDdqSLfAvmlC6G/qTZoxX ZSkWO9v3aq0UpE1hbsxaNaKRNopKOBX7u/Ik2oTzjQh8E3CutJ/LBKG/xvz2rrbpd2Fy FAg6A8sbESNl0Tu3Y68cN1WOB0Mq0yF44znLqivgb7q759oGOB7aZ5HP5Lynzfc5oACP nQRYXLnAGy9aa0waFP0AvnwPPKaKPl4+gybhMVBgvsFpODjx6bsku1f8kJMpDUxtvWpd xMnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+gDCGjMZWEdVRUtQZYVp+UsS6eran4MdaLZDqVTRgpg=; b=sbIMlGUBoRYqkPVHDbk75AyFqdNHdWhnPYkGaCjmv+Mg6RqhEO5cmDb3sOyB4RZdzd F7STXtNRL8QCc3TGrJuvcw9ZJEWJ2HWWJg3+0+rwV0Wysous7OI91AQp4W/bOdwW5FfD 3PuJ/nEXUGqIJ+qyNK/pEFXlzkGg6yOPpU+wdTZBotSFDDgc7GQss2W8r6Rxhi2MyRLA 6eQJi9wCSBgul0AH6VKo6O5RHlGmbR++svUSihlAu5NdT3I1zrk4bXXK3EzmFZFo5VDa mCMsTg7WhME6zpgrUoH9sGjeL4dOyISoK1CBYQD7oY0CrIrfTNHLqkWVo5aReWDX9oAt 0jAQ== X-Gm-Message-State: AOAM531uk7/qIPZgkRiezj7nt0ZCogIM3XBwIny73UaMOrBh3GbpbNWn kr2iIfSu7DtKZ8JgQb8RTxVAc6Qii6Mgk5FW7fI4Fw== X-Received: by 2002:a9f:37c3:: with SMTP id q61mr4034114uaq.100.1589987209658; Wed, 20 May 2020 08:06:49 -0700 (PDT) MIME-Version: 1.0 References: <20200520131558.23009-1-tomi.valkeinen@ti.com> In-Reply-To: <20200520131558.23009-1-tomi.valkeinen@ti.com> From: Ulf Hansson Date: Wed, 20 May 2020 17:06:12 +0200 Message-ID: Subject: Re: [PATCH] media: videobuf2-dma-contig: fix bad kfree in vb2_dma_contig_clear_max_seg_size To: Tomi Valkeinen Cc: Linux Media Mailing List , Mauro Carvalho Chehab , Marek Szyprowski , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 May 2020 at 15:16, Tomi Valkeinen 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(). Not entirely true I believe, see more below. > > 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 > --- > > Note: I have only fully tested this on linux-next, as the capture driver > I use doesn't support unloading modules in v5.7. > > drivers/media/common/videobuf2/videobuf2-dma-contig.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > index d3a3ee5b597b..24f80b62ef94 100644 > --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c > +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c > @@ -726,9 +726,8 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops); > int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size) > { > if (!dev->dma_parms) { > - dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL); > - if (!dev->dma_parms) > - return -ENOMEM; > + dev_err(dev, "Failed to set max_seg_size: dma_parms is NULL\n"); > + return -ENODEV; > } > if (dma_get_max_seg_size(dev) < size) > return dma_set_max_seg_size(dev, size); > @@ -747,8 +746,6 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size); > */ > void vb2_dma_contig_clear_max_seg_size(struct device *dev) > { > - kfree(dev->dma_parms); > - dev->dma_parms = NULL; > } > EXPORT_SYMBOL_GPL(vb2_dma_contig_clear_max_seg_size); I think you need something along the lines of this as well: diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 5c2a23b953a4..7acf2a03812d 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -1070,6 +1070,7 @@ static const struct v4l2_file_operations s5p_mfc_fops = { /* DMA memory related helper functions */ static void s5p_mfc_memdev_release(struct device *dev) { + kfree(dev->dma_parms); of_reserved_mem_device_release(dev); } @@ -1090,6 +1091,10 @@ static struct device *s5p_mfc_alloc_memdev(struct device *dev, child->dma_mask = dev->dma_mask; child->release = s5p_mfc_memdev_release; + child->dma_parms = kzalloc(sizeof(*child->dma_parms), GFP_KERNEL); + if (!child->dma_parms) + goto err; + /* * The memdevs are not proper OF platform devices, so in order for them * to be treated as valid DMA masters we need a bit of a hack to force @@ -1105,6 +1110,7 @@ static struct device *s5p_mfc_alloc_memdev(struct device *dev, device_del(child); } +err: put_device(child); return NULL; } Also, please tag the patch for stable. Kind regards Uffe