October 2015 - kernelnewbies@kernelnewbies.org

Re: [PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
by Mark Rutland Oct. 5, 2015

Oct. 5, 2015

On Mon, Oct 05, 2015 at 08:43:46AM -0400, Gabriel L. Somlo wrote: > On Mon, Oct 05, 2015 at 01:23:33PM +0100, Mark Rutland wrote: > > On Mon, Oct 05, 2015 at 01:48:52PM +0200, Paolo Bonzini wrote: > > > > > > > > > On 05/10/2015 12:00, Mark Rutland wrote: > > > > Some of the keys in the example look like they'd come from other sources > > > > (e.g. the *-tables entries), while others look like kernel/bootloader > > > > configuration options (e.g. etc/boot-fail-wait, bootorder) -- I'm > > > > concerned about redundancy here. > > > > > > The redundancy is because the firmware and the bootloader actually > > > _consume_ these fw_cfg strings to produce the others (the ACPI tables, > > > the kernel configuration options). > > > > > > On the other hand, hiding some strings just because they ought to have > > > been consumed already makes little sense. > > > > Sure. However, I'm concerned that providing redundant interfaces for > > those could lead to people grabbing information from here (because it's > > convenient) rather than the existing canonical locations, which means we > > get more software that works on fewer systems for no good reason. > > > > What I couldn't figure out was what _additional_ information this > > provided; it looked like a mixed bag of details we could already get > > from disparate sources. If that's all it does, then it seems to me like > > it doesn't add any benefit and potentially makes things worse. > > > > So what do we get from this interface that we cannot get elsewhere, and > > why is this the best way of exposing it? > > Starting with qemu 2.4, it is possible to insert arbitrary named > blobs into fw_cfg from the qemu command line. *Those* entries > might be interesting to userspace, which is why it might be handy > to access to fw_cfg blobs in general. So this is a mechanism to pass arbitrary key:value pairs to a guest userspace? What would those be used for, and why would this be the correct location for that? How do we avoid clashes between user-selected names and those we need to pass actual FW data? Mark.

2 1

Unset LOCKDEP and TRACE_IRQFLAGS_SUPPORT
by vibnwis Oct. 5, 2015

Oct. 5, 2015

