Received: by 2002:a05:7412:e794:b0:fa:551:50a7 with SMTP id o20csp1723112rdd; Thu, 11 Jan 2024 07:30:01 -0800 (PST) X-Google-Smtp-Source: AGHT+IGL4bc9XACdJKLMLsrRNvt3SSBsjmXUm6HlztXI4Sbrj7MJqoWzn25Oms9/HBpSp6F5YpJr X-Received: by 2002:a05:6359:5a2:b0:173:227:39bb with SMTP id ee34-20020a05635905a200b00173022739bbmr19995rwb.0.1704987001608; Thu, 11 Jan 2024 07:30:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704987001; cv=none; d=google.com; s=arc-20160816; b=MFw8PnSjPJeo0j/+Pglh/CTfvIuBaxhReQat1nfrRB9zVRybD3Ly7Ma/SeulFLisv3 ULYfGVD8xL+b8JjY3+qzFFMOBiowu62PgMp0Z1cOeUnnwrZjL6xEhT6sqc521jIt35Nz Th970mEbPueE71gGjE8ApHxJ7YCpYIvY7qQi06jkziA3tU0E/5ytyISij4blQOrsZ3GE 0hyZMLXPMtKfbwl5O6tOQbtvOv5bZ9NhY+quD8+wkVU8MoA7XriF/CRMo39NUe2F7Lxq MPbu3hKNrsG0rV4te2vMxfUxZdFZ9I3w7h+02GlEJsYDgqhMhj1y529TFimI1Ul34FWa H+1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=MtoT52YTrH42ch7YxYaEjtOEITM9BuzH9xQRvt2UX1c=; fh=JIA10jp39eFUNsQEjaVGVUL7ghGa7AhWcb9kUGYDEi4=; b=ZXDaXLDzS6dTdO9AR8FLSZYD4IYHWgi6q44LKb5k7Bi7aFVQwRycOFt68hI6uaUTo6 RbRNN4ak005PRyKKooIcqW4hm6/FKnqoyyiFEnl9x5+i1MFcMyk+sGbTPzCoFr+G1l7q UlQTrL4wFKSKv2eayzc/Al95JZxLz4iEAtm1Tuv5TxeZu3pxVYeNfugcrJhNvAJA/RFX 98Dv7Jxyr/lZWxywVgfxuS1YgNGrpK7retU84cY3rkRSVO5RsiaSaOLPtC9eytTDVKdk KZDEhOd7UE0X0Nbgg80zkgNqvxp1hP7o4N4CJT7Ov1X5cmxsU9UWJJKQmImeExIdnqtM +gkQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-23770-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23770-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id r144-20020a632b96000000b005cdfe3e662asi1291487pgr.825.2024.01.11.07.30.01 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Jan 2024 07:30:01 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-23770-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-23770-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-23770-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 7CC5828C930 for ; Thu, 11 Jan 2024 15:10:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6A7A44CB3C; Thu, 11 Jan 2024 15:10:19 +0000 (UTC) Received: from exchange.fintech.ru (exchange.fintech.ru [195.54.195.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E1F822074; Thu, 11 Jan 2024 15:10:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=fintech.ru Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fintech.ru Received: from Ex16-01.fintech.ru (10.0.10.18) by exchange.fintech.ru (195.54.195.159) with Microsoft SMTP Server (TLS) id 14.3.498.0; Thu, 11 Jan 2024 18:10:11 +0300 Received: from [192.168.211.130] (10.0.253.138) by Ex16-01.fintech.ru (10.0.10.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 11 Jan 2024 18:10:10 +0300 Message-ID: Date: Thu, 11 Jan 2024 07:10:10 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] media: em28xx: return error on media_device_register() failure To: Mauro Carvalho Chehab CC: , References: <20240110173958.4544-1-n.zhandarovich@fintech.ru> <20240111074905.67d61b00@coco.lan> Content-Language: en-US From: Nikita Zhandarovich In-Reply-To: <20240111074905.67d61b00@coco.lan> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: Ex16-02.fintech.ru (10.0.10.19) To Ex16-01.fintech.ru (10.0.10.18) On 1/10/24 22:49, Mauro Carvalho Chehab wrote: > Em Wed, 10 Jan 2024 09:39:58 -0800 > Nikita Zhandarovich escreveu: > >> In an unlikely case of failure in media_device_register(), release >> resources and return the erroneous value. Otherwise, possible issues >> with registering the device will continue to be ignored. >> >> Found by Linux Verification Center (linuxtesting.org) with static >> analysis tool SVACE. >> >> Fixes: 37ecc7b1278f ("[media] em28xx: add media controller support") >> Signed-off-by: Nikita Zhandarovich >> --- >> drivers/media/usb/em28xx/em28xx-cards.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c >> index 4d037c92af7c..dae731dfc569 100644 >> --- a/drivers/media/usb/em28xx/em28xx-cards.c >> +++ b/drivers/media/usb/em28xx/em28xx-cards.c >> @@ -4095,6 +4095,8 @@ static int em28xx_usb_probe(struct usb_interface *intf, >> */ >> #ifdef CONFIG_MEDIA_CONTROLLER >> retval = media_device_register(dev->media_dev); >> + if (retval) >> + goto err_free; > > Not freeing resources here is intentional. See, the media controller > API is optional on this driver. It will just provide a way to identify > the device's topology, but the device is completely usable without > it. > > Perhaps we need, instead, a patch documenting it, and preventing > static analysis tools to point it as an issue. > > Thanks, > Mauro Thank you for your feedback, however I had a few questions... While I understand what you mean about optional nature of media controller registration in this case, a quick glance into other calls to media_device_register() across the source code shows that usually failure with registering is handled as a proper error regardless of whether the device is still usable. But if you think that we can make an exception here, I'll happily oblige. Then if I am to continue on this path, would the following comment above the call to media_device_register() suffice? #ifdef CONFIG_MEDIA_CONTROLLER + /* + * No need to check the return value, the device will still be + * usable without media controller API. + */ retval = media_device_register(dev->media_dev); Thanks, Nikita