From: Kees Cook <keescook@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linux-kernel@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
gmpy.liaowx@gmail.com, Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
Jonathan Corbet <corbet@lwn.net>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-doc@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH v2 3/4] pstore/blk: Include zone in pstore_device_info
Date: Wed, 16 Jun 2021 07:41:52 -0700 [thread overview]
Message-ID: <202106160737.B0B8882B@keescook> (raw)
In-Reply-To: <20210616040247.GD25873@lst.de>
On Wed, Jun 16, 2021 at 06:02:47AM +0200, Christoph Hellwig wrote:
> > +#define verify_size(name, alignsize, enabled) { \
> > + long _##name_; \
> > + if (enabled) \
> > + _##name_ = check_size(name, alignsize); \
> > + else \
> > + _##name_ = 0; \
> > + /* synchronize visible module parameters to result. */ \
> > + name = _##name_ / 1024; \
> > + dev->zone.name = _##name_; \
> > + }
>
> The formatting here looks weird between the two-tab indent and the
> opening brace on the macro definition line.
I can adjust that, sure.
>
> > - if (!dev || !dev->total_size || !dev->read || !dev->write) {
> > + if (!dev || !dev->zone.total_size || !dev->zone.read || !dev->zone.write) {
> > if (!dev)
> > - pr_err("NULL device info\n");
> > + pr_err("NULL pstore_device_info\n");
> > else {
> > - if (!dev->total_size)
> > + if (!dev->zone.total_size)
> > pr_err("zero sized device\n");
> > - if (!dev->read)
> > + if (!dev->zone.read)
> > pr_err("no read handler for device\n");
> > - if (!dev->write)
> > + if (!dev->zone.write)
> > pr_err("no write handler for device\n");
> > }
>
> This still looks odd to me. Why not the somewhat more verbose but
> much more obvious:
>
> if (!dev) {
> pr_err("NULL pstore_device_info\n");
> return -EINVAL;
> }
> if (!dev->zone.total_size) {
> pr_err("zero sized device\n");
> return -EINVAL;
> }
> ...
Will do.
> > - dev.total_size = i_size_read(I_BDEV(psblk_file->f_mapping->host)->bd_inode);
> > + dev->zone.total_size = i_size_read(I_BDEV(psblk_file->f_mapping->host)->bd_inode);
>
> This is starting to be unreadable long. A local variable for the inode
> might be nice, as that can also be used in the ISBLK check above.
Fair enough; will change.
> > + if (!pstore_device_info && best_effort && blkdev[0]) {
> > + struct pstore_device_info *best_effort_dev;
> > +
> > + best_effort_dev = kzalloc(sizeof(*best_effort_dev), GFP_KERNEL);
> > + if (!best_effort) {
> > + ret = -ENOMEM;
> > + goto unlock;
> > + }
> > + best_effort_dev->zone.read = psblk_generic_blk_read;
> > + best_effort_dev->zone.write = psblk_generic_blk_write;
> > +
> > + ret = __register_pstore_blk(best_effort_dev,
> > + early_boot_devpath(blkdev));
> > + if (ret)
> > + kfree(best_effort_dev);
> > + else
> > + pr_info("attached %s (%zu) (no dedicated panic_write!)\n",
> > + blkdev, best_effort_dev->zone.total_size);
>
> Maybe split this into a little helper?
>
> > + /* Unregister and free the best_effort device. */
> > + if (psblk_file) {
> > + struct pstore_device_info *dev = pstore_device_info;
> > +
> > + __unregister_pstore_device(dev);
> > + kfree(dev);
> > + fput(psblk_file);
> > + psblk_file = NULL;
> > }
>
> Same.
I guess? I don't feel strongly one way or another.
>
> > + /* If we've been asked to unload, unregister any registered device. */
> > + if (pstore_device_info)
> > + __unregister_pstore_device(pstore_device_info);
>
> Won't this double unregister pstore_device_info?
No, __unregister_pstore_device() will NULL pstore_device_info.
>
> > struct pstore_device_info {
> > - unsigned long total_size;
> > unsigned int flags;
> > - pstore_zone_read_op read;
> > - pstore_zone_write_op write;
> > - pstore_zone_erase_op erase;
> > - pstore_zone_write_op panic_write;
> > + struct pstore_zone_info zone;
> > };
>
> Given that flags is only used inside of __register_pstore_device
> why not kill this struct and just pass it explicitly?
Because of the mess pstore's internal APIs used to be. :) It's likely
other things will get added here in the future, and I don't want to
have to repeat the kind of argument passing games that used to exist in
this code.
--
Kees Cook
next prev parent reply other threads:[~2021-06-16 14:42 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-15 21:21 [PATCH v2 0/4] Include zone in pstore_device_info Kees Cook
2021-06-15 21:21 ` [PATCH v2 1/4] pstore/blk: Improve failure reporting Kees Cook
2021-06-16 3:51 ` Christoph Hellwig
2021-06-15 21:21 ` [PATCH v2 2/4] pstore/blk: Use the normal block device I/O path Kees Cook
2021-06-16 3:52 ` Christoph Hellwig
2021-06-15 21:21 ` [PATCH v2 3/4] pstore/blk: Include zone in pstore_device_info Kees Cook
2021-06-16 4:02 ` Christoph Hellwig
2021-06-16 14:41 ` Kees Cook [this message]
2021-06-15 21:21 ` [PATCH v2 4/4] pstore/blk: Fix kerndoc and redundancy on blkdev param Kees Cook
2021-06-16 3:53 ` Christoph Hellwig
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=202106160737.B0B8882B@keescook \
--to=keescook@chromium.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=corbet@lwn.net \
--cc=gmpy.liaowx@gmail.com \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=miquel.raynal@bootlin.com \
--cc=richard@nod.at \
--cc=tony.luck@intel.com \
--cc=vigneshr@ti.com \
--cc=viro@zeniv.linux.org.uk \
/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 NNTP newsgroup(s).