Hi all, I need to unset default value of LOCKDEP(=y) and TRACE_IRQFLAGS_SUPPORT(=y) to both "n". Having asked around and had tried for at least 3 days, seriously I still couldn't get both items configured as "n" Perhaps someone can help me on this item first. For instance, Symbol TRACE_IRQFLAGS description below, to set it, it will need the logics below: PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] && STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] || IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE To unset it, I could either set DEBUG_KERNEL=n or set TRACING_SUPPORT=n (or FTRACE=n). However, having set it, yet I don't see symbol TRACE_IRQFLAGS is unset. Anything wrong of my interpretation of the logics above? Copied from "/" type TRACE_IRQFLAGS in menuconfig │ Symbol: TRACE_IRQFLAGS [=y] │ │ Type : boolean │ │ Defined at lib/Kconfig.debug:1047 │ │ Selected by: PROVE_LOCKING [=y] && DEBUG_KERNEL [=y] && TRACE_IRQFLAGS_SUPPORT [=y] && STACKTRACE_SUPPORT [=y] && LOCKDEP_SUPPORT [=y] || IRQSOFF_TRACER [=n] && TRACING_SUPPORT [=y] && FTRACE [=n │ │ │ │ │ │ Symbol: TRACE_IRQFLAGS_SUPPORT [=y] │ │ Type : boolean │ │ Defined at arch/arm/Kconfig:174 Appreciate any comments. Thanks in advance. Lim

4 24

[PATCH v3 2/4] firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver
by Gabriel L. Somlo Oct. 4, 2015

Oct. 4, 2015

From: Gabriel Somlo <somlo(a)cmu.edu> Instead of blindly probing fw_cfg registers at known IOport and MMIO locations, use the ACPI subsystem to determine whether a QEMU fw_cfg device is present, and, if found, to initialize it. This limits portability to architectures which support ACPI (x86 and UEFI-enabled aarch64), but avoids touching hardware registers before being certain that our device is present. NOTE: The standard way to verify the presence of fw_cfg on arm VMs would have been to use the device tree, but that would have left out x86, which is the primary architecture targeted by this patch. Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 4 + drivers/firmware/Kconfig | 2 +- drivers/firmware/qemu_fw_cfg.c | 201 +++++++++++---------- 3 files changed, 113 insertions(+), 94 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg index f1ef44e..e9761bf 100644 --- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg @@ -76,6 +76,10 @@ Description: the port number of the control register. I.e., the two ports are overlapping, and can not be mapped separately. + NOTE 2. QEMU publishes the register details in the device tree + on arm guests, and in ACPI (under _HID "QEMU0002") on x86 and + select arm (aarch64) VM types. + === Firmware Configuration Items of Interest === Originally, the index key, size, and formatting of blobs in diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index 0466e80..bc12d31 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -137,7 +137,7 @@ config ISCSI_IBFT config FW_CFG_SYSFS tristate "QEMU fw_cfg device support in sysfs" - depends on SYSFS + depends on SYSFS && ACPI default n help Say Y or M here to enable the exporting of the QEMU firmware diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c index 3a67a16..f935afb 100644 --- a/drivers/firmware/qemu_fw_cfg.c +++ b/drivers/firmware/qemu_fw_cfg.c @@ -8,6 +8,7 @@ */ #include <linux/module.h> +#include <linux/acpi.h> #include <linux/slab.h> #include <linux/io.h> #include <linux/ioport.h> @@ -35,53 +36,10 @@ struct fw_cfg_file { char name[FW_CFG_MAX_FILE_PATH]; }; -/* fw_cfg device i/o access options type */ -struct fw_cfg_access { - const char *name; - phys_addr_t base; - u8 size; - u8 ctrl_offset; - u8 data_offset; - bool is_mmio; -}; - -/* table of fw_cfg device i/o access options for known architectures */ -static struct fw_cfg_access fw_cfg_modes[] = { - { - .name = "fw_cfg IOport on i386, sun4u", - .base = 0x510, - .size = 0x02, - .ctrl_offset = 0x00, - .data_offset = 0x01, - .is_mmio = false, - }, { - .name = "fw_cfg MMIO on arm", - .base = 0x9020000, - .size = 0x0a, - .ctrl_offset = 0x08, - .data_offset = 0x00, - .is_mmio = true, - }, { - .name = "fw_cfg MMIO on sun4m", - .base = 0xd00000510, - .size = 0x03, - .ctrl_offset = 0x00, - .data_offset = 0x02, - .is_mmio = true, - }, { - .name = "fw_cfg MMIO on ppc/mac", - .base = 0xf0000510, - .size = 0x03, - .ctrl_offset = 0x00, - .data_offset = 0x02, - .is_mmio = true, - }, { } /* END */ -}; - -/* fw_cfg device i/o currently selected option set */ -static struct fw_cfg_access *fw_cfg_mode; - /* fw_cfg device i/o register addresses */ +static bool fw_cfg_is_mmio; +static phys_addr_t fw_cfg_phys_base; +static u32 fw_cfg_phys_size; static void __iomem *fw_cfg_dev_base; static void __iomem *fw_cfg_reg_ctrl; static void __iomem *fw_cfg_reg_data; @@ -92,7 +50,7 @@ static DEFINE_MUTEX(fw_cfg_dev_lock); /* pick appropriate endianness for selector key */ static inline u16 fw_cfg_sel_endianness(u16 key) { - return fw_cfg_mode->is_mmio ? cpu_to_be16(key) : cpu_to_le16(key); + return fw_cfg_is_mmio ? cpu_to_be16(key) : cpu_to_le16(key); } /* type for fw_cfg "directory scan" visitor/callback function */ @@ -133,60 +91,100 @@ static inline void fw_cfg_read_blob(u16 key, /* clean up fw_cfg device i/o */ static void fw_cfg_io_cleanup(void) { - if (fw_cfg_mode->is_mmio) { + if (fw_cfg_is_mmio) { iounmap(fw_cfg_dev_base); - release_mem_region(fw_cfg_mode->base, fw_cfg_mode->size); + release_mem_region(fw_cfg_phys_base, fw_cfg_phys_size); } else { ioport_unmap(fw_cfg_dev_base); - release_region(fw_cfg_mode->base, fw_cfg_mode->size); + release_region(fw_cfg_phys_base, fw_cfg_phys_size); } } -/* probe and map fw_cfg device */ -static int __init fw_cfg_io_probe(void) +/* configure fw_cfg device i/o from ACPI _CRS method */ +static acpi_status fw_cfg_walk_crs(struct acpi_resource *r, void *context) +{ + struct acpi_resource_io *io; + struct acpi_resource_fixed_memory32 *mmio; + + switch (r->type) { + case ACPI_RESOURCE_TYPE_END_TAG: + return AE_OK; + case ACPI_RESOURCE_TYPE_IO: + io = &r->data.io; + /* physical base addr should NOT be already set */ + if (fw_cfg_phys_base) + return AE_ERROR; + if (!request_region(io->minimum, + io->address_length, "fw_cfg_io")) + return AE_ERROR; + fw_cfg_dev_base = ioport_map(io->minimum, io->address_length); + if (!fw_cfg_dev_base) { + release_region(io->minimum, io->address_length); + return AE_ERROR; + } + fw_cfg_phys_base = io->minimum; + fw_cfg_phys_size = io->address_length; + fw_cfg_is_mmio = false; + /* set register addresses (pc/i386 offsets) */ + fw_cfg_reg_ctrl = fw_cfg_dev_base + 0x00; + fw_cfg_reg_data = fw_cfg_dev_base + 0x01; + return AE_OK; + case ACPI_RESOURCE_TYPE_FIXED_MEMORY32: + mmio = &r->data.fixed_memory32; + /* physical base addr should NOT be already set */ + if (fw_cfg_phys_base) + return AE_ERROR; + /* MMIO and ACPI, but not on ARM ?!?! */ + if (mmio->address_length < 0x0a) + return AE_ERROR; + if (!request_mem_region(mmio->address, + mmio->address_length, "fw_cfg_mem")) + return AE_ERROR; + fw_cfg_dev_base = ioremap(mmio->address, mmio->address_length); + if (!fw_cfg_dev_base) { + release_mem_region(mmio->address, mmio->address_length); + return AE_ERROR; + } + fw_cfg_phys_base = mmio->address; + fw_cfg_phys_size = mmio->address_length; + fw_cfg_is_mmio = true; + /* set register addresses (arm offsets) */ + fw_cfg_reg_ctrl = fw_cfg_dev_base + 0x08; + fw_cfg_reg_data = fw_cfg_dev_base + 0x00; + return AE_OK; + default: + return AE_ERROR; + } +} + +/* initialize fw_cfg device i/o from ACPI data */ +static int fw_cfg_acpi_init(struct acpi_device *dev) { char sig[FW_CFG_SIG_SIZE]; + acpi_status status; + int err; - for (fw_cfg_mode = &fw_cfg_modes[0]; - fw_cfg_mode->base; fw_cfg_mode++) { - - phys_addr_t base = fw_cfg_mode->base; - u8 size = fw_cfg_mode->size; - - /* reserve and map mmio or ioport region */ - if (fw_cfg_mode->is_mmio) { - if (!request_mem_region(base, size, fw_cfg_mode->name)) - continue; - fw_cfg_dev_base = ioremap(base, size); - if (!fw_cfg_dev_base) { - release_mem_region(base, size); - continue; - } - } else { - if (!request_region(base, size, fw_cfg_mode->name)) - continue; - fw_cfg_dev_base = ioport_map(base, size); - if (!fw_cfg_dev_base) { - release_region(base, size); - continue; - } - } + err = acpi_bus_get_status(dev); + if (err < 0) + return err; - /* set control and data register addresses */ - fw_cfg_reg_ctrl = fw_cfg_dev_base + fw_cfg_mode->ctrl_offset; - fw_cfg_reg_data = fw_cfg_dev_base + fw_cfg_mode->data_offset; + if (!(dev->status.enabled && dev->status.functional)) + return -ENODEV; - /* verify fw_cfg device signature */ - fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE); - if (memcmp(sig, "QEMU", FW_CFG_SIG_SIZE) == 0) - /* success, we're done */ - return 0; + /* extract device i/o details from _CRS */ + status = acpi_walk_resources(dev->handle, METHOD_NAME__CRS, + fw_cfg_walk_crs, NULL); + if (status != AE_OK || !fw_cfg_phys_base) + return -ENODEV; - /* clean up before probing next access mode */ + /* verify fw_cfg device signature */ + fw_cfg_read_blob(FW_CFG_SIGNATURE, sig, 0, FW_CFG_SIG_SIZE); + if (memcmp(sig, "QEMU", FW_CFG_SIG_SIZE) != 0) { fw_cfg_io_cleanup(); + return -ENODEV; } - return -ENODEV; + return 0; } /* fw_cfg revision attribute, in /sys/firmware/qemu_fw_cfg top-level dir. */ @@ -353,7 +351,7 @@ static struct kobject *fw_cfg_top_ko; static struct kobject *fw_cfg_sel_ko; /* callback function to register an individual fw_cfg file */ -static int __init fw_cfg_register_file(const struct fw_cfg_file *f) +static int fw_cfg_register_file(const struct fw_cfg_file *f) { int err; struct fw_cfg_sysfs_entry *entry; @@ -397,12 +395,12 @@ static inline void fw_cfg_kobj_cleanup(struct kobject *kobj) kobject_put(kobj); } -static int __init fw_cfg_sysfs_init(void) +static int fw_cfg_sysfs_add(struct acpi_device *dev) { int err; - /* probe for the fw_cfg "hardware" */ - err = fw_cfg_io_probe(); + /* initialize fw_cfg device i/o from ACPI data */ + err = fw_cfg_acpi_init(dev); if (err) return err; @@ -443,14 +441,31 @@ err_top: return err; } -static void __exit fw_cfg_sysfs_exit(void) +static int fw_cfg_sysfs_remove(struct acpi_device *dev) { pr_debug("fw_cfg: unloading.\n"); fw_cfg_sysfs_cache_cleanup(); fw_cfg_kobj_cleanup(fw_cfg_sel_ko); fw_cfg_kobj_cleanup(fw_cfg_top_ko); fw_cfg_io_cleanup(); + return 0; } -module_init(fw_cfg_sysfs_init); -module_exit(fw_cfg_sysfs_exit); +static const struct acpi_device_id fw_cfg_sysfs_device_ids[] = { + { "QEMU0002", 0 }, + { "", 0 }, +}; +MODULE_DEVICE_TABLE(acpi, fw_cfg_sysfs_device_ids); + +static struct acpi_driver fw_cfg_sysfs_driver = { + .name = "fw_cfg", + .class = "QEMU", + .ids = fw_cfg_sysfs_device_ids, + .ops = { + .add = fw_cfg_sysfs_add, + .remove = fw_cfg_sysfs_remove, + }, + .owner = THIS_MODULE, +}; + +module_acpi_driver(fw_cfg_sysfs_driver); -- 2.4.3

2 3

Logging communication with devices
by Peter Senna Tschudin Oct. 4, 2015

Oct. 4, 2015

Does Linux provide an elegant and/or standard way of logging communication with devices that manage buffers and that can help me improve code like: $ cat drivers/usb/host/fotg210-hcd.c ... temp = snprintf(next, size, "\n\t%p%c%s len=%d %08x urb %p", td, mark, ({ char *tmp; switch ((scratch>>8)&0x03) { case 0: tmp = "out"; break; case 1: tmp = "in"; break; case 2: tmp = "setup"; break; default: tmp = "?"; break; } tmp; }), (scratch >> 16) & 0x7fff, scratch, td->urb); -- Peter

2 1

[PATCH v3 4/4] firmware: create directory hierarchy for sysfs fw_cfg entries
by Gabriel L. Somlo Oct. 3, 2015

Oct. 3, 2015

From: Gabriel Somlo <somlo(a)cmu.edu> Each fw_cfg entry of type "file" has an associated 56-char, nul-terminated ASCII string which represents its name. While the fw_cfg device doesn't itself impose any specific naming convention, QEMU developers have traditionally used path name semantics (i.e. "etc/acpi/rsdp") to descriptively name the various fw_cfg "blobs" passed into the guest. This patch attempts, on a best effort basis, to create a directory hierarchy representing the content of fw_cfg file names, under /sys/firmware/qemu_fw_cfg/by_name. Upon successful creation of all directories representing the "dirname" portion of a fw_cfg file, a symlink will be created to represent the "basename", pointing at the appropriate /sys/firmware/qemu_fw_cfg/by_key entry. If a file name is not suitable for this procedure (e.g., if its basename or dirname components collide with an already existing dirname component or basename, respectively) the corresponding fw_cfg blob is skipped and will remain available in sysfs only by its selector key value. Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 42 +++++++++ drivers/firmware/qemu_fw_cfg.c | 104 +++++++++++++++++++++ 2 files changed, 146 insertions(+) diff --git a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg index e9761bf..2e3eaba 100644 --- a/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg +++ b/Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg @@ -169,3 +169,45 @@ Description: entry via the control register, and reading a number of bytes equal to the blob size from the data register. + + --- Listing fw_cfg blobs by file name --- + + While the fw_cfg device does not impose any specific naming + convention on the blobs registered in the file directory, + QEMU developers have traditionally used path name semantics + to give each blob a descriptive name. For example: + + "bootorder" + "genroms/kvmvapic.bin" + "etc/e820" + "etc/boot-fail-wait" + "etc/system-states" + "etc/table-loader" + "etc/acpi/rsdp" + "etc/acpi/tables" + "etc/smbios/smbios-tables" + "etc/smbios/smbios-anchor" + ... + + In addition to the listing by unique selector key described + above, the fw_cfg sysfs driver also attempts to build a tree + of directories matching the path name components of fw_cfg + blob names, ending in symlinks to the by_key entry for each + "basename", as illustrated below (assume current directory is + /sys/firmware): + + qemu_fw_cfg/by_name/bootorder -> ../by_key/38 + qemu_fw_cfg/by_name/etc/e820 -> ../../by_key/35 + qemu_fw_cfg/by_name/etc/acpi/rsdp -> ../../../by_key/41 + ... + + Construction of the directory tree and symlinks is done on a + "best-effort" basis, as there is no guarantee that components + of fw_cfg blob names are always "well behaved". I.e., there is + the possibility that a symlink (basename) will conflict with + a dirname component of another fw_cfg blob, in which case the + creation of the offending /sys/firmware/qemu_fw_cfg/by_name + entry will be skipped. + + The authoritative list of entries will continue to be found + under the /sys/firmware/qemu_fw_cfg/by_key directory. diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c index f935afb..880f8ff 100644 --- a/drivers/firmware/qemu_fw_cfg.c +++ b/drivers/firmware/qemu_fw_cfg.c @@ -346,9 +346,104 @@ static struct bin_attribute fw_cfg_sysfs_attr_raw = { .read = fw_cfg_sysfs_read_raw, }; +/* + * Create a kset subdirectory matching each '/' delimited dirname token + * in 'name', starting with sysfs kset/folder 'dir'; At the end, create + * a symlink directed at the given 'target'. + * NOTE: We do this on a best-effort basis, since 'name' is not guaranteed + * to be a well-behaved path name. Whenever a symlink vs. kset directory + * name collision occurs, the kernel will issue big scary warnings while + * refusing to add the offending link or directory. We follow up with our + * own, slightly less scary error messages explaining the situation :) + */ +static int __init fw_cfg_build_symlink(struct kset *dir, + struct kobject *target, + const char *name) +{ + int ret; + struct kset *subdir; + struct kobject *ko; + char *name_copy, *p, *tok; + + if (!dir || !target || !name || !*name) + return -EINVAL; + + /* clone a copy of name for parsing */ + name_copy = p = kstrdup(name, GFP_KERNEL); + if (!name_copy) + return -ENOMEM; + + /* create folders for each dirname token, then symlink for basename */ + while ((tok = strsep(&p, "/")) && *tok) { + + /* last (basename) token? If so, add symlink here */ + if (!p || !*p) { + ret = sysfs_create_link(&dir->kobj, target, tok); + break; + } + + /* does the current dir contain an item named after tok ? */ + ko = kset_find_obj(dir, tok); + if (ko) { + /* drop reference added by kset_find_obj */ + kobject_put(ko); + + /* ko MUST be a kset - we're about to use it as one ! */ + if (ko->ktype != dir->kobj.ktype) { + ret = -EINVAL; + break; + } + + /* descend into already existing subdirectory */ + dir = to_kset(ko); + } else { + /* create new subdirectory kset */ + subdir = kzalloc(sizeof(struct kset), GFP_KERNEL); + if (!subdir) { + ret = -ENOMEM; + break; + } + subdir->kobj.kset = dir; + subdir->kobj.ktype = dir->kobj.ktype; + ret = kobject_set_name(&subdir->kobj, "%s", tok); + if (ret) { + kfree(subdir); + break; + } + ret = kset_register(subdir); + if (ret) { + kfree(subdir); + break; + } + + /* descend into newly created subdirectory */ + dir = subdir; + } + } + + /* we're done with cloned copy of name */ + kfree(name_copy); + return ret; +} + +/* recursively unregister fw_cfg/by_name/ kset directory tree */ +static void fw_cfg_kset_unregister_recursive(struct kset *kset) +{ + struct kobject *k, *next; + + list_for_each_entry_safe(k, next, &kset->list, entry) + /* all set members are ksets too, but check just in case... */ + if (k->ktype == kset->kobj.ktype) + fw_cfg_kset_unregister_recursive(to_kset(k)); + + /* symlinks are cleanly and automatically removed with the directory */ + kset_unregister(kset); +} + /* kobjects & kset representing top-level, by_key, and by_name folders */ static struct kobject *fw_cfg_top_ko; static struct kobject *fw_cfg_sel_ko; +static struct kset *fw_cfg_fname_kset; /* callback function to register an individual fw_cfg file */ static int fw_cfg_register_file(const struct fw_cfg_file *f) @@ -377,6 +472,9 @@ static int fw_cfg_register_file(const struct fw_cfg_file *f) if (err) goto err_add_raw; + /* try adding "/sys/firmware/qemu_fw_cfg/by_name/" symlink */ + fw_cfg_build_symlink(fw_cfg_fname_kset, &entry->kobj, entry->f.name); + /* success, add entry to global cache */ fw_cfg_sysfs_cache_enlist(entry); return 0; @@ -412,6 +510,9 @@ static int fw_cfg_sysfs_add(struct acpi_device *dev) fw_cfg_sel_ko = kobject_create_and_add("by_key", fw_cfg_top_ko); if (!fw_cfg_sel_ko) goto err_sel; + fw_cfg_fname_kset = kset_create_and_add("by_name", NULL, fw_cfg_top_ko); + if (!fw_cfg_fname_kset) + goto err_name; /* get revision number, add matching top-level attribute */ fw_cfg_read_blob(FW_CFG_ID, &fw_cfg_rev, 0, sizeof(fw_cfg_rev)); @@ -433,6 +534,8 @@ err_scan: fw_cfg_sysfs_cache_cleanup(); sysfs_remove_file(fw_cfg_top_ko, &fw_cfg_rev_attr.attr); err_rev: + fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset); +err_name: fw_cfg_kobj_cleanup(fw_cfg_sel_ko); err_sel: fw_cfg_kobj_cleanup(fw_cfg_top_ko); @@ -445,6 +548,7 @@ static int fw_cfg_sysfs_remove(struct acpi_device *dev) { pr_debug("fw_cfg: unloading.\n"); fw_cfg_sysfs_cache_cleanup(); + fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset); fw_cfg_kobj_cleanup(fw_cfg_sel_ko); fw_cfg_kobj_cleanup(fw_cfg_top_ko); fw_cfg_io_cleanup(); -- 2.4.3

