Linux kernel staging patches
 help / color / mirror / Atom feed
From: Alex Elder <elder@ieee.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rui Miguel Silva <rui.silva@linaro.org>,
	greybus-dev@lists.linaro.org,
	Mikhail Lobanov <m.lobanov@rosalinux.ru>,
	linux-staging@lists.linux.dev,
	Rui Miguel Silva <rmfrfs@gmail.com>
Subject: Re: [PATCH] greybus: lights: check return of get_channel_from_mode
Date: Mon, 25 Mar 2024 13:55:36 -0500	[thread overview]
Message-ID: <14e1f476-7c3c-40ac-a48e-9af3e43a834d@ieee.org> (raw)
In-Reply-To: <2024032510-planner-caterer-3693@gregkh>

On 3/25/24 1:50 PM, Greg Kroah-Hartman wrote:
> On Mon, Mar 25, 2024 at 01:31:34PM -0500, Alex Elder wrote:
>> On 3/25/24 12:25 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Mar 07, 2024 at 09:48:13AM +0000, Rui Miguel Silva wrote:
>>>> If channel for the given node is not found we return null from
>>>> get_channel_from_mode. Make sure we validate the return pointer
>>>> before using it in two of the missing places.
>>>>
>>>> This was originally reported in [0]:
>>>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>>>
>>>> [0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
>>>>
>>>> Fixes: 2870b52bae4c ("greybus: lights: add lights implementation")
>>>> Reported-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
>>>> Suggested-by: Mikhail Lobanov <m.lobanov@rosalinux.ru>
>>>> Suggested-by: Alex Elder <elder@ieee.org>
>>>> Signed-off-by: Rui Miguel Silva <rmfrfs@gmail.com>
>>>> ---
>>>>    drivers/staging/greybus/light.c | 6 +++++-
>>>>    1 file changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
>>>> index c6bd86a5335a..6f10b9e2c053 100644
>>>> --- a/drivers/staging/greybus/light.c
>>>> +++ b/drivers/staging/greybus/light.c
>>>> @@ -147,6 +147,9 @@ static int __gb_lights_flash_brightness_set(struct gb_channel *channel)
>>>>    		channel = get_channel_from_mode(channel->light,
>>>>    						GB_CHANNEL_MODE_TORCH);
>>>> +	if (!channel)
>>>> +		return -EINVAL;
>>>> +
>>>>    	/* For not flash we need to convert brightness to intensity */
>>>>    	intensity = channel->intensity_uA.min +
>>>>    			(channel->intensity_uA.step * channel->led->brightness);
>>>> @@ -549,7 +552,8 @@ static int gb_lights_light_v4l2_register(struct gb_light *light)
>>>>    	}
>>>>    	channel_flash = get_channel_from_mode(light, GB_CHANNEL_MODE_FLASH);
>>>> -	WARN_ON(!channel_flash);
>>>> +	if (WARN_ON(!channel_flash))
>>>> +		return -EINVAL;
>>>
>>> We should NOT crash machines just because of this, the WARN_ON() should
>>> be removed and just properly handle the error please.
>>
>> Greg, WARN_ON() doesn't normally crash the machine.  That said,
>> it's reasonable to remove the WARN_ON().
> 
> The huge majority of running Linux systems in the world run with
> panic-on-warn enabled, including the one in your pocket :(

I did not know that.  Then WARN_ON() is no better than BUG_ON().
I'm still learning.  Thank you.

					-Alex

>> I think the purpose of the warning is that this is a case that
>> should "never happen," so if it does, it's making some noise.
> 
> Making noise by rebooting the box is not good.
> 
> thanks,
> 
> greg k-h


  reply	other threads:[~2024-03-25 18:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07  9:48 [PATCH] greybus: lights: check return of get_channel_from_mode Rui Miguel Silva
2024-03-25 17:25 ` Greg Kroah-Hartman
2024-03-25 18:31   ` Alex Elder
2024-03-25 18:50     ` Greg Kroah-Hartman
2024-03-25 18:55       ` Alex Elder [this message]
2024-03-25 19:08         ` Rui Miguel Silva
2024-03-25 19:04   ` Rui Miguel Silva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=14e1f476-7c3c-40ac-a48e-9af3e43a834d@ieee.org \
    --to=elder@ieee.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=greybus-dev@lists.linaro.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=m.lobanov@rosalinux.ru \
    --cc=rmfrfs@gmail.com \
    --cc=rui.silva@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).