address mapping from one process to another in Linux - linux

Can this be done? Process A does x = malloc(...). x is the virtual address from process A's address space (heap). I want a system call, which takes x and unmap's it from process A's address space, and maps it to the virtual address space of process B.
Would virt_to_phys() and phys_to_virt() work? virt_to_phys() would be done in process A's context and phys_to_virt() in process B's context. Am I making any sense? I did not dive deeply into address mapping mechanisms in the Linux kernel.

You can do this using POSIX shared memory
Process 1
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/types.h>
#include <stdlib.h>
int main()
{
unsigned char *shared_byte;
int shmfd = shm_open("/test_object", O_CREAT | O_RDWR, S_IRUSR | S_IWUSR);
ftruncate(shmfd, 1);
shared_byte = mmap(NULL, 1, PROT_READ | PROT_WRITE, MAP_SHARED, shmfd, 0);
*shared_byte = 123;
for(;;);
}
Compile and run:
$ cc proc1.c -o proc1 -lrt
$ ./proc1 &
[1] 5381
Inspect the process map:
$ pmap 5381
5381: ./proc1
08048000 4K r-x-- proc1
08049000 4K rw--- proc1
b7540000 8K rw--- [ anon ]
b7542000 100K r-x-- libpthread-2.22.so
b755b000 4K r---- libpthread-2.22.so
b755c000 4K rw--- libpthread-2.22.so
b755d000 8K rw--- [ anon ]
b755f000 1728K r-x-- libc-2.22.so
b770f000 4K ----- libc-2.22.so
b7710000 8K r---- libc-2.22.so
b7712000 4K rw--- libc-2.22.so
b7713000 12K rw--- [ anon ]
b7716000 28K r-x-- librt-2.22.so
b771d000 4K r---- librt-2.22.so
b771e000 4K rw--- librt-2.22.so
b7724000 4K rw-s- test_object
b7725000 4K rw--- [ anon ]
b7726000 8K r---- [ anon ]
b7728000 4K r-x-- [ anon ]
b7729000 136K r-x-- ld-2.22.so
b774b000 4K r---- ld-2.22.so
b774c000 4K rw--- ld-2.22.so
bfe7f000 132K rw--- [ stack ]
total 2220K
Notice that there is a 4k test_object mapped to the virtual address space of process 1.
Process 2
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>
int main()
{
unsigned char *shared_byte;
int shmfd = shm_open("/test_object", O_RDONLY, 0);
shared_byte = mmap(NULL, 1, PROT_READ, MAP_SHARED, shmfd, 0);
printf("%d\n", *shared_byte);
for(;;);
}
Compile and run:
$ cc proc2.c -o proc2 -lrt
$ ./proc2 &
[2] 5397
123
Notice the "123" value is there from the first program.
Inspect the process map:
$ pmap 5397
5397: ./proc2
08048000 4K r-x-- proc2
08049000 4K rw--- proc2
b7555000 8K rw--- [ anon ]
b7557000 100K r-x-- libpthread-2.22.so
b7570000 4K r---- libpthread-2.22.so
b7571000 4K rw--- libpthread-2.22.so
b7572000 8K rw--- [ anon ]
b7574000 1728K r-x-- libc-2.22.so
b7724000 4K ----- libc-2.22.so
b7725000 8K r---- libc-2.22.so
b7727000 4K rw--- libc-2.22.so
b7728000 12K rw--- [ anon ]
b772b000 28K r-x-- librt-2.22.so
b7732000 4K r---- librt-2.22.so
b7733000 4K rw--- librt-2.22.so
b7738000 4K rw--- [ anon ]
b7739000 4K r--s- test_object
b773a000 4K rw--- [ anon ]
b773b000 8K r---- [ anon ]
b773d000 4K r-x-- [ anon ]
b773e000 136K r-x-- ld-2.22.so
b7760000 4K r---- ld-2.22.so
b7761000 4K rw--- ld-2.22.so
bffbf000 132K rw--- [ stack ]
total 2224K
Notice that there is a 4k test_object mapped to the virtual address space of process 2.
Cleanup
$ killall proc1
[1]- Terminated ./proc1
$ killall proc2
[2]+ Terminated ./proc2
$ cat > clean.c << EOF
#include <sys/mman.h>
#include <sys/stat.h>
#include <fcntl.h>
int main()
{
shm_unlink("/test_object");
}
EOF
$ cc clean.c -o clean -lrt
$ ./clean

Related

glibc Arena system_mem does not add up to the amount of VSS or RSS

