Message ID | 20240110173958.4544-1-n.zhandarovich@fintech.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-22545-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2411:b0:101:2151:f287 with SMTP id m17csp947694dyi; Wed, 10 Jan 2024 09:42:37 -0800 (PST) X-Google-Smtp-Source: AGHT+IFWWTAoqM5bUy8D6O6w9JaJ3D3qx+HxvLpuvcfI9q70dEahUZ4PA38vodg29Su89n+Bt6xo X-Received: by 2002:a05:6a20:3ca4:b0:19a:3d26:d40f with SMTP id b36-20020a056a203ca400b0019a3d26d40fmr413180pzj.39.1704908557366; Wed, 10 Jan 2024 09:42:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704908557; cv=none; d=google.com; s=arc-20160816; b=VbXJZ4r++3ooK/vQE0OHwaOb3HagZQ12K5WydU3BXhzsioFsZRe2k6QAKG9VNwomdQ 0AEFDw/llXwYtwAiMSXCm1dUmnRC4rijBZMRl6AII+klvDV4/k1xe9Yg1hMw7Wromi6d FavSdbIv/7V9I7AUDbFRakhYlu9fNUgdGPRKIMSF5NmsyKcXFF0/w+vIXG23qsJFuspr Hvhxnxx/tcl6T6gJ3EdHAfWg6WYbbgSOJkUHm803w6SfNdmolufrXgX+OoIK44lAdQcw CwvzAFj0oEoNaAa5y2swdRyegMTvIK2lT2rmrC6M9IutxjuR3ITVNnQ/A3nf+aBfjQxs +E4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=bLcVR4b30t9K1TjNYadhvfqgYQnB+VOQ5Ntb5Vmzx9w=; fh=mR1j1IVvHEi0jEbdfH0z4VX8hw4ltuoo5vh+ql7sokg=; b=kRobAVCvrPWKu/yf+mWRS20NqHMiPlNwTa/timsDb0LD4RDAFKbOCYupVeqMEvBDgq IWZ/4ilzte4txCGId93YIRsqczCritpSrlrLH31WQdaE5Q82+P/DIHFlakx436J/8lot eVdo+YuYCoWsG5zlwWxx3FMS1TtkD0ulU91AfXY3oRr6yvt40hpKUpA+wLeY8iwYd09w dj6gZxjUQ1CcOZXFG5EsCrtbOP/kemCU2xci/XuwYW0D4MM1VyYrzaBWgRTVMmBMDToI z+gOMrrl8V/nlA2kBhnqD5PyXCDWWuBrWHDFI8ChDfzU6SeLmuayJcZqYAO0BlpiYE0U 7jHw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-22545-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22545-ouuuleilei=gmail.com@vger.kernel.org" Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [2604:1380:40f1:3f00::1]) by mx.google.com with ESMTPS id fm2-20020a056a002f8200b006d9e3783cf4si4090744pfb.52.2024.01.10.09.42.37 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jan 2024 09:42:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-22545-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-22545-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-22545-ouuuleilei=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 sy.mirrors.kernel.org (Postfix) with ESMTPS id 82029B2587C for <ouuuleilei@gmail.com>; Wed, 10 Jan 2024 17:42:17 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9A46F4D13D; Wed, 10 Jan 2024 17:41:50 +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 56FF24D102; Wed, 10 Jan 2024 17:41:43 +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; Wed, 10 Jan 2024 20:40:06 +0300 Received: from localhost (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; Wed, 10 Jan 2024 20:40:06 +0300 From: Nikita Zhandarovich <n.zhandarovich@fintech.ru> To: Mauro Carvalho Chehab <mchehab@kernel.org> CC: Nikita Zhandarovich <n.zhandarovich@fintech.ru>, <linux-media@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] media: em28xx: return error on media_device_register() failure Date: Wed, 10 Jan 2024 09:39:58 -0800 Message-ID: <20240110173958.4544-1-n.zhandarovich@fintech.ru> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: Ex16-02.fintech.ru (10.0.10.19) To Ex16-01.fintech.ru (10.0.10.18) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787726195738037369 X-GMAIL-MSGID: 1787726195738037369 |
Series |
media: em28xx: return error on media_device_register() failure
|
|
Commit Message
Nikita Zhandarovich
Jan. 10, 2024, 5:39 p.m. UTC
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 <n.zhandarovich@fintech.ru>
---
drivers/media/usb/em28xx/em28xx-cards.c | 2 ++
1 file changed, 2 insertions(+)
Comments
Le 10/01/2024 à 18:39, Nikita Zhandarovich a écrit : > 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 <n.zhandarovich@fintech.ru> > --- > 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; > #endif > > return 0; > > Hi, I think that some resources allocated in em28xx_init_dev() should also be freed if media_device_register() fails. (see the error handling path at the end of em28xx_init_dev()) Just my 2c. CJ
Em Wed, 10 Jan 2024 09:39:58 -0800 Nikita Zhandarovich <n.zhandarovich@fintech.ru> 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 <n.zhandarovich@fintech.ru> > --- > 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
On 1/10/24 22:49, Mauro Carvalho Chehab wrote: > Em Wed, 10 Jan 2024 09:39:58 -0800 > Nikita Zhandarovich <n.zhandarovich@fintech.ru> 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 <n.zhandarovich@fintech.ru> >> --- >> 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
Em Thu, 11 Jan 2024 07:10:10 -0800 Nikita Zhandarovich <n.zhandarovich@fintech.ru> escreveu: > On 1/10/24 22:49, Mauro Carvalho Chehab wrote: > > Em Wed, 10 Jan 2024 09:39:58 -0800 > > Nikita Zhandarovich <n.zhandarovich@fintech.ru> 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 <n.zhandarovich@fintech.ru> > >> --- > >> 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. It depends on how the actual device is controlled. "Normal" media devices are fully controlled via v4l2 API. On those, the media controller API is there just to let userspace to query about the internal settings, but the actual pipelines are created via V4L2 API. Almost all normal applications will just ignore the media controller API. Embedded hardware, however, require setting pipelines via media controller for they to actually work. Almost all drivers implementing the media controller API fall on this category. > > 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); That works for me. It would still produce alerts at static analyzers, as they'll notice that we're storing retval there without actually using it. Thanks, Mauro
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; #endif return 0;