From: Jason Gunthorpe <jgg@nvidia.com>
To: Dan Carpenter <dan.carpenter@oracle.com>, Christoph Hellwig <hch@lst.de>
Cc: kbusch@kernel.org, linux-kernel@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [bug report] node: Add memory-side caching attributes
Date: Thu, 1 Apr 2021 12:22:13 -0300 [thread overview]
Message-ID: <20210401152213.GI1463678@nvidia.com> (raw)
In-Reply-To: <20210401140652.GT2088@kadam>
On Thu, Apr 01, 2021 at 05:06:52PM +0300, Dan Carpenter wrote:
> > diff --git a/drivers/base/node.c b/drivers/base/node.c
> > index f449dbb2c74666..89c28952863977 100644
> > +++ b/drivers/base/node.c
> > @@ -319,25 +319,24 @@ void node_add_cache(unsigned int nid, struct node_cache_attrs *cache_attrs)
> > return;
> >
> > dev = &info->dev;
> > + device_initialize(dev)
> > dev->parent = node->cache_dev;
> > dev->release = node_cacheinfo_release;
> > dev->groups = cache_groups;
> > if (dev_set_name(dev, "index%d", cache_attrs->level))
>
> Is calling dev_set_name() without doing a device_initialize() a bug? I
> could write a check for that.
IMHO, yes.
However, Greg may not agree as dev_set_name() with no error check
followed by device_register() is a very common pattern. If the user
omits the device_initialize() then dev_set_name() must be immediately
before only device_register() with no error unwind between them. It
must not error unwind dev_set_name() to kfree. (This is really
tricky)
Greg and I have argued on the merits of device_initialize() several
times before.
I argue the error control flow is simpler and easier to get right, he
argues the extra statement is unneeded complexity and people will get
the error unwind wrong.
Every time you find a bug like this is someone getting the complexity
around error handling and device_register() wrong, so my advices is to
stop using device_register (aka device_init_and_add) and make it
explicit so the goto unwind has logical pairing. put_device() pairs
with device_initialize().
The tricky bit is establishing the release function, as complex
release functions often have complex init sequences and you need the
setup done enough to go to release. When things become this complex I
advocate splitting alloc into a function:
/* Caller must use put_device(&foo->dev) */
struct foo *foo_allocate()
{
foo = kzalloc
allocate release freeing thing 1;
allocate release freeing thing 2;
allocate release freeing thing 3;
device_initialize();
return foo;
err:
free thing 3;
err:
free thing 2;
err:
free thing 1;
err:
kfree(foo)
return rc;
}
Thus there is a clear logical seperation between the world of 'unwind
to kfree' and the world of 'unwind to put_device'. dev_set_name() can
not be inside an alloc function.
Simple cases, like here, should just do device_initialize()
immediately after kzalloc() and never have a kfree() error unwind.
I saw Christoph had a similar opinion on 'init and add' patterns being
bad, maybe he has additional colour to share.
Jason
next prev parent reply other threads:[~2021-04-01 18:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-01 9:00 [bug report] node: Add memory-side caching attributes Dan Carpenter
2021-04-01 11:25 ` Jason Gunthorpe
2021-04-01 14:06 ` Dan Carpenter
2021-04-01 15:22 ` Jason Gunthorpe [this message]
2021-04-01 21:27 ` Keith Busch
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=20210401152213.GI1463678@nvidia.com \
--to=jgg@nvidia.com \
--cc=dan.carpenter@oracle.com \
--cc=hch@lst.de \
--cc=kbusch@kernel.org \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox