All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zijun Hu <zijun_hu@icloud.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org, Zijun Hu <quic_zijuhu@quicinc.com>
Subject: Re: [PATCH v2] driver core: bus: Remove an impossible error handling path in bus_add_driver()
Date: Mon, 14 Oct 2024 00:35:51 +0800	[thread overview]
Message-ID: <a9a011fb-31d0-4ecb-ad8d-540d9761e28d@icloud.com> (raw)
In-Reply-To: <2024101349-handpick-cozy-f19e@gregkh>

On 2024/10/14 00:24, Greg Kroah-Hartman wrote:
> On Mon, Oct 14, 2024 at 12:13:30AM +0800, Zijun Hu wrote:
>> On 2024/10/14 00:00, Greg Kroah-Hartman wrote:
>>> On Sun, Oct 13, 2024 at 11:46:46PM +0800, Zijun Hu wrote:
>>>> On 2024/10/13 23:02, Greg Kroah-Hartman wrote:
>>>>> On Tue, Sep 17, 2024 at 02:53:32PM +0800, Zijun Hu wrote:
>>>>>> On 2024/9/17 14:49, Zijun Hu wrote:
>>>>>>> From: Zijun Hu <quic_zijuhu@quicinc.com>
>>>>>>>
>>>>>>> For the following function call chain:
>>>>>>> API driver_register() -> bus_add_driver() -> driver_attach()
>>>>>>>
>>>>>>> There is an error handling path for driver_attach() returning non-zero
>>>>>>> or failure in bus_add_driver(), remove it with below reasons:
>>>>>>>
>>>>>>> - It is impossible for driver_attach() to have failure in bus_add_driver()
>>>>>>>   For int driver_attach(const struct device_driver *drv), the only factor
>>>>>>>   which makes it failed is that bus_to_subsys(@drv->bus) is NULL, but
>>>>>>>   the factor has been excluded by bus_add_driver() before calling it.
>>>>>>>
>>>>>>> - driver_attach() is irrelevant with driver_register(), so the former's
>>>>>>>   result should not also have an impact on the later.
>>>>>>>
>>>>>>> Signed-off-by: Zijun Hu <quic_zijuhu@quicinc.com>
>>>>>>> ---
>>>>>>> Changes in v2:
>>>>>>> - Remove the error handling path instead of WARN_ON() it.
>>>>>>> - Correct title and commit message
>>>>>>> - Link to v1: https://lore.kernel.org/r/20240915-bus_add_driver_fix-v1-1-ce5cf1f66601@quicinc.com
>>>>>>> ---
>>>>>>>  drivers/base/bus.c | 4 ++--
>>>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
>>>>>>> index 657c93c38b0d..54ff92aece92 100644
>>>>>>> --- a/drivers/base/bus.c
>>>>>>> +++ b/drivers/base/bus.c
>>>>>>> @@ -674,7 +674,8 @@ int bus_add_driver(struct device_driver *drv)
>>>>>>>  	if (sp->drivers_autoprobe) {
>>>>>>>  		error = driver_attach(drv);
>>>>>>>  		if (error)
>>>>>>> -			goto out_del_list;
>>>>>>> +			pr_warn("%s: failed to attach driver '%s' to bus '%s'\n",
>>>>>>> +				__func__, drv->name, sp->bus->name);
>>>>>>
>>>>>> driver_attach() has __must_check attribute and this error may be
>>>>>> inconsequential for driver_register(), so give pr_warn() here
>>>>>
>>>>> Yes, but you  now ignore the error, so someone will come back and add
>>>>> that error handling in.  I'd just leave it as-is.
>>>>>
>>>>
>>>> driver API driver_attach() may ONLY have below error -EINVAL.
>>>> is it worthy of a __must_check attribute ?
>>>
>>> Yes.
>>>
>>>> i agree with you to leave it as-is if your answer is "YES".
>>>> otherwise, i would like to also simply remove __must_check attribute.
>>>
>>> Please don't.  If you do that, then callers will end up not checking the
>>> results, and we do not want that.
>>>
>> okay.
>>
>> but as 2nd reason of commit message explained:
>> driver_attach() failure should NOT cause driver_register() failure, so
>> should ignore driver_attach() failure here.
> 
> How could driver_attach() fail and it still be ok to continue?
> 
sorry, i am wrong, agree with you to leave it as-is.

driver_attach() failure means driver itself error not attaching it with
devices error. so should cause driver_register() failure even if the
error is impossible here.

thanks.

> thanks,
> 
> greg k-h


      reply	other threads:[~2024-10-13 16:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-17  6:49 [PATCH v2] driver core: bus: Remove an impossible error handling path in bus_add_driver() Zijun Hu
2024-09-17  6:53 ` Zijun Hu
2024-10-13 15:02   ` Greg Kroah-Hartman
2024-10-13 15:46     ` Zijun Hu
2024-10-13 16:00       ` Greg Kroah-Hartman
2024-10-13 16:13         ` Zijun Hu
2024-10-13 16:24           ` Greg Kroah-Hartman
2024-10-13 16:35             ` Zijun Hu [this message]

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=a9a011fb-31d0-4ecb-ad8d-540d9761e28d@icloud.com \
    --to=zijun_hu@icloud.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_zijuhu@quicinc.com \
    --cc=rafael@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.