I have a process where I'm trying to account for where all the memory is going. My first thought was to iterate through all the arenas with gdb and output their system memory like so (I've configured the process to 32 arenas):
define arenaSizeWalk
set var $n = main_arena
set var $size = 0
set var $count = 0
while $count < 32
set var $size = $n.system_mem
set var $n = $n.next
set var $count = $count + 1
printf "%d\n", $size
end
end
However, this comes up quite short. This adds up to ~3GB. But my total memory footprint as gleaned from pmap (excluding stack guards and loaded libraries) is to the tune of 25GB.
Moreover, I used gdb-heap to dump all the memory chunks and compared them to the output from pmap
From heap all:
...
39: 0x00007fc1840c8000 -> 0x00007fc1841c8fff inuse: 1052672 bytes (<MChunkPtr chunk=0x7fc1840c8000 mem=0x7fc1840c8010 prev_size=0 IS_MMAPPED chunksize=1052672 memsize=1052656>)
40: 0x00007fc1841c9000 -> 0x00007fc184649fff inuse: 4722688 bytes (<MChunkPtr chunk=0x7fc1841c9000 mem=0x7fc1841c9010 prev_size=0 IS_MMAPPED chunksize=4722688 memsize=4722672>)
41: 0x00007fc18464a000 -> 0x00007fc18474afff inuse: 1052672 bytes (<MChunkPtr chunk=0x7fc18464a000 mem=0x7fc18464a010 prev_size=0 IS_MMAPPED chunksize=1052672 memsize=1052656>)
42: 0x00007fc1d401b000 -> 0x00007fc1d4044fff inuse: 172032 bytes (<MChunkPtr chunk=0x7fc1d401b000 mem=0x7fc1d401b010 prev_size=0 IS_MMAPPED chunksize=172032 memsize=172016>)
...
From pmap:
00007fc1840c8000 6668K rw--- [ anon ]
00007fc18474c000 1024K rw--- [ anon ]
00007fc18484d000 1024K rw--- [ anon ]
00007fc18494e000 1024K rw--- [ anon ]
00007fc184a4f000 1024K rw--- [ anon ]
00007fc184b50000 1024K rw--- [ anon ]
00007fc184c51000 1024K rw--- [ anon ]
00007fc184d52000 1024K rw--- [ anon ]
00007fc184e53000 1024K rw--- [ anon ]
00007fc184f54000 1024K rw--- [ anon ]
Chunk 42 there leaped in address space from 7fc18... -> 7fc18d. Meanwhile, we have these pmapped addresses proceeding after 07fc1840c8000 that don't seem to be accounted for with existing chunks.
I'm using glibc 2.17 under RHEL7. Am I missing something??? How can I have memory regions that don't seem to be accounted for by the system default malloc implementation? Or perhaps I've grossly misunderstood something somewheres. And how am I so short on the memory accounting?
Thanks in advance!!
I figured this out. The reason why memory regions were not traceable in this manner was because some other parts of the program were calling mmap() directly as opposed to using malloc() or new.
Only those allocations that interface with malloc will be traceable by examining the main_arena or utilizing gdb-heap.

Debug stack from kernel module

