From: Kees Cook <keescook@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Tony Luck <tony.luck@intel.com>,
Anton Vorontsov <anton@enomsg.org>,
linux-kernel@vger.kernel.org,
WeiXiong Liao <liaoweixiong@allwinnertech.com>,
linux-mtd@lists.infradead.org, Colin Cross <ccross@android.com>
Subject: Re: [PATCH 8/9] pstore/blk: use the normal block device I/O path
Date: Tue, 1 Dec 2020 11:52:09 -0800 [thread overview]
Message-ID: <202012011149.5650B9796@keescook> (raw)
In-Reply-To: <20201016132047.3068029-9-hch@lst.de>
On Fri, Oct 16, 2020 at 03:20:46PM +0200, Christoph Hellwig wrote:
> Stop poking into block layer internals and just open the block device
> file an use kernel_read and kernel_write on it. Note that this means
> the transformation from name_to_dev_t can't be used anymore, and proper
> block device file names must be used.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> [...]
> +
> +#ifdef MODULE
> +static int __init pstore_blk_init(void)
> +{
> + return __pstore_blk_init(blkdev);
> +}
> late_initcall(pstore_blk_init);
>
> static void __exit pstore_blk_exit(void)
> {
> - if (!psblk_bdev)
> + if (!psblk_file)
> return;
> unregister_pstore_device(&pstore_blk_zone_ops);
> - blkdev_put(psblk_bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL);
> + fput(psblk_file);
> }
> module_exit(pstore_blk_exit);
> +#else /* MODULE */
> +/*
> + * During early boot the real root file system hasn't been mounted yet,
> + * and not device nodes are present yet. Use the same scheme to find
> + * the device that we use for mounting the root file system.
> + */
> +void __init pstore_blk_early_init(void)
> +{
> + const char devname[] = "/dev/pstore-blk";
> + dev_t dev = name_to_dev_t(blkdev);
> +
> + if (!dev)
> + return;
> + init_unlink(devname);
> + init_mknod(devname, S_IFBLK | 0600, new_encode_dev(dev));
> + __pstore_blk_init(devname);
> +}
> +#endif /* MODULE */
That the allowed naming conventions change based on _how_ pstore is
built seems very wrong to me.
While I do like the clean up to simplify the read/write activities, this
seems like totally the wrong approach here.
>
> /* get information of pstore/blk */
> int pstore_blk_get_config(struct pstore_blk_config *info)
> diff --git a/include/linux/pstore_blk.h b/include/linux/pstore_blk.h
> index 0abd412a6cb3e3..7c06b9d6740e2a 100644
> --- a/include/linux/pstore_blk.h
> +++ b/include/linux/pstore_blk.h
> @@ -39,4 +39,6 @@ struct pstore_blk_config {
> */
> int pstore_blk_get_config(struct pstore_blk_config *info);
>
> +void __init pstore_blk_early_init(void);
> +
> #endif
> diff --git a/init/main.c b/init/main.c
> index 1af84337cb18d5..058cce64f70390 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -98,6 +98,7 @@
> #include <linux/mem_encrypt.h>
> #include <linux/kcsan.h>
> #include <linux/init_syscalls.h>
> +#include <linux/pstore_blk.h>
>
> #include <asm/io.h>
> #include <asm/bugs.h>
> @@ -1524,6 +1525,9 @@ static noinline void __init kernel_init_freeable(void)
> prepare_namespace();
> }
>
> + if (IS_BUILTIN(CONFIG_PSTORE_BLK))
> + pstore_blk_early_init();
> +
I hate this being a special-case in kernel_init. For ramoops, we use:
postcore_initcall(ramoops_init);
which is much better than open coding this here.
> /*
> * Ok, we have completed the initial bootup, and
> * we're essentially up and running. Get rid of the
> --
> 2.28.0
>
--
Kees Cook
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Anton Vorontsov <anton@enomsg.org>,
Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
WeiXiong Liao <liaoweixiong@allwinnertech.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 8/9] pstore/blk: use the normal block device I/O path
Date: Tue, 1 Dec 2020 11:52:09 -0800 [thread overview]
Message-ID: <202012011149.5650B9796@keescook> (raw)
In-Reply-To: <20201016132047.3068029-9-hch@lst.de>
On Fri, Oct 16, 2020 at 03:20:46PM +0200, Christoph Hellwig wrote:
> Stop poking into block layer internals and just open the block device
> file an use kernel_read and kernel_write on it. Note that this means
> the transformation from name_to_dev_t can't be used anymore, and proper
> block device file names must be used.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> [...]
> +
> +#ifdef MODULE
> +static int __init pstore_blk_init(void)
> +{
> + return __pstore_blk_init(blkdev);
> +}
> late_initcall(pstore_blk_init);
>
> static void __exit pstore_blk_exit(void)
> {
> - if (!psblk_bdev)
> + if (!psblk_file)
> return;
> unregister_pstore_device(&pstore_blk_zone_ops);
> - blkdev_put(psblk_bdev, FMODE_READ | FMODE_WRITE | FMODE_EXCL);
> + fput(psblk_file);
> }
> module_exit(pstore_blk_exit);
> +#else /* MODULE */
> +/*
> + * During early boot the real root file system hasn't been mounted yet,
> + * and not device nodes are present yet. Use the same scheme to find
> + * the device that we use for mounting the root file system.
> + */
> +void __init pstore_blk_early_init(void)
> +{
> + const char devname[] = "/dev/pstore-blk";
> + dev_t dev = name_to_dev_t(blkdev);
> +
> + if (!dev)
> + return;
> + init_unlink(devname);
> + init_mknod(devname, S_IFBLK | 0600, new_encode_dev(dev));
> + __pstore_blk_init(devname);
> +}
> +#endif /* MODULE */
That the allowed naming conventions change based on _how_ pstore is
built seems very wrong to me.
While I do like the clean up to simplify the read/write activities, this
seems like totally the wrong approach here.
>
> /* get information of pstore/blk */
> int pstore_blk_get_config(struct pstore_blk_config *info)
> diff --git a/include/linux/pstore_blk.h b/include/linux/pstore_blk.h
> index 0abd412a6cb3e3..7c06b9d6740e2a 100644
> --- a/include/linux/pstore_blk.h
> +++ b/include/linux/pstore_blk.h
> @@ -39,4 +39,6 @@ struct pstore_blk_config {
> */
> int pstore_blk_get_config(struct pstore_blk_config *info);
>
> +void __init pstore_blk_early_init(void);
> +
> #endif
> diff --git a/init/main.c b/init/main.c
> index 1af84337cb18d5..058cce64f70390 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -98,6 +98,7 @@
> #include <linux/mem_encrypt.h>
> #include <linux/kcsan.h>
> #include <linux/init_syscalls.h>
> +#include <linux/pstore_blk.h>
>
> #include <asm/io.h>
> #include <asm/bugs.h>
> @@ -1524,6 +1525,9 @@ static noinline void __init kernel_init_freeable(void)
> prepare_namespace();
> }
>
> + if (IS_BUILTIN(CONFIG_PSTORE_BLK))
> + pstore_blk_early_init();
> +
I hate this being a special-case in kernel_init. For ramoops, we use:
postcore_initcall(ramoops_init);
which is much better than open coding this here.
> /*
> * Ok, we have completed the initial bootup, and
> * we're essentially up and running. Get rid of the
> --
> 2.28.0
>
--
Kees Cook
next prev parent reply other threads:[~2020-12-01 19:53 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-16 13:20 simplify pstore-blk Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-10-16 13:20 ` [PATCH 1/9] pstore/zone: cap the maximum device size Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-11-08 14:05 ` 廖威雄
2020-11-08 14:05 ` 廖威雄
2020-12-01 19:08 ` Kees Cook
2020-12-01 19:08 ` Kees Cook
2020-12-01 21:11 ` Kees Cook
2020-12-01 21:11 ` Kees Cook
2020-10-16 13:20 ` [PATCH 2/9] pstore/blk: update the command line example Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-11-08 14:05 ` 廖威雄
2020-11-08 14:05 ` 廖威雄
2020-12-01 19:10 ` Kees Cook
2020-12-01 19:10 ` Kees Cook
2020-10-16 13:20 ` [PATCH 3/9] pstore/blk: remove {un,}register_pstore_blk Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-12-01 19:29 ` Kees Cook
2020-12-01 19:29 ` Kees Cook
2020-10-16 13:20 ` [PATCH 4/9] pstore/blk: remove __unregister_pstore_blk Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-12-01 19:20 ` Kees Cook
2020-12-01 19:20 ` Kees Cook
2020-10-16 13:20 ` [PATCH 5/9] pstore/blk: simplify the block device open / close path Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-12-01 19:40 ` Kees Cook
2020-12-01 19:40 ` Kees Cook
2020-10-16 13:20 ` [PATCH 6/9] pstore/zone: split struct pstore_zone_info Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-12-01 19:42 ` Kees Cook
2020-12-01 19:42 ` Kees Cook
2020-10-16 13:20 ` [PATCH 7/9] pstore/blk: remove struct pstore_device_info Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-12-01 19:44 ` Kees Cook
2020-12-01 19:44 ` Kees Cook
2020-10-16 13:20 ` [PATCH 8/9] pstore/blk: use the normal block device I/O path Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-11-08 14:43 ` 廖威雄
2020-11-08 14:43 ` 廖威雄
2020-11-23 14:49 ` Christoph Hellwig
2020-11-23 14:49 ` Christoph Hellwig
2020-12-01 19:52 ` Kees Cook [this message]
2020-12-01 19:52 ` Kees Cook
2020-10-16 13:20 ` [PATCH 9/9] pstore/blk: don't depend on CONFIG_BLOCK Christoph Hellwig
2020-10-16 13:20 ` Christoph Hellwig
2020-10-16 19:36 ` kernel test robot
2020-12-01 19:53 ` Kees Cook
2020-12-01 19:53 ` Kees Cook
2020-10-16 22:54 ` simplify pstore-blk Kees Cook
2020-10-16 22:54 ` Kees Cook
2020-11-23 14:53 ` Christoph Hellwig
2020-11-23 14:53 ` Christoph Hellwig
2020-11-24 22:53 ` Kees Cook
2020-11-24 22:53 ` Kees Cook
2020-11-08 14:34 ` 廖威雄
2020-11-08 14:34 ` 廖威雄
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=202012011149.5650B9796@keescook \
--to=keescook@chromium.org \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=hch@lst.de \
--cc=liaoweixiong@allwinnertech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=tony.luck@intel.com \
/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.