November 2015 - kernelnewbies@kernelnewbies.org

Get user stackpointer from task_struct
by Shirish Gajera Nov. 6, 2015

Nov. 6, 2015

Hi, I have kcore and I want to get userspace backtrace from kcore. I looked at some macro <https://www.kernel.org/doc/Documentation/kdump/gdbmacros.txt> but still this is just giving me kernel backtrace only. What I want is userspace backtrace. Good news is I have pointer to task_struct. task_struct->thread->sp (Kernel stack pointer) task_struct->thread->usersp (user stack pointer) but this is junk My question is how to get userspace backtrace (or stack pointer) from kcore or task_struct ? - Shirish

2 1

How to properly write tests for kernel functions
by Maxim Pugachev Nov. 5, 2015

Nov. 5, 2015

Hi all, I'm trying to understand is there any uniform way to write tests? For example, lib/ folder has a bunch of tests, but all of them use various technics: - pr_warn/pr_err (i.e. printk) or WARN for assertions - just tens of functions that check something, or unified macros - no naming convention for test cases So, I'm wondering, whether there is an example or guidelines that is worth to follow. Thanks!

2 4

[PATCH v3 0/4] SysFS driver for QEMU fw_cfg device
by Gabriel L. Somlo Nov. 4, 2015

Nov. 4, 2015