I write kernel module to debug user processes' stack's. I found a way to get pointer to stack using mm field from task_struct structure, but when I try read value from stack adress my module is crashed.
Code (for existing process with pid 860):
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/pid.h>
#include <linux/proc_fs.h>
struct task_struct *ed_task;
long int *val;
void *stack_p;
int i = 0;
static int __init init(void)
{
ed_task = pid_task(find_vpid(860), PIDTYPE_PID);
stack_p = (void *) ed_task->mm->start_stack;
printk("stack %d: %p", i, stack_p);
val = stack_p - sizeof(void *);
printk("stack %d value: %ld", i, *val);
printk(">");
return 0;
}
static void __exit modex(void)
{
}
module_init(init);
module_exit(modex);
MODULE_LICENSE("GPL");
Error:
[ 2714.296489] stack 0: 00007fffbd922e30
[ 2714.296495] BUG: unable to handle kernel paging request at 00007fffbd922e28
[ 2714.297844] IP: init+0x65/0x1000 [main3]
[ 2714.299017] PGD 10140d067
[ 2714.299019] P4D 10140d067
[ 2714.300188] PUD 0
[ 2714.303364] Oops: 0000 [#4] PREEMPT SMP
[ 2714.306523] Modules linked in: main3(O+) main1(O+) main(O+) main2(O+) rndis_host cdc_ether usbnet mii fuse rfcomm bnep nls_iso8859_1 nls_cp437 vfat fat intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm hp_wmi irqbypass iTCO_wdt mousedev sparse_keymap iTCO_vendor_support ppdev joydev mei_wdt btusb crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel btrtl pcbc btbcm aesni_intel btintel bluetooth evdev input_leds aes_x86_64 uvcvideo crypto_simd glue_helper cryptd videobuf2_vmalloc intel_cstate intel_rapl_perf videobuf2_memops ecdh_generic pcspkr videobuf2_v4l2 videobuf2_core videodev media psmouse mac_hid hid_generic arc4 nouveau iwldvm mac80211 mxm_wmi iwlwifi ttm cfg80211 drm_kms_helper drm rfkill syscopyarea sysfillrect snd_hda_codec_hdmi sysimgblt snd_hda_codec_idt
[ 2714.312788] snd_hda_codec_generic fb_sys_fops snd_hda_intel i2c_algo_bit snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore parport_pc thermal tpm_infineon hp_accel ac e1000e lis3lv02d parport wmi mei_me mei input_polldev battery video ptp pps_core button lpc_ich shpchp tpm_tis tpm_tis_core tpm sch_fq_codel vboxnetflt(O) vboxnetadp(O) pci_stub vboxpci(O) vboxdrv(O) sg ip_tables x_tables ext4 crc16 jbd2 fscrypto mbcache sr_mod cdrom sd_mod usbhid hid serio_raw atkbd libps2 ahci libahci libata scsi_mod firewire_ohci xhci_pci xhci_hcd sdhci_pci sdhci ehci_pci led_class ehci_hcd firewire_core mmc_core crc_itu_t usbcore usb_common i8042 serio [last unloaded: main]
[ 2714.318036] CPU: 3 PID: 6244 Comm: insmod Tainted: G D O 4.12.4-1-ARCH #1
[ 2714.319130] Hardware name: Hewlett-Packard HP EliteBook 8560w/1631, BIOS 68SVD Ver. F.60 03/12/2015
[ 2714.320246] task: ffff917ea5819c80 task.stack: ffff9f90455c8000
[ 2714.321406] RIP: 0010:init+0x65/0x1000 [main3]
[ 2714.322524] RSP: 0018:ffff9f90455cbc90 EFLAGS: 00010286
[ 2714.323684] RAX: 00007fffbd922e30 RBX: 0000000000000000 RCX: ffffffff8ba55a68
[ 2714.324813] RDX: 00007fffbd922e28 RSI: 0000000000000000 RDI: ffffffffc0f08031
[ 2714.325937] RBP: ffff9f90455cbc90 R08: 000000000000044b R09: ffffffff8bca0940
[ 2714.327040] R10: fffff2d0c2ecac40 R11: 0000000000000000 R12: ffffffffc0498000
[ 2714.328142] R13: ffff917e6ee4c480 R14: ffffffffc0f09050 R15: ffff917f06e24660
[ 2714.329279] FS: 00007f8999054b80(0000) GS:ffff917f3dcc0000(0000) knlGS:0000000000000000
[ 2714.330389] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2714.331516] CR2: 00007fffbd922e28 CR3: 000000010150f000 CR4: 00000000000406e0
[ 2714.332652] Call Trace:
[ 2714.333810] do_one_initcall+0x50/0x190
[ 2714.334945] ? do_init_module+0x27/0x1e6
[ 2714.336065] do_init_module+0x5f/0x1e6
[ 2714.337197] load_module+0x2610/0x2ab0
[ 2714.338349] ? vfs_read+0x115/0x130
[ 2714.339469] SYSC_finit_module+0xf6/0x110
[ 2714.340574] ? SYSC_finit_module+0xf6/0x110
[ 2714.341675] SyS_finit_module+0xe/0x10
[ 2714.342782] entry_SYSCALL_64_fastpath+0x1a/0xa5
[ 2714.343899] RIP: 0033:0x7f8998765bb9
[ 2714.344988] RSP: 002b:00007ffc068a0528 EFLAGS: 00000206 ORIG_RAX: 0000000000000139
[ 2714.346111] RAX: ffffffffffffffda RBX: 00007f8998a26aa0 RCX: 00007f8998765bb9
[ 2714.347203] RDX: 0000000000000000 RSI: 000000000041aada RDI: 0000000000000003
[ 2714.348279] RBP: 00007f8998a26af8 R08: 0000000000000000 R09: 00007f8998a28e40
[ 2714.349368] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000001020
[ 2714.350441] R13: 0000000000001018 R14: 00007f8998a26af8 R15: 0000000000000001
[ 2714.351524] Code: 48 89 15 07 13 a7 00 e8 8d 11 cf ca 48 8b 05 fb 12 a7 00 8b 35 ed 12 a7 00 48 c7 c7 31 80 f0 c0 48 8d 50 f8 48 89 15 eb 12 a7 00 <48> 8b 50 f8 e8 65 11 cf ca 48 c7 c7 45 80 f0 c0 e8 59 11 cf ca
[ 2714.353786] RIP: init+0x65/0x1000 [main3] RSP: ffff9f90455cbc90
[ 2714.354914] CR2: 00007fffbd922e28
[ 2714.356130] ---[ end trace a150fd8aba7bd1e3 ]---
Why it doesn't work? Are stacks have any special memory protection or something wrong am I doing?
You cannot directly access userspace memory from the kernel space. In order to do so, you need to use the kernel provided API function copy_from_user().
Modifying your code to make use of this API should work:
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/sched.h>
#include <linux/pid.h>
#include <linux/proc_fs.h>
#include <linux/uaccess.h> // Header file corresponding to copy_from_user()
struct task_struct *ed_task;
long int *valp; // Pointer to destination kernel memory
long int val; // Destination kernel memory
void *stack_p;
int i = 0;
static int __init init(void)
{
ed_task = pid_task(find_vpid(2298), PIDTYPE_PID);
stack_p = (void *) ed_task->mm->start_stack;
printk("stack %d: %p\n", i, stack_p);
valp = stack_p - sizeof(void *);
copy_from_user(&val, valp, sizeof(val));
printk("stack %d value: %ld", i, val);
printk(">");
return 0;
}
static void __exit modex(void)
{
}
module_init(init);
module_exit(modex);
MODULE_LICENSE("GPL");

