2019-05-30 07:57:39 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2016-04-14 17:59:31 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright(c) 2015 Intel Deutschland GmbH
|
|
|
|
|
*/
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
#ifndef __DEVCOREDUMP_H
|
|
|
|
|
#define __DEVCOREDUMP_H
|
|
|
|
|
|
|
|
|
|
#include <linux/device.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/vmalloc.h>
|
|
|
|
|
|
2016-04-14 17:59:31 +08:00
|
|
|
#include <linux/scatterlist.h>
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* _devcd_free_sgtable - free all the memory of the given scatterlist table
|
|
|
|
|
* (i.e. both pages and scatterlist instances)
|
|
|
|
|
* NOTE: if two tables allocated and chained using the sg_chain function then
|
|
|
|
|
* this function should be called only once on the first table
|
|
|
|
|
* @table: pointer to sg_table to free
|
|
|
|
|
*/
|
|
|
|
|
static inline void _devcd_free_sgtable(struct scatterlist *table)
|
|
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
struct page *page;
|
|
|
|
|
struct scatterlist *iter;
|
|
|
|
|
struct scatterlist *delete_iter;
|
|
|
|
|
|
|
|
|
|
/* free pages */
|
|
|
|
|
iter = table;
|
|
|
|
|
for_each_sg(table, iter, sg_nents(table), i) {
|
|
|
|
|
page = sg_page(iter);
|
|
|
|
|
if (page)
|
|
|
|
|
__free_page(page);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* then free all chained tables */
|
|
|
|
|
iter = table;
|
|
|
|
|
delete_iter = table; /* always points on a head of a table */
|
|
|
|
|
while (!sg_is_last(iter)) {
|
|
|
|
|
iter++;
|
|
|
|
|
if (sg_is_chain(iter)) {
|
|
|
|
|
iter = sg_chain_ptr(iter);
|
|
|
|
|
kfree(delete_iter);
|
|
|
|
|
delete_iter = iter;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* free the last table */
|
|
|
|
|
kfree(delete_iter);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
#ifdef CONFIG_DEV_COREDUMP
|
2016-04-14 17:59:31 +08:00
|
|
|
void dev_coredumpv(struct device *dev, void *data, size_t datalen,
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
gfp_t gfp);
|
|
|
|
|
|
|
|
|
|
void dev_coredumpm(struct device *dev, struct module *owner,
|
2016-04-14 17:59:31 +08:00
|
|
|
void *data, size_t datalen, gfp_t gfp,
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
ssize_t (*read)(char *buffer, loff_t offset, size_t count,
|
2016-04-14 17:59:31 +08:00
|
|
|
void *data, size_t datalen),
|
|
|
|
|
void (*free)(void *data));
|
|
|
|
|
|
|
|
|
|
void dev_coredumpsg(struct device *dev, struct scatterlist *table,
|
|
|
|
|
size_t datalen, gfp_t gfp);
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
#else
|
2016-04-14 17:59:31 +08:00
|
|
|
static inline void dev_coredumpv(struct device *dev, void *data,
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
size_t datalen, gfp_t gfp)
|
|
|
|
|
{
|
|
|
|
|
vfree(data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
dev_coredumpm(struct device *dev, struct module *owner,
|
2016-04-14 17:59:31 +08:00
|
|
|
void *data, size_t datalen, gfp_t gfp,
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
ssize_t (*read)(char *buffer, loff_t offset, size_t count,
|
2016-04-14 17:59:31 +08:00
|
|
|
void *data, size_t datalen),
|
|
|
|
|
void (*free)(void *data))
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
{
|
|
|
|
|
free(data);
|
|
|
|
|
}
|
2016-04-14 17:59:31 +08:00
|
|
|
|
|
|
|
|
static inline void dev_coredumpsg(struct device *dev, struct scatterlist *table,
|
|
|
|
|
size_t datalen, gfp_t gfp)
|
|
|
|
|
{
|
|
|
|
|
_devcd_free_sgtable(table);
|
|
|
|
|
}
|
device coredump: add new device coredump class
Many devices run firmware and/or complex hardware, and most of that
can have bugs. When it misbehaves, however, it is often much harder
to debug than software running on the host.
Introduce a "device coredump" mechanism to allow dumping internal
device/firmware state through a generalized mechanism. As devices
are different and information needed can vary accordingly, this
doesn't prescribe a file format - it just provides mechanism to
get data to be able to capture it in a generalized way (e.g. in
distributions.)
The dumped data will be readable in sysfs in the virtual device's
data file under /sys/class/devcoredump/devcd*/. Writing to it will
free the data and remove the device, as does a 5-minute timeout.
Note that generalized capturing of such data may result in privacy
issues, so users generally need to be involved. In order to allow
certain users/system integrators/... to disable the feature at all,
introduce a Kconfig option to override the drivers that would like
to have the feature.
For now, this provides two ways of dumping data:
1) with a vmalloc'ed area, that is then given to the subsystem
and freed after retrieval or timeout
2) with a generalized reader/free function method
We could/should add more options, e.g. a list of pages, since the
vmalloc area is very limited on some architectures.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-09-12 15:01:56 +08:00
|
|
|
#endif /* CONFIG_DEV_COREDUMP */
|
|
|
|
|
|
|
|
|
|
#endif /* __DEVCOREDUMP_H */
|