public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafał Miłecki" <zajec5@gmail.com>
To: Johan Hovold <johan@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Srinivas Kandagatla" <srinivas.kandagatla@linaro.org>,
	"Andrey Smirnov" <andrew.smirnov@gmail.com>,
	linux-kernel@vger.kernel.org, "Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH] nvmem: fix unregistering device in nvmem_register() error path
Date: Wed, 22 Dec 2021 10:00:03 +0100	[thread overview]
Message-ID: <52a2a318-0efe-94af-b8b9-308c2fbb1fab@gmail.com> (raw)
In-Reply-To: <YcLkA0e48+xuGsHk@hovoldconsulting.com>

On 22.12.2021 09:38, Johan Hovold wrote:
> On Wed, Dec 22, 2021 at 08:44:44AM +0100, Greg Kroah-Hartman wrote:
>> On Tue, Dec 21, 2021 at 06:46:01PM +0100, Rafał Miłecki wrote:
>>> On 21.12.2021 17:06, Greg Kroah-Hartman wrote:
>>>> On Tue, Dec 21, 2021 at 04:45:50PM +0100, Rafał Miłecki wrote:
>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>
>>>>> 1. Drop incorrect put_device() calls
>>>>>
>>>>> If device_register() fails then underlaying device_add() takes care of
>>>>> calling put_device() if needed. There is no need to do that in a driver.
>>>>
>>>> Did you read the documentation for device_register() that says:
>>>>
>>>>    * NOTE: _Never_ directly free @dev after calling this function, even
>>>>    * if it returned an error! Always use put_device() to give up the
>>>>    * reference initialized in this function instead.
>>>
>>> I clearly tried to be too smart and ignored documentation.
>>>
>>> I'd say device_add() behaviour is rather uncommon and a bit unintuitive.
>>> Most kernel functions are safe to assume to do nothing that requires
>>> cleanup if they fail.
>>>
>>> E.g. if I call platform_device_register() and it fails I don't need to
>>> call anything like platform_device_put(). I just free previously
>>> allocated memory.
>>
>> And that is wrong.
> 
> It seems Rafał is mistaken here too; you certainly need to call
> platform_device_put() if platform_device_register() fail, even if many
> current users do appear to get this wrong.

Yes I was! Gosh I made up that "platform_device_put()" name and only
now I realized it actually exists!

I stand by saying this design is really misleading. Even though
platform_device_put() was obviously a bad example.

Please remember I'm just a minor kernel developer however in my humble
opinion behaviour of device_register() and platform_device_register()
should be changed.

If any function fails I expect:
1. That function to clean up its mess if any
2. Me to be responsible to clean up my mess if any

This is how "most" code (whatever it means) works.
1. If POSIX snprintf() fails I'm not expected to call *printf_put() sth
2. If POSIX bind() fails I'm not expected to call bind_put() sth
3. (...)

I'm not sure if those are the best examples but you should get my point.

  parent reply	other threads:[~2021-12-22  9:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-21 15:45 [PATCH] nvmem: fix unregistering device in nvmem_register() error path Rafał Miłecki
2021-12-21 16:06 ` Greg Kroah-Hartman
2021-12-21 17:46   ` Rafał Miłecki
2021-12-22  7:44     ` Greg Kroah-Hartman
2021-12-22  8:38       ` Johan Hovold
2021-12-22  8:56         ` Greg Kroah-Hartman
2021-12-22  9:02           ` Rafał Miłecki
2021-12-22  9:03           ` Johan Hovold
2021-12-22  9:24             ` Johan Hovold
2021-12-22  9:34               ` Greg Kroah-Hartman
2021-12-22  9:00         ` Rafał Miłecki [this message]
2021-12-22  9:08           ` Johan Hovold
2021-12-22  9:16             ` Rafał Miłecki
2021-12-22  9:26               ` Johan Hovold
2021-12-22  9:46                 ` Rafał Miłecki
2021-12-22  9:30               ` Greg Kroah-Hartman
2021-12-22  9:29           ` Greg Kroah-Hartman

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=52a2a318-0efe-94af-b8b9-308c2fbb1fab@gmail.com \
    --to=zajec5@gmail.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafal@milecki.pl \
    --cc=srinivas.kandagatla@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