Unable to handle kernel paging request at virtual address...custom board

I have taken rpi as a reference and trying to boot kernel to our custom board, modified the "dts" file by removing all peripherals except UART and Interrupt controller by changing the base address of the rpi board to our board specific address.
Seeting the env variables as follows,
$ setenv initrd 0xc3000000;setenv initrd_high 0xc4000000;setenv fdt_high 0xc1001000;setenv fdt_addr_r 0xc1000000
$ setenv bootargs earlyprintk console=ttyAMA0 mem=128M noinitrd root=/dev/mtdblock3 rw rootfstype=jffs2 rw init=/sbin/init
This is the error log we got....
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] Unable to handle kernel paging request at virtual address 48000fe0
[ 0.000000] pgd = c0004000
[ 0.000000] [48000fe0] *pgd=00000000
[ 0.000000] Internal error: Oops: 5 [#1] ARM
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.22+ #81
[ 0.000000] Hardware name: BCM2835
[ 0.000000] task: c0497f58 task.stack: c0494000
[ 0.000000] PC is at __vic_init+0x3c/0x178
[ 0.000000] LR is at 0x48000fe0
[ 0.000000] pc : [<c0473b74>] lr : [<48000fe0>] psr: a00000d3
[ 0.000000] sp : c0495f50 ip : 00000000 fp : c0495f7c
[ 0.000000] r10: 00000001 r9 : 410fb767 r8 : 48000000
[ 0.000000] r7 : 00000000 r6 : 00000000 r5 : ffffffff r4 : 00000000
[ 0.000000] r3 : 48000fe0 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 0.000000] Flags: NzCv IRQs off FIQs off Mode SVC_32 ISA ARM
Segment user
[ 0.000000] Control: 00c5387d Table: c0004008 DAC: 00000055
[ 0.000000] Process swapper (pid: 0, stack limit = 0xc0494188)
[ 0.000000] Stack: (0xc0495f50 to 0xc0496000)
Please help me,Thanks in advance.
Seems like the problem occured in interrupt context in procedure __vic_init. This procedure tried to access virtual address 48000fe0.
By the way - are you sure that this is complete calltrace taken from dmesg?
If this is only a snippet taken from dmesg - put the whole calltrace here.
If you have sources for this procedure __vic_init you can debug it - I mean find the number of the line in source file and do the further debug.

virtual memory size is much larger than RES, although there are no mapped files