From: "Gabriel Somlo" <somlo(a)cmu.edu> Allow access to QEMU firmware blobs, passed into the guest VM via the fw_cfg device, through SysFS entries. Blob meta-data (e.g. name, size, and fw_cfg key), as well as the raw binary blob data may be accessed. The SysFS access location is /sys/firmware/qemu_fw_cfg/... and was selected based on overall similarity to the type of information exposed under /sys/firmware/dmi/entries/... NEW (since v2): Using ACPI to detect the presence and details of the fw_cfg virtual hardware device. Device Tree has been suggested by Ard as a comment on v2 of this patch, but after some deliberation I decided to go with ACPI, since it's supported on both x86 and some (uefi-enabled) versions of aarch64. I really don't see how I'd reasonably use *both* DT (on ARM) *and* ACPI (on x86), and after all I'm mostly concerned with x86, but originally wanted to maximize portability (which is where the register probing in earlier versions came from). A patch set generating an ACPI device node for qemu's fw_cfg is currently under review on the qemu-devel list: http://lists.nongnu.org/archive/html/qemu-devel/2015-09/msg06946.html (sorry, gmane appears down at the moment...) In consequence: - Patch 1/4 is mostly the same as in v2; - Patch 2/4 switches device initialization from register probing to using ACPI; this is a separate patch only to illustrate the transition from probing to ACPI, and I'm assuming it will end up squashed on top of patch 1/4 in the final version. - Patches 3/4 and 4/4 add a "human-readable" directory hierarchy built from tokenizing fw_cfg blob names into '/'-separated components, with symlinks to each 'by_key' blob folder (same as in earlier versions). At Greg's suggestion I tried to build this folder hierarchy and leaf symlinks using udev rules, but so far I haven't been successful in figuring that out. If udev turns out to be applicable after all, these two patches can be dropped from this series. In other words, patches 1 and 2 give us the following "by_key" listing of blobs contained in the qemu fw_cfg device (example pulled from a PC qemu guest running Fedora 22), with the value of each "name" attribute shown on the right: $ tree /sys/firmware/qemu_fw_cfg/ /sys/firmware/qemu_fw_cfg/ |-- by_key | |-- 32 | | |-- key | | |-- name ("etc/boot-fail-wait") | | |-- raw | | `-- size | |-- 33 | | |-- key | | |-- name ("etc/smbios/smbios-tables") | | |-- raw | | `-- size | |-- 34 | | |-- key | | |-- name ("etc/smbios/smbios-anchor") | | |-- raw | | `-- size | |-- 35 | | |-- key | | |-- name ("etc/e820") | | |-- raw | | `-- size | |-- 36 | | |-- key | | |-- name ("genroms/kvmvapic.bin") | | |-- raw | | `-- size | |-- 37 | | |-- key | | |-- name ("etc/system-states") | | |-- raw | | `-- size | |-- 38 | | |-- key | | |-- name ("etc/acpi/tables") | | |-- raw | | `-- size | |-- 39 | | |-- key | | |-- name ("etc/table-loader") | | |-- raw | | `-- size | |-- 40 | | |-- key | | |-- name ("etc/tpm/log") | | |-- raw | | `-- size | |-- 41 | | |-- key | | |-- name ("etc/acpi/rsdp") | | |-- raw | | `-- size | `-- 42 | |-- key | |-- name ("bootorder") | |-- raw | `-- size | ... Additionally, patches 3 and 4 (mostly 4) give us the following "user friendly" directory hierarchy as a complement to the above, based on tokenizing each blob name into symlink-tipped (sub)directories: ... |-- by_name | |-- bootorder -> ../by_key/42 | |-- etc | | |-- acpi | | | |-- rsdp -> ../../../by_key/41 | | | `-- tables -> ../../../by_key/38 | | |-- boot-fail-wait -> ../../by_key/32 | | |-- e820 -> ../../by_key/35 | | |-- smbios | | | |-- smbios-anchor -> ../../../by_key/34 | | | `-- smbios-tables -> ../../../by_key/33 | | |-- system-states -> ../../by_key/37 | | |-- table-loader -> ../../by_key/39 | | `-- tpm | | `-- log -> ../../../by_key/40 | `-- genroms | `-- kvmvapic.bin -> ../../by_key/36 `-- rev The trick is to figure out how to replace patches 3 and 4 with a udev rule that would read the contents of each "name" attribute, and build the "by_name" hierarchy and symlinks in userspace. I tried: $ udevadm info -a -p /sys/firmware/qemu_fw_cfg/by_key/33 looking at device '/firmware/qemu_fw_cfg/by_key/33': KERNEL=="33" SUBSYSTEM=="" DRIVER=="" ATTR{key}=="33" ATTR{name}=="etc/smbios/smbios-tables" ATTR{size}=="388" looking at parent device '/firmware/qemu_fw_cfg/by_key': KERNELS=="by_key" SUBSYSTEMS=="" DRIVERS=="" looking at parent device '/firmware/qemu_fw_cfg': KERNELS=="qemu_fw_cfg" SUBSYSTEMS=="" DRIVERS=="" ATTRS{rev}=="1" Then I tried creating a file, /usr/lib/udev/rules.d/99-qemu-fw-cfg.rules containing the following line: KERNELS=="qemu_fw_cfg", ATTRS{rev}=="1", SYMLINK="%p/%s{name}" but NOTHING happens when I insert/remove qemu_fw_cfg.ko. I also tried: KERNELS=="qemu_fw_cfg", ATTRS{rev}=="1", PROGRAM="/foo %k" where "/foo" basically did "echo $* > /tmp/bar", but no /tmp/bar file ever showed up as a consequence of inserting/removing the qemu_fw_cfg.ko module. At this point, I need help figuring out whether udev is really what would get the second, user-friendly, "by_name" /sysfs directory tree created, and how I'd go about that... Thanks much, --Gabriel Gabriel Somlo (4): firmware: introduce sysfs driver for QEMU's fw_cfg device firmware: use acpi to detect QEMU fw_cfg device for sysfs fw_cfg driver kobject: export kset_find_obj() for module use firmware: create directory hierarchy for sysfs fw_cfg entries .../ABI/testing/sysfs-firmware-qemu_fw_cfg | 213 ++++++++ drivers/firmware/Kconfig | 10 + drivers/firmware/Makefile | 1 + drivers/firmware/qemu_fw_cfg.c | 575 +++++++++++++++++++++ lib/kobject.c | 1 + 5 files changed, 800 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-qemu_fw_cfg create mode 100644 drivers/firmware/qemu_fw_cfg.c -- 2.4.3

8 16

Bluetooth doesn't work
by Kinka Huang Nov. 4, 2015

Nov. 4, 2015

Hi all, Thinkpad X1 2015, ubuntu 15.10, the bluetooth module seems not work well. Once connect, it prints the following kernel log: [ 196.730943] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.730946] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.730948] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.740970] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.740975] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 196.740976] Bluetooth: hci0 SCO packet for unknown connection handle 0 [ 201.764755] Bluetooth: hci0 SCO packet for unknown connection handle 257 [ 201.764768] Bluetooth: hci0 SCO packet for unknown connection handle 257 [ 201.764777] Bluetooth: hci0 SCO packet for unknown connection handle 257 and something I think related while kernel initing: [ 3.738275] usbcore: registered new interface driver btusb [ 3.754215] Bluetooth: hci0: read Intel version: 370810011003110e00 [ 3.755429] Adding 7999996k swap on /swap/swapfile. Priority:-1 extents:66 across:13275644k SSFS [ 3.757145] Bluetooth: hci0: Intel Bluetooth firmware file: intel/ibt-hw-37.8.10-fw-1.10.3.11.e.bseq I think it is a good chance for me to diving into the linux kernel, so can anyone offer some hints that I could solve this problem. $ uname -ar Linux kinka-X1 4.3.0-rc7+ #50 SMP Wed Oct 28 22:49:01 CST 2015 x86_64 x86_64 x86_64 GNU/Linux Many thanks~ Kinka

1 0

Mentor
by Ranjith T Nov. 3, 2015

Nov. 3, 2015

Hi, I am Ranjith from India and I would like to contribute something for linux kernel. But I really don't know from where I have to start.(I have submitted linux kernel patch already). Thanks, Ranjith.T.

5 4

Strange warnings out of checkpatch
by John Whitmore Nov. 2, 2015

Nov. 2, 2015

I'm using the MCP2515 driver chip on some work I'm doing. Out of curiosity I ran checkpatch.pl on the C file and don't understand the output. A search sort of seems to suggest that it is a problem with the checkpatch utility itself. http://www.serverphorums.com/read.php?12,1264313 I'd like to understand what is either wrong with code or chcekpatch $ scripts/checkpatch.pl drivers/net/can/spi/mcp251x.c WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) #727: static void mcp251x_error_skb(struct net_device *net, int can_id, int data1) ERROR: Does not appear to be a unified-diff format patch total: 1 errors, 1 warnings, 0 lines checked drivers/net/can/spi/mcp251x.c has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS.

2 3

How to see the preprocessed output of a module source file
by Shiyao Ma Nov. 2, 2015

Nov. 2, 2015

Hi, Say I am writing a module. Instead of directly compile it into a ko file, I'd like to see the preprocessed output of that file, similarly the way it's done in gcc -E. Regards. -- 吾輩は猫である。ホームーページはhttps://introo.me <http://introo.me>。

3 2

How to disable "module verification failed: signature and/or required key missing - tainting kernel" message?
by Nan Xiao Nov. 2, 2015

Nov. 2, 2015

Hi all, When the vendor Linux system enable "kernel module signature verification" mechanism, if install your own built module, the kernel will complain: module verification failed: signature and/or required key missing - tainting kernel After referring this post on SO(http://stackoverflow.com/questions/24975377/kvm-module-verification-fail…, I add "CONFIG_MODULE_SIG=n" at the beginning of Makefile, and rebuild the module. But I find this configuration option doesn't take effect, and "module verification failed: signature and/or required key missing - tainting kernel" message still occurs when first loading the module. Per my understanding, this message shouldn't occur anytime. Could anyone give some clues on this issue? Thanks in advance! Best Regards Nan Xiao

3 6