1 0

[PATCH v3 3/4] kobject: export kset_find_obj() for module use
by Gabriel L. Somlo Oct. 3, 2015

Oct. 3, 2015

From: Gabriel Somlo <somlo(a)cmu.edu> Signed-off-by: Gabriel Somlo <somlo(a)cmu.edu> --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/kobject.c b/lib/kobject.c index 3e3a5c3..bea2c9b 100644 --- a/lib/kobject.c +++ b/lib/kobject.c @@ -842,6 +842,7 @@ struct kobject *kset_find_obj(struct kset *kset, const char *name) spin_unlock(&kset->list_lock); return ret; } +EXPORT_SYMBOL(kset_find_obj); static void kset_release(struct kobject *kobj) { -- 2.4.3

1 0

Re: Translating physical/linear address to virtual address
by Martin Ichilevici de Oliveira Oct. 3, 2015

Oct. 3, 2015

Hello Anish, On Fri, Oct 02, 2015 at 08:37:25PM -0700, anish singh wrote: > On Fri, Oct 2, 2015 at 12:58 PM, martin <iomartin(a)iomartin.net> wrote: > > > Hello, > > > > I'm working with a kernel module that, through hardware events, gets a > > list of physical and linear memory addresses accessed by a program. I > > would like to convert these to the virtual addresses, as seen from the > > user space. > > > > what are you trying to achieve? I'm collecting some stats about these addresses, namely the amount of accesses to each page that happen under specific conditions (and thus why I use hardware events, instead of a simple memory trace). My goal is to use this data to make informed decisions on pages distribution in NUMA machines (with libnuma). The problem is that, as far as I understood, physical and linear addresses won't necessarily be the same between runs of the same program. Virtual addresses, on the other hand, can be made to be consistent (by turning address space layout randomization off). Using virtual addresses also have the advantage that I can do all memory management in userspace, with libnuma. Thank you, Martin

2 1

Translating physical/linear address to virtual address
by martin Oct. 2, 2015

Oct. 2, 2015

Hello, I'm working with a kernel module that, through hardware events, gets a list of physical and linear memory addresses accessed by a program. I would like to convert these to the virtual addresses, as seen from the user space. I saw there's phys_to_virt(), but as I understood it's only valid for kernel addresses. What would be the correct approach? Pointers to the correct structs and functions are greatly appreciated. Thank you. Martin

1 0

Can I send a patch about 00-INDEX?
by Navy Cheng Oct. 2, 2015

Oct. 2, 2015

Hi, I read some document about schedule in Documentation/schedule/ but I find that there are 9 files in 00-INDEX (include itself), however there are 10 files in the Documentation/schedule/* . *completoin.txt* is added in 2015 and 00-INDEX is not include it. Should I send a patch like this? Thank you?

2 1

In SMP system, is there any api to disable IRQ for all CPUs?
by loody Oct. 2, 2015

Oct. 2, 2015

hi all: is there any kernel API can let IRQ disable for all CPU in SMP system for a while? I just need it for a experiment on my module. such as: xxxx --> disable SMP all cpu IRQ OOO ---> no interrupt happen OOO ---> no interrupt happen zzzz ---> enable SMP all cou IRQ Appreciate your kind help in advance,

2 1