The program has much large virtual memory than it's in ram, there is no swapping, since there is a lot of free space in ram. I looked at file descriptors, and there are no large files. This is part of process map:
107 00007f97f8021000 65404K ----- [ anon ]
108 00007f97fc000000 2052K rw--- [ anon ]
109 00007f97fc201000 63484K ----- [ anon ]
110 00007f9800000000 272K rw--- [ anon ]
111 00007f9800044000 65264K ----- [ anon ]
112 00007f98043fa000 4K ----- [ anon ]
113 00007f98043fb000 10240K rw--- [ anon ]
There are a lot of regions with about 64Kb. If they are allocated in my program, why then ram is only 250mb and virtual 3gb? What means anon?

Call trace when loading a module in Linux

I'm writing my first Linux kernel module, which actually is a RAM disk driver plus some additional features. When I tried to insmod the module, "Segmentation fault" happened.
And here is the corresponding kernel log, actually two pieces of kernel oops messages. After reading a lot of related tutorials, I still have some questions regarding this log:
In the call trace list, there are functions preceeded with and without question marks, what is the special meaning of the question mark "?" for that function?
My understanding of the call trace is: every function, except the bottom one, should be called by the one below it. But for this:
[ 397.855035] [<c05a603b>] ? exact_lock+0x0/0x16
[ 397.855035] [<f787c252>] ? diag_init+0x252/0x4bd [b2bntb_diag]
[ 397.855035] [<c0451e35>] ? __blocking_notifier_call_chain+0x42/0x4d
[ 397.855035] [<f787c000>] ? diag_init+0x0/0x4bd [b2bntb_diag]
diag_init the module init function written by me. It does not call any function named either exact_lock or __blocking_notifier_call_chain, how come these two functions appear such in the call trace here?
What is the error and how to resolve it?
BTW, the Linux kernel I'm running has version 2.6.35.6.
[ 397.850955] ------------[ cut here ]------------
[ 397.851544] WARNING: at lib/kobject.c:168 kobject_add_internal+0x3a/0x1e2()
[ 397.851601] Hardware name: VirtualBox
[ 397.851639] kobject: (f4580258): attempted to be registered with empty name!
[ 397.851678] Modules linked in: b2bntb_diag(+) fuse vboxvideo drm sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 vboxsf uinput snd_intel8x0 snd_ac97_codec vboxguest ac97_bus snd_seq snd_seq_device ppdev snd_pcm parport_pc parport microcode snd_timer joydev snd e1000 i2c_piix4 soundcore i2c_core snd_page_alloc [last unloaded: mperf]
[ 397.852707] Pid: 1958, comm: insmod Tainted: G W 2.6.35.6-45.fc14.i686 #1
[ 397.852749] Call Trace:
[ 397.852828] [<c043938d>] warn_slowpath_common+0x6a/0x7f
[ 397.852970] [<c05b054d>] ? kobject_add_internal+0x3a/0x1e2
[ 397.853130] [<c0439415>] warn_slowpath_fmt+0x2b/0x2f
[ 397.853182] [<c05b054d>] kobject_add_internal+0x3a/0x1e2
[ 397.853235] [<c05b098b>] kobject_add+0x5b/0x66
[ 397.853292] [<c064e8e3>] device_add+0xda/0x4b6
[ 397.853346] [<c05b7bc7>] ? kvasprintf+0x38/0x43
[ 397.853394] [<c05b08e0>] ? kobject_set_name_vargs+0x46/0x4c
[ 397.853467] [<c051b9bc>] register_disk+0x31/0x109
[ 397.853528] [<c05a6234>] ? blk_register_region+0x20/0x25
[ 397.853579] [<c05a6b08>] add_disk+0x9f/0xf0
[ 397.853627] [<c05a5bff>] ? exact_match+0x0/0xd
[ 397.853678] [<c05a603b>] ? exact_lock+0x0/0x16
[ 397.853731] [<f787c252>] diag_init+0x252/0x4bd [b2bntb_diag]
[ 397.853785] [<c0451e35>] ? __blocking_notifier_call_chain+0x42/0x4d
[ 397.853836] [<f787c000>] ? diag_init+0x0/0x4bd [b2bntb_diag]
[ 397.853889] [<c0401246>] do_one_initcall+0x4f/0x139
[ 397.853967] [<c0451e51>] ? blocking_notifier_call_chain+0x11/0x13
[ 397.854086] [<c04621a4>] sys_init_module+0x7f/0x19b
[ 397.854142] [<c07a7374>] syscall_call+0x7/0xb
[ 397.854177] ---[ end trace 6dc509801197bdc3 ]---
[ 397.855035] ------------[ cut here ]------------
[ 397.855035] kernel BUG at fs/sysfs/group.c:65!
[ 397.855035] invalid opcode: 0000 [#1] SMP
[ 397.855035] last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/PNP0C0A:00/power_supply/BAT0/energy_full
[ 397.855035] Modules linked in: b2bntb_diag(+) fuse vboxvideo drm sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 vboxsf uinput snd_intel8x0 snd_ac97_codec vboxguest ac97_bus snd_seq snd_seq_device ppdev snd_pcm parport_pc parport microcode snd_timer joydev snd e1000 i2c_piix4 soundcore i2c_core snd_page_alloc [last unloaded: mperf]
[ 397.855035]
[ 397.855035] Pid: 1958, comm: insmod Tainted: G W 2.6.35.6-45.fc14.i686 #1 /VirtualBox
[ 397.855035] EIP: 0060:[<c0520d15>] EFLAGS: 00010246 CPU: 0
[ 397.855035] EIP is at internal_create_group+0x23/0x103
[ 397.855035] EAX: f4580258 EBX: f4580258 ECX: c09d4344 EDX: 00000000
[ 397.855035] ESI: f60521f0 EDI: c09d4344 EBP: f45b7ef0 ESP: f45b7ed0
[ 397.855035] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 397.855035] Process insmod (pid: 1958, ti=f45b6000 task=f3a68ca0 task.ti=f45b6000)
[ 397.855035] Stack:
[ 397.855035] 00000000 f45b7ee4 c05b08e0 8eecb04c f4580200 f4580200 f60521f0 f4580200
[ 397.855035] <0> f45b7ef8 c0520e1c f45b7f00 c0498de9 f45b7f18 c05a261a f4580250 f4580200
[ 397.855035] <0> 00000001 00000000 f45b7f38 c05a6b0f c05a5bff c05a603b f4580200 0fc00000
[ 397.855035] Call Trace:
[ 397.855035] [<c05b08e0>] ? kobject_set_name_vargs+0x46/0x4c
[ 397.855035] [<c0520e1c>] ? sysfs_create_group+0x11/0x15
[ 397.855035] [<c0498de9>] ? blk_trace_init_sysfs+0x10/0x12
[ 397.855035] [<c05a261a>] ? blk_register_queue+0x3b/0xac
[ 397.855035] [<c05a6b0f>] ? add_disk+0xa6/0xf0
[ 397.855035] [<c05a5bff>] ? exact_match+0x0/0xd
[ 397.855035] [<c05a603b>] ? exact_lock+0x0/0x16
[ 397.855035] [<f787c252>] ? diag_init+0x252/0x4bd [b2bntb_diag]
[ 397.855035] [<c0451e35>] ? __blocking_notifier_call_chain+0x42/0x4d
[ 397.855035] [<f787c000>] ? diag_init+0x0/0x4bd [b2bntb_diag]
[ 397.855035] [<c0401246>] ? do_one_initcall+0x4f/0x139
[ 397.855035] [<c0451e51>] ? blocking_notifier_call_chain+0x11/0x13
[ 397.855035] [<c04621a4>] ? sys_init_module+0x7f/0x19b
[ 397.855035] [<c07a7374>] ? syscall_call+0x7/0xb
[ 397.855035] Code: 8d 65 f4 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 14 0f 1f 44 00 00 85 c0 89 c3 89 55 e0 89 cf 74 0a 85 d2 75 08 83 78 18 00 75 11 <0f> 0b 83 78 18 00 be ea ff ff ff 0f 84 c5 00 00 00 8b 17 85 d2
[ 397.855035] EIP: [<c0520d15>] internal_create_group+0x23/0x103 SS:ESP 0068:f45b7ed0
[ 397.865682] ---[ end trace 6dc509801197bdc4 ]---
[root#localhost ntb]#
The first oopss message is actually a warning from the kernel. The important part of the warning is right here: "attempted to be registered with empty name!". It means a descriptive name string field in a kobject was not supplied. Specifically, since in the call trace of the warning we see register_disk, I assume you forgot to properly init the name field of a struct you passed during registration. This is the warning part.
The next oopss message is an actual crash - some code in the sysfs file system that tried to create the name of a group from the name you were supposed to give in your registration process hit a kernel runtime assertion, not doubt due to the missing name field.
So this is why it is crashing. About your questions - some of the functions you see in the trace are actually called from inlined functions (and/or macros) that are used in your code. So your code is calling them, although not by name.
About the question mark, the kernel stack tracking mechanism reports if the address to symbol name lookup it does is "reliable" or not. Not 100% sure what that means, but if it doesn't you get the question mark in the symbol name.

Resources