Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp4283767ybf; Wed, 4 Mar 2020 00:41:50 -0800 (PST) X-Google-Smtp-Source: ADFU+vuQDJqtgmUIl6w28AgtaWL+1zlNmdiPJmvGtfjC8RQXLy/DaogOBGNagneBKIEx3KbLsuLM X-Received: by 2002:a9d:7607:: with SMTP id k7mr1481458otl.205.1583311310218; Wed, 04 Mar 2020 00:41:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583311310; cv=none; d=google.com; s=arc-20160816; b=DZ1RVOyMNtvL0/8z+oNi/NX8KC4+P6f+L1wYb5ZR3XSGoMhdsw08GMSFRBDx3UHNyb lqFsMUnzuUw2Ron/WvJqokilf/o9Vc82mav7RtaKbipiZLIuojOCdX3h+7cEoKvdx+Kv 9l/cKX50r7xTq4R3MiOxQM4JpXUiNEGbiOdns9M73eavbjj0IhL7OAtPkeh8yQkghweA 17hw0V4MRoZrlTa9QCU72G2Y1e+anqdelnFG8hIyH+Xe72f0bxs3lwCkblmrKx0mk84Z guw/2jwZcERXnALpLbW1sOWYOlVrJ10NXfQZfxR2ICS9glL9nbiCb9BlYGyRiUaPdahv OKMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=Nor6UwICB71c/cHX1FmjRqlYHp+LS5fnin9yQh6uyuY=; b=kZsdoF/3/ldR1HHVMNo+rP5TiHwzY4lx8y+rCKAwZl3RdrSKceeNx5wkoW0T3UOkEJ XHMHwZ0lstTcUz42QSVg6VRfMGkb3058hcV1Ng4Yco3RCyOL9nlXgPReyLuuUQwXkyak N+6EO0IXXhpFy1roED+0N1g99wOVYrMFk7eW5M0o0iDo1OZG5TqlzGTc9gUXkdBLWdvP 2L+4t3WDwqG48COZQ3cXz2LZ+AWX242ZoEcEjJrxoaSakfwk+fav+6cjouFfcN2M7ciP SO/3BmrVk+ahPVgUMBlEKJl+bVJrhYgJ84i4dJAKhvBcIwdmvuF53p+i3mMfi+iyEDqg h9ww== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=qEwXCsIR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z14si730902oih.89.2020.03.04.00.41.38; Wed, 04 Mar 2020 00:41:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=qEwXCsIR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387640AbgCDIkH (ORCPT + 99 others); Wed, 4 Mar 2020 03:40:07 -0500 Received: from lelv0142.ext.ti.com ([198.47.23.249]:54714 "EHLO lelv0142.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387396AbgCDIkG (ORCPT ); Wed, 4 Mar 2020 03:40:06 -0500 Received: from lelv0265.itg.ti.com ([10.180.67.224]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 0248e52t078499; Wed, 4 Mar 2020 02:40:06 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1583311206; bh=Nor6UwICB71c/cHX1FmjRqlYHp+LS5fnin9yQh6uyuY=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=qEwXCsIRoB9KIBCIJRCBpDuRDH9Pez31eTXr8hdfpz3swDjdQLKEoKSai9UirTlMK ZYC0aBmA+ayMNoMrf4/xn3H2siDz5f1lsLuXXF24+sOcc5I3vzEIkL78l6oCvPw9Ql +sBdABj3x0gB38+mAcDd/RRbcEoFaY0jKWXoh8Vg= Received: from DLEE114.ent.ti.com (dlee114.ent.ti.com [157.170.170.25]) by lelv0265.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 0248e5ks078118 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 4 Mar 2020 02:40:05 -0600 Received: from DLEE108.ent.ti.com (157.170.170.38) by DLEE114.ent.ti.com (157.170.170.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3; Wed, 4 Mar 2020 02:40:05 -0600 Received: from localhost.localdomain (10.64.41.19) by DLEE108.ent.ti.com (157.170.170.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1847.3 via Frontend Transport; Wed, 4 Mar 2020 02:40:05 -0600 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by localhost.localdomain (8.15.2/8.15.2) with ESMTP id 0248e3F9058305; Wed, 4 Mar 2020 02:40:04 -0600 Subject: Re: [Patch] media: ti-vpe: cal: fix a kernel oops when unloading module To: Benoit Parrot , Hans Verkuil CC: , , , References: <20200303172629.21339-1-bparrot@ti.com> From: Tomi Valkeinen Message-ID: <4010c13f-6a32-f3c3-5b6d-62a4e3782c64@ti.com> Date: Wed, 4 Mar 2020 10:40:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <20200303172629.21339-1-bparrot@ti.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/03/2020 19:26, Benoit Parrot wrote: > After the switch to use v4l2_async_notifier_add_subdev() and > v4l2_async_notifier_cleanup(), unloading the ti_cal module would casue a > kernel oops. > > This was root cause to the fact that v4l2_async_notifier_cleanup() tries > to kfree the asd pointer passed into v4l2_async_notifier_add_subdev(). > > In our case the asd reference was from a statically allocated struct. > So in effect v4l2_async_notifier_cleanup() was trying to free a pointer > that was not kalloc. > > So here we switch to using a kzalloc struct instead of a static one. > > Fixes: d079f94c9046 ("media: platform: Switch to v4l2_async_notifier_add_subdev") > > Cc: stable@vger.kernel.org > Signed-off-by: Benoit Parrot > --- > drivers/media/platform/ti-vpe/cal.c | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/platform/ti-vpe/cal.c b/drivers/media/platform/ti-vpe/cal.c > index 6d4cbb8782ed..18fe2cb9dd17 100644 > --- a/drivers/media/platform/ti-vpe/cal.c > +++ b/drivers/media/platform/ti-vpe/cal.c > @@ -372,8 +372,6 @@ struct cal_ctx { > struct v4l2_subdev *sensor; > struct v4l2_fwnode_endpoint endpoint; > > - struct v4l2_async_subdev asd; > - > struct v4l2_fh fh; > struct cal_dev *dev; > struct cc_data *cc; > @@ -2032,7 +2030,6 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) > > parent = pdev->dev.of_node; > > - asd = &ctx->asd; > endpoint = &ctx->endpoint; > > ep_node = NULL; > @@ -2040,6 +2037,10 @@ static int of_cal_create_instance(struct cal_ctx *ctx, int inst) > sensor_node = NULL; > ret = -EINVAL; > > + asd = kzalloc(sizeof(*asd), GFP_KERNEL); > + if (!asd) > + goto cleanup_exit; > + > ctx_dbg(3, ctx, "Scanning Port node for csi2 port: %d\n", inst); > for (index = 0; index < CAL_NUM_CSI2_PORTS; index++) { > port = of_get_next_port(parent, port); > Thanks, this fixes the crash for me. It does look a bit odd that something is allocated with kzalloc, and then it's freed somewhere inside v4l2_async_notifier_cleanup, though. But if that's how it supposed to be used, looks fine to me. Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki