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 11:54:57 +03: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-14 22:39:51 +03: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 11:54:57 +03: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 11:54:59 +03: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 11:55:00 +03: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 11:55:01 +03: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 18:34:01 +03: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 11:54:57 +03:00
|
|
|
/*
|
|
|
|
* blkdev - the block device to use for pstore storage
|
|
|
|
*
|
|
|
|
* Usually, this will be a partition of a block device.
|
|
|
|
*
|
2021-06-14 22:39:51 +03:00
|
|
|
* blkdev accepts the following variants, when built as a module:
|
|
|
|
* 1) /dev/<disk_name> represents the device number of disk
|
|
|
|
* 2) /dev/<disk_name><decimal> represents the device number
|
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 11:54:57 +03:00
|
|
|
* of partition - device number of disk plus the partition number
|
2021-06-14 22:39:51 +03:00
|
|
|
* 3) /dev/<disk_name>p<decimal> - same as the above, that form is
|
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 11:54:57 +03:00
|
|
|
* used when disk name of partitioned disk ends on a digit.
|
2021-06-14 22:39:51 +03:00
|
|
|
*
|
|
|
|
* blkdev accepts the following variants when built into the kernel:
|
|
|
|
* 1) <hex_major><hex_minor> device number in hexadecimal representation,
|
|
|
|
* with no leading 0x, for example b302.
|
|
|
|
* 2) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
|
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 11:54:57 +03:00
|
|
|
* unique id of a partition if the partition table provides it.
|
|
|
|
* The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
|
|
|
|
* partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
|
|
|
|
* filled hex representation of the 32-bit "NT disk signature", and PP
|
|
|
|
* is a zero-filled hex representation of the 1-based partition number.
|
2021-06-14 22:39:51 +03:00
|
|
|
* 3) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
|
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 11:54:57 +03:00
|
|
|
* a partition with a known unique id.
|
2021-06-14 22:39:51 +03:00
|
|
|
* 4) <major>:<minor> major and minor number of the device separated by
|
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 11:54:57 +03:00
|
|
|
* a colon.
|
|
|
|
*/
|
|
|
|
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-14 22:39:51 +03:00
|
|
|
static struct file *psblk_file;
|
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 11:54:57 +03:00
|
|
|
static struct pstore_zone_info *pstore_zone_info;
|
|
|
|
|
2020-03-25 11:55:04 +03: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 17:51:28 +03: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; \
|
|
|
|
pstore_zone_info->name = _##name_; \
|
|
|
|
}
|
|
|
|
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2020-03-25 11:55:05 +03:00
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
|
|
|
|
2021-06-15 18:40:04 +03: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 11:54:57 +03:00
|
|
|
return -EINVAL;
|
2021-06-15 18:40:04 +03:00
|
|
|
}
|
|
|
|
if (!dev->total_size) {
|
|
|
|
pr_err("zero sized device\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (!dev->read) {
|
|
|
|
pr_err("no read handler for device\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
if (!dev->write) {
|
|
|
|
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 11:54:57 +03:00
|
|
|
|
|
|
|
/* someone already registered before */
|
2020-03-25 11:55:05 +03:00
|
|
|
if (pstore_zone_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 11:54:57 +03:00
|
|
|
return -EBUSY;
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
pstore_zone_info = kzalloc(sizeof(struct pstore_zone_info), GFP_KERNEL);
|
2020-03-25 11:55:05 +03:00
|
|
|
if (!pstore_zone_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 11:54:57 +03:00
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* zero means not limit on which backends to attempt to store. */
|
|
|
|
if (!dev->flags)
|
|
|
|
dev->flags = UINT_MAX;
|
|
|
|
|
|
|
|
verify_size(kmsg_size, 4096, dev->flags & PSTORE_FLAGS_DMESG);
|
2020-03-25 11:54:59 +03:00
|
|
|
verify_size(pmsg_size, 4096, dev->flags & PSTORE_FLAGS_PMSG);
|
2020-03-25 11:55:00 +03:00
|
|
|
verify_size(console_size, 4096, dev->flags & PSTORE_FLAGS_CONSOLE);
|
2020-03-25 11:55:01 +03:00
|
|
|
verify_size(ftrace_size, 4096, dev->flags & PSTORE_FLAGS_FTRACE);
|
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 11:54:57 +03:00
|
|
|
|
|
|
|
pstore_zone_info->total_size = dev->total_size;
|
|
|
|
pstore_zone_info->max_reason = max_reason;
|
|
|
|
pstore_zone_info->read = dev->read;
|
|
|
|
pstore_zone_info->write = dev->write;
|
2020-03-25 11:55:05 +03:00
|
|
|
pstore_zone_info->erase = dev->erase;
|
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 11:54:57 +03:00
|
|
|
pstore_zone_info->panic_write = dev->panic_write;
|
|
|
|
pstore_zone_info->name = KBUILD_MODNAME;
|
|
|
|
pstore_zone_info->owner = THIS_MODULE;
|
|
|
|
|
|
|
|
ret = register_pstore_zone(pstore_zone_info);
|
|
|
|
if (ret) {
|
|
|
|
kfree(pstore_zone_info);
|
|
|
|
pstore_zone_info = NULL;
|
|
|
|
}
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
mutex_unlock(&pstore_blk_lock);
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
return ret;
|
|
|
|
}
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
{
|
2020-03-25 11:55:05 +03:00
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
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 11:54:57 +03:00
|
|
|
if (pstore_zone_info && pstore_zone_info->read == dev->read) {
|
|
|
|
unregister_pstore_zone(pstore_zone_info);
|
|
|
|
kfree(pstore_zone_info);
|
|
|
|
pstore_zone_info = NULL;
|
|
|
|
}
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
mutex_unlock(&pstore_blk_lock);
|
|
|
|
}
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
|
|
|
|
static ssize_t psblk_generic_blk_read(char *buf, size_t bytes, loff_t pos)
|
|
|
|
{
|
2021-06-14 22:39:51 +03: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 11:54:57 +03: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-14 22:39:51 +03: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 11:54:57 +03:00
|
|
|
}
|
|
|
|
|
2020-10-16 16:20:41 +03:00
|
|
|
/*
|
|
|
|
* This takes its configuration only from the module parameters now.
|
|
|
|
*/
|
2021-06-14 22:39:51 +03:00
|
|
|
static int __register_pstore_blk(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 11:54:57 +03:00
|
|
|
{
|
2021-06-14 22:39:51 +03:00
|
|
|
struct pstore_device_info dev = {
|
|
|
|
.read = psblk_generic_blk_read,
|
|
|
|
.write = psblk_generic_blk_write,
|
|
|
|
};
|
|
|
|
struct inode *inode;
|
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 11:54:57 +03:00
|
|
|
int ret = -ENODEV;
|
|
|
|
|
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
|
|
|
|
2021-06-14 22:39:51 +03: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 11:54:57 +03:00
|
|
|
}
|
|
|
|
|
2021-06-14 22:39:51 +03:00
|
|
|
inode = file_inode(psblk_file);
|
|
|
|
if (!S_ISBLK(inode->i_mode)) {
|
|
|
|
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 11:54:57 +03:00
|
|
|
}
|
|
|
|
|
2021-06-14 22:39:51 +03:00
|
|
|
inode = I_BDEV(psblk_file->f_mapping->host)->bd_inode;
|
|
|
|
dev.total_size = i_size_read(inode);
|
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 11:54:57 +03:00
|
|
|
|
2020-03-25 11:55:05 +03: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 11:54:57 +03:00
|
|
|
if (ret)
|
2021-06-14 22:39:51 +03: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 11:54:57 +03:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2021-06-14 22:39:51 +03: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 11:54:57 +03:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-06-14 22:39:51 +03:00
|
|
|
static void __unregister_pstore_blk(struct file *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 11:54:57 +03:00
|
|
|
{
|
|
|
|
struct pstore_device_info dev = { .read = psblk_generic_blk_read };
|
|
|
|
|
|
|
|
lockdep_assert_held(&pstore_blk_lock);
|
2021-06-14 22:39:51 +03:00
|
|
|
if (psblk_file && psblk_file == device) {
|
2020-03-25 11:55:05 +03:00
|
|
|
__unregister_pstore_device(&dev);
|
2021-06-14 22:39:51 +03:00
|
|
|
fput(psblk_file);
|
|
|
|
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 11:54:57 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-03-25 11:55:04 +03: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-14 22:39:51 +03: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.
|
|
|
|
*/
|
|
|
|
dev_t dev = name_to_dev_t(initial_devname);
|
|
|
|
|
|
|
|
if (!dev) {
|
|
|
|
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
|
|
|
|
|
2020-05-08 18:34:01 +03:00
|
|
|
static int __init pstore_blk_init(void)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
mutex_lock(&pstore_blk_lock);
|
2021-06-14 22:39:51 +03:00
|
|
|
if (!pstore_zone_info && best_effort && blkdev[0]) {
|
|
|
|
ret = __register_pstore_blk(early_boot_devpath(blkdev));
|
|
|
|
if (ret == 0 && pstore_zone_info)
|
|
|
|
pr_info("attached %s:%s (%zu) (no dedicated panic_write!)\n",
|
|
|
|
pstore_zone_info->name, blkdev,
|
|
|
|
pstore_zone_info->total_size);
|
|
|
|
}
|
2020-05-08 18:34:01 +03: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 11:54:57 +03:00
|
|
|
static void __exit pstore_blk_exit(void)
|
|
|
|
{
|
|
|
|
mutex_lock(&pstore_blk_lock);
|
2021-06-14 22:39:51 +03:00
|
|
|
if (psblk_file)
|
|
|
|
__unregister_pstore_blk(psblk_file);
|
2020-03-25 11:55:05 +03:00
|
|
|
else {
|
|
|
|
struct pstore_device_info dev = { };
|
|
|
|
|
|
|
|
if (pstore_zone_info)
|
|
|
|
dev.read = pstore_zone_info->read;
|
|
|
|
__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 11:54:57 +03: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");
|