pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
/*
|
|
|
|
* Implements pstore backend driver that write to block (or non-block) storage
|
|
|
|
* devices, using the pstore/zone API.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/blkdev.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/of.h>
|
|
|
|
#include <linux/of_address.h>
|
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/pstore_blk.h>
|
2021-06-15 03:39:51 +08:00
|
|
|
#include <linux/fs.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/init_syscalls.h>
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
#include <linux/mount.h>
|
|
|
|
|
|
|
|
static long kmsg_size = CONFIG_PSTORE_BLK_KMSG_SIZE;
|
|
|
|
module_param(kmsg_size, long, 0400);
|
|
|
|
MODULE_PARM_DESC(kmsg_size, "kmsg dump record size in kbytes");
|
|
|
|
|
|
|
|
static int max_reason = CONFIG_PSTORE_BLK_MAX_REASON;
|
|
|
|
module_param(max_reason, int, 0400);
|
|
|
|
MODULE_PARM_DESC(max_reason,
|
|
|
|
"maximum reason for kmsg dump (default 2: Oops and Panic)");
|
|
|
|
|
2020-03-25 16:54:59 +08:00
|
|
|
#if IS_ENABLED(CONFIG_PSTORE_PMSG)
|
|
|
|
static long pmsg_size = CONFIG_PSTORE_BLK_PMSG_SIZE;
|
|
|
|
#else
|
|
|
|
static long pmsg_size = -1;
|
|
|
|
#endif
|
|
|
|
module_param(pmsg_size, long, 0400);
|
|
|
|
MODULE_PARM_DESC(pmsg_size, "pmsg size in kbytes");
|
|
|
|
|
2020-03-25 16:55:00 +08:00
|
|
|
#if IS_ENABLED(CONFIG_PSTORE_CONSOLE)
|
|
|
|
static long console_size = CONFIG_PSTORE_BLK_CONSOLE_SIZE;
|
|
|
|
#else
|
|
|
|
static long console_size = -1;
|
|
|
|
#endif
|
|
|
|
module_param(console_size, long, 0400);
|
|
|
|
MODULE_PARM_DESC(console_size, "console size in kbytes");
|
|
|
|
|
2020-03-25 16:55:01 +08:00
|
|
|
#if IS_ENABLED(CONFIG_PSTORE_FTRACE)
|
|
|
|
static long ftrace_size = CONFIG_PSTORE_BLK_FTRACE_SIZE;
|
|
|
|
#else
|
|
|
|
static long ftrace_size = -1;
|
|
|
|
#endif
|
|
|
|
module_param(ftrace_size, long, 0400);
|
|
|
|
MODULE_PARM_DESC(ftrace_size, "ftrace size in kbytes");
|
|
|
|
|
2020-05-08 23:34:01 +08:00
|
|
|
static bool best_effort;
|
|
|
|
module_param(best_effort, bool, 0400);
|
|
|
|
MODULE_PARM_DESC(best_effort, "use best effort to write (i.e. do not require storage driver pstore support, default: off)");
|
|
|
|
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
/*
|
|
|
|
* blkdev - the block device to use for pstore storage
|
2021-06-16 01:33:00 +08:00
|
|
|
* See Documentation/admin-guide/pstore-blk.rst for details.
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
*/
|
|
|
|
static char blkdev[80] = CONFIG_PSTORE_BLK_BLKDEV;
|
|
|
|
module_param_string(blkdev, blkdev, 80, 0400);
|
|
|
|
MODULE_PARM_DESC(blkdev, "block device for pstore storage");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* All globals must only be accessed under the pstore_blk_lock
|
|
|
|
* during the register/unregister functions.
|
|
|
|
*/
|
|
|
|
static DEFINE_MUTEX(pstore_blk_lock);
|
2021-06-15 03:39:51 +08:00
|
|
|
static struct file *psblk_file;
|
2021-06-16 01:19:13 +08:00
|
|
|
static struct pstore_device_info *pstore_device_info;
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
2020-03-25 16:55:04 +08:00
|
|
|
#define check_size(name, alignsize) ({ \
|
|
|
|
long _##name_ = (name); \
|
|
|
|
_##name_ = _##name_ <= 0 ? 0 : (_##name_ * 1024); \
|
|
|
|
if (_##name_ & ((alignsize) - 1)) { \
|
|
|
|
pr_info(#name " must align to %d\n", \
|
|
|
|
(alignsize)); \
|
|
|
|
_##name_ = ALIGN(name, (alignsize)); \
|
|
|
|
} \
|
|
|
|
_##name_; \
|
|
|
|
})
|
|
|
|
|
2021-06-16 22:51:28 +08:00
|
|
|
#define verify_size(name, alignsize, enabled) { \
|
|
|
|
long _##name_; \
|
|
|
|
if (enabled) \
|
|
|
|
_##name_ = check_size(name, alignsize); \
|
|
|
|
else \
|
|
|
|
_##name_ = 0; \
|
|
|
|
/* Synchronize module parameters with resuls. */ \
|
|
|
|
name = _##name_ / 1024; \
|
2021-06-16 01:19:13 +08:00
|
|
|
dev->zone.name = _##name_; \
|
2021-06-16 22:51:28 +08:00
|
|
|
}
|
|
|
|
|
2020-03-25 16:55:05 +08:00
|
|
|
static int __register_pstore_device(struct pstore_device_info *dev)
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2020-03-25 16:55:05 +08:00
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
|
|
|
|
2021-06-15 23:40:04 +08:00
|
|
|
if (!dev) {
|
|
|
|
pr_err("NULL device info\n");
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
return -EINVAL;
|
2021-06-15 23:40:04 +08:00
|
|
|
}
|
2021-06-16 01:19:13 +08:00
|
|
|
if (!dev->zone.total_size) {
|
2021-06-15 23:40:04 +08:00
|
|
|
pr_err("zero sized device\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2021-06-16 01:19:13 +08:00
|
|
|
if (!dev->zone.read) {
|
2021-06-15 23:40:04 +08:00
|
|
|
pr_err("no read handler for device\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2021-06-16 01:19:13 +08:00
|
|
|
if (!dev->zone.write) {
|
2021-06-15 23:40:04 +08:00
|
|
|
pr_err("no write handler for device\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
|
|
|
/* someone already registered before */
|
2021-06-16 01:19:13 +08:00
|
|
|
if (pstore_device_info)
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
return -EBUSY;
|
2020-03-25 16:55:05 +08:00
|
|
|
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
/* zero means not limit on which backends to attempt to store. */
|
|
|
|
if (!dev->flags)
|
|
|
|
dev->flags = UINT_MAX;
|
|
|
|
|
2021-06-16 01:19:13 +08:00
|
|
|
/* Copy in module parameters. */
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
verify_size(kmsg_size, 4096, dev->flags & PSTORE_FLAGS_DMESG);
|
2020-03-25 16:54:59 +08:00
|
|
|
verify_size(pmsg_size, 4096, dev->flags & PSTORE_FLAGS_PMSG);
|
2020-03-25 16:55:00 +08:00
|
|
|
verify_size(console_size, 4096, dev->flags & PSTORE_FLAGS_CONSOLE);
|
2020-03-25 16:55:01 +08:00
|
|
|
verify_size(ftrace_size, 4096, dev->flags & PSTORE_FLAGS_FTRACE);
|
2021-06-16 01:19:13 +08:00
|
|
|
dev->zone.max_reason = max_reason;
|
|
|
|
|
|
|
|
/* Initialize required zone ownership details. */
|
|
|
|
dev->zone.name = KBUILD_MODNAME;
|
|
|
|
dev->zone.owner = THIS_MODULE;
|
|
|
|
|
|
|
|
ret = register_pstore_zone(&dev->zone);
|
|
|
|
if (ret == 0)
|
|
|
|
pstore_device_info = dev;
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
2020-03-25 16:55:05 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
/**
|
|
|
|
* register_pstore_device() - register non-block device to pstore/blk
|
|
|
|
*
|
|
|
|
* @dev: non-block device information
|
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* * 0 - OK
|
|
|
|
* * Others - something error.
|
|
|
|
*/
|
|
|
|
int register_pstore_device(struct pstore_device_info *dev)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(&pstore_blk_lock);
|
|
|
|
ret = __register_pstore_device(dev);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
mutex_unlock(&pstore_blk_lock);
|
2020-03-25 16:55:05 +08:00
|
|
|
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2020-03-25 16:55:05 +08:00
|
|
|
EXPORT_SYMBOL_GPL(register_pstore_device);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
2020-03-25 16:55:05 +08:00
|
|
|
static void __unregister_pstore_device(struct pstore_device_info *dev)
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
{
|
2020-03-25 16:55:05 +08:00
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
2021-06-16 01:19:13 +08:00
|
|
|
if (pstore_device_info && pstore_device_info == dev) {
|
|
|
|
unregister_pstore_zone(&dev->zone);
|
|
|
|
pstore_device_info = NULL;
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
}
|
2020-03-25 16:55:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* unregister_pstore_device() - unregister non-block device from pstore/blk
|
|
|
|
*
|
|
|
|
* @dev: non-block device information
|
|
|
|
*/
|
|
|
|
void unregister_pstore_device(struct pstore_device_info *dev)
|
|
|
|
{
|
|
|
|
mutex_lock(&pstore_blk_lock);
|
|
|
|
__unregister_pstore_device(dev);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
mutex_unlock(&pstore_blk_lock);
|
|
|
|
}
|
2020-03-25 16:55:05 +08:00
|
|
|
EXPORT_SYMBOL_GPL(unregister_pstore_device);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
|
|
|
static ssize_t psblk_generic_blk_read(char *buf, size_t bytes, loff_t pos)
|
|
|
|
{
|
2021-06-15 03:39:51 +08:00
|
|
|
return kernel_read(psblk_file, buf, bytes, &pos);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t psblk_generic_blk_write(const char *buf, size_t bytes,
|
|
|
|
loff_t pos)
|
|
|
|
{
|
|
|
|
/* Console/Ftrace backend may handle buffer until flush dirty zones */
|
|
|
|
if (in_interrupt() || irqs_disabled())
|
|
|
|
return -EBUSY;
|
2021-06-15 03:39:51 +08:00
|
|
|
return kernel_write(psblk_file, buf, bytes, &pos);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
}
|
|
|
|
|
2020-10-16 21:20:41 +08:00
|
|
|
/*
|
|
|
|
* This takes its configuration only from the module parameters now.
|
|
|
|
*/
|
2021-06-16 01:19:13 +08:00
|
|
|
static int __register_pstore_blk(struct pstore_device_info *dev,
|
|
|
|
const char *devpath)
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
{
|
|
|
|
int ret = -ENODEV;
|
|
|
|
|
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
|
|
|
|
2021-06-15 03:39:51 +08:00
|
|
|
psblk_file = filp_open(devpath, O_RDWR | O_DSYNC | O_NOATIME | O_EXCL, 0);
|
|
|
|
if (IS_ERR(psblk_file)) {
|
|
|
|
ret = PTR_ERR(psblk_file);
|
|
|
|
pr_err("failed to open '%s': %d!\n", devpath, ret);
|
|
|
|
goto err;
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
}
|
|
|
|
|
2021-10-18 18:11:21 +08:00
|
|
|
if (!S_ISBLK(file_inode(psblk_file)->i_mode)) {
|
2021-06-15 03:39:51 +08:00
|
|
|
pr_err("'%s' is not block device!\n", devpath);
|
|
|
|
goto err_fput;
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
}
|
|
|
|
|
2021-10-18 18:11:21 +08:00
|
|
|
dev->zone.total_size =
|
|
|
|
bdev_nr_bytes(I_BDEV(psblk_file->f_mapping->host));
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
2021-06-16 01:19:13 +08:00
|
|
|
ret = __register_pstore_device(dev);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
if (ret)
|
2021-06-15 03:39:51 +08:00
|
|
|
goto err_fput;
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2021-06-15 03:39:51 +08:00
|
|
|
err_fput:
|
|
|
|
fput(psblk_file);
|
|
|
|
err:
|
|
|
|
psblk_file = NULL;
|
|
|
|
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2020-03-25 16:55:04 +08:00
|
|
|
/* get information of pstore/blk */
|
|
|
|
int pstore_blk_get_config(struct pstore_blk_config *info)
|
|
|
|
{
|
|
|
|
strncpy(info->device, blkdev, 80);
|
|
|
|
info->max_reason = max_reason;
|
|
|
|
info->kmsg_size = check_size(kmsg_size, 4096);
|
|
|
|
info->pmsg_size = check_size(pmsg_size, 4096);
|
|
|
|
info->ftrace_size = check_size(ftrace_size, 4096);
|
|
|
|
info->console_size = check_size(console_size, 4096);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(pstore_blk_get_config);
|
|
|
|
|
2021-06-15 03:39:51 +08:00
|
|
|
|
|
|
|
#ifndef MODULE
|
|
|
|
static const char devname[] = "/dev/pstore-blk";
|
|
|
|
static __init const char *early_boot_devpath(const char *initial_devname)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* During early boot the real root file system hasn't been
|
|
|
|
* mounted yet, and no device nodes are present yet. Use the
|
|
|
|
* same scheme to find the device that we use for mounting
|
|
|
|
* the root file system.
|
|
|
|
*/
|
2023-05-31 20:55:24 +08:00
|
|
|
dev_t dev;
|
2021-06-15 03:39:51 +08:00
|
|
|
|
2023-05-31 20:55:24 +08:00
|
|
|
if (early_lookup_bdev(initial_devname, &dev)) {
|
2021-06-15 03:39:51 +08:00
|
|
|
pr_err("failed to resolve '%s'!\n", initial_devname);
|
|
|
|
return initial_devname;
|
|
|
|
}
|
|
|
|
|
|
|
|
init_unlink(devname);
|
|
|
|
init_mknod(devname, S_IFBLK | 0600, new_encode_dev(dev));
|
|
|
|
|
|
|
|
return devname;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
static inline const char *early_boot_devpath(const char *initial_devname)
|
|
|
|
{
|
|
|
|
return initial_devname;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2021-06-16 01:19:13 +08:00
|
|
|
static int __init __best_effort_init(void)
|
|
|
|
{
|
|
|
|
struct pstore_device_info *best_effort_dev;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* No best-effort mode requested. */
|
|
|
|
if (!best_effort)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Reject an empty blkdev. */
|
|
|
|
if (!blkdev[0]) {
|
|
|
|
pr_err("blkdev empty with best_effort=Y\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
best_effort_dev = kzalloc(sizeof(*best_effort_dev), GFP_KERNEL);
|
|
|
|
if (!best_effort_dev)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
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
|
2021-11-19 02:26:21 +08:00
|
|
|
pr_info("attached %s (%lu) (no dedicated panic_write!)\n",
|
2021-06-16 01:19:13 +08:00
|
|
|
blkdev, best_effort_dev->zone.total_size);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __exit __best_effort_exit(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Currently, the only user of psblk_file is best_effort, so
|
|
|
|
* we can assume that pstore_device_info is associated with it.
|
|
|
|
* Once there are "real" blk devices, there will need to be a
|
|
|
|
* dedicated pstore_blk_info, etc.
|
|
|
|
*/
|
|
|
|
if (psblk_file) {
|
|
|
|
struct pstore_device_info *dev = pstore_device_info;
|
|
|
|
|
|
|
|
__unregister_pstore_device(dev);
|
|
|
|
kfree(dev);
|
|
|
|
fput(psblk_file);
|
|
|
|
psblk_file = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-05-08 23:34:01 +08:00
|
|
|
static int __init pstore_blk_init(void)
|
|
|
|
{
|
2021-06-16 01:19:13 +08:00
|
|
|
int ret;
|
2020-05-08 23:34:01 +08:00
|
|
|
|
|
|
|
mutex_lock(&pstore_blk_lock);
|
2021-06-16 01:19:13 +08:00
|
|
|
ret = __best_effort_init();
|
2020-05-08 23:34:01 +08:00
|
|
|
mutex_unlock(&pstore_blk_lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
late_initcall(pstore_blk_init);
|
|
|
|
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
static void __exit pstore_blk_exit(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&pstore_blk_lock);
|
2021-06-16 01:19:13 +08:00
|
|
|
__best_effort_exit();
|
|
|
|
/* If we've been asked to unload, unregister any remaining device. */
|
|
|
|
__unregister_pstore_device(pstore_device_info);
|
pstore/blk: Introduce backend for block devices
pstore/blk is similar to pstore/ram, but uses a block device as the
storage rather than persistent ram.
The pstore/blk backend solves two common use-cases that used to preclude
using pstore/ram:
- not all devices have a battery that could be used to persist
regular RAM across power failures.
- most embedded intelligent equipment have no persistent ram, which
increases costs, instead preferring cheaper solutions, like block
devices.
pstore/blk provides separate configurations for the end user and for the
block drivers. User configuration determines how pstore/blk operates, such
as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig
and/or module parameters, but module parameter have priority over Kconfig.
Driver configuration covers all the details about the target block device,
such as total size of the device and how to perform read/write operations.
These are provided by block drivers, calling pstore_register_blkdev(),
including an optional panic_write callback used to bypass regular IO
APIs in an effort to avoid potentially destabilized kernel code during
a panic.
Signed-off-by: WeiXiong Liao <liaoweixiong@allwinnertech.com>
Link: https://lore.kernel.org/lkml/20200511233229.27745-3-keescook@chromium.org/
Co-developed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-03-25 16:54:57 +08:00
|
|
|
mutex_unlock(&pstore_blk_lock);
|
|
|
|
}
|
|
|
|
module_exit(pstore_blk_exit);
|
|
|
|
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_AUTHOR("WeiXiong Liao <liaoweixiong@allwinnertech.com>");
|
|
|
|
MODULE_AUTHOR("Kees Cook <keescook@chromium.org>");
|
|
|
|
MODULE_DESCRIPTION("pstore backend for block devices");
|