Re: function from userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 30, 2010 at 10:44 AM, Rahul Kumar <mailforgroup@xxxxxxxxx> wrote:
> Thanks for giving the pointers.
>
> I tried with the strace for below program, what does mmap2 do below?.
> Can i assume that read is a syscall made for getchar?. Also at what
> point it geoes into kernel space?. I would like to have some
> understanding on this.

The answers (i reordered your questions):

a.   everything u see in "strace" is system call, and by definition,
system call is the entry point where userspace got into kernel.
b.   when "execve()" an exe, u have to load all its dependent
libraries (userspace), and then map it contiguously in memory in
multiple of 4K of addresses (not sure?), so it is possible to be
padded with zero at the end to reach 4K boundary.   mmap2() is used
for this purpose.   Physical copies of all userspace libraries only
have one copy in memory, but different exe may map it to diff virtual
addresses.
c.   brk() is the memory allocation part.   (just "man brk")
d.   mmap2 or mmap() is the mapping of files to virtual memory addresses:

http://opengroup.org/onlinepubs/007908775/xsh/mmap.html
e.   read() actually correspond to your reading from
keyboard.....which is analyzed before....

>
> execve("./a.out", ["./a.out"], [/* 15 vars */]) = 0
> brk(0)                                  = 0x85d0000
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7896000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=128666, ...}) = 0
> mmap2(NULL, 128666, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7876000
> close(3)                                = 0
> access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
> open("/lib/tls/i686/cmov/libc.so.6", O_RDONLY) = 3
> read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320h\1\0004\0\0\0\344"...,
> 512) = 512
> fstat64(3, {st_mode=S_IFREG|0755, st_size=1442180, ...}) = 0
> mmap2(NULL, 1451632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE,
> 3, 0) = 0xb7713000
> mprotect(0xb786f000, 4096, PROT_NONE)   = 0
> mmap2(0xb7870000, 12288, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15c) = 0xb7870000
> mmap2(0xb7873000, 9840, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7873000
> close(3)                                = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7712000
> set_thread_area({entry_number:-1 -> 6, base_addr:0xb77126c0,
> limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
> limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> open("/dev/urandom", O_RDONLY)          = 3
> read(3, "L\350\325"..., 3)              = 3
> close(3)                                = 0
> mprotect(0xb7870000, 8192, PROT_READ)   = 0
> mprotect(0x8049000, 4096, PROT_READ)    = 0
> mprotect(0xb78b5000, 4096, PROT_READ)   = 0
> munmap(0xb7876000, 128666)              = 0
> fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7895000
> read(0, 1 <- Here i gave an input 1
> "1\n"..., 1024)                 = 2
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 5), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7894000
> write(1, " You Entered: 1\n"..., 16 You Entered: 1
> )    = 16
> exit_group(16)                          = ?
>
>
>
>
>
> On Tue, Jun 29, 2010 at 11:04 AM, Peter Teoh <htmldeveloper@xxxxxxxxx> wrote:
>> The interface between userspace and kernel is very clear, because
>> userspace code will never be executed in kernel and vice versa.
>> Userspace interface with kernelspace via system call, cat
>> /proc/kallsyms | grep " sys_" and u can see MOST the system FROM THE
>> KERNEL side.   Minus the sys_ and u can search the web for the
>> corresponding userspace function API - most of the time.   (Cannot
>> generalize too far, because I have never seen many of these symbols in
>> userspace or even in kernel myself :-)).
>>
>> From below:
>>
>> #include <stdio.h>
>>
>> main()
>> {
>>        char c=getchar();
>>        printf("%c\n", c);
>> }
>>
>> Doing a "strace" we can see that read() is one key API used for I/O -
>> its kernel API is sys_read().
>>
>> Three option are available (minus kdb and lttng):  systemtap or ftrace
>> or kgdb + VirtualBox, as sys_read() is used for many reasons - many
>> paths are will reach sys_read().
>>
>> Eg, for ftrace:
>>
>> you will get 22K lines of traces then zooming down into sys_read:
>>
>>  17423          getchar-6557  [000]   157.098641: kmem_cache_free <-putname
>>  17424          getchar-6557  [000]   157.098642: sys_read <-syscall_call
>>  17425          getchar-6557  [000]   157.098643: fget_light <-sys_read
>>  17426          getchar-6557  [000]   157.098643: vfs_read <-sys_read
>>  17427          getchar-6557  [000]   157.098644: rw_verify_area <-vfs_read
>>  17428          getchar-6557  [000]   157.098644:
>> security_file_permission <-rw_verify_area
>>  17429          getchar-6557  [000]   157.098645: cap_file_permission
>> <-security_file_permission
>>  17430          getchar-6557  [000]   157.098645: do_sync_read <-vfs_read
>>  17431          getchar-6557  [000]   157.098646:
>> generic_file_aio_read <-do_sync_read
>>
>> There is almost NO mapping to any keyboard at all......
>>
>> Then I used systemtap:
>>
>> ====>evdev_event
>>  0xc047fb20 : evdev_event+0x0/0x90 [kernel]
>>  0xc0479d92 : input_pass_event+0xb2/0xc0 [kernel]
>>  0xc047c3c2 : input_handle_event+0x82/0x440 [kernel]
>>  0xc047c878 : input_event+0x68/0x80 [kernel]
>>  0xc0481d35 : atkbd_interrupt+0x645/0x6a0 [kernel]
>>  0xc0476f7d : serio_interrupt+0x3d/0x90 [kernel]
>>  0xc04782a1 : i8042_interrupt+0x1d1/0x330 [kernel]
>>  0xc01ad970 : handle_IRQ_event+0x60/0x140 [kernel]
>>  0xc01af9a1 : handle_edge_irq+0xb1/0x140 [kernel]
>>  0xc0104bdf : handle_irq+0x1f/0x30 [kernel]
>>  0xc05ceedb : do_IRQ+0x4b/0xc0 [kernel]
>>  0xc0103469 : common_interrupt+0x29/0x30 [kernel]
>>  0xc017007b : alloc_pid+0x19b/0x360 [kernel] (inexact)
>>  0xc03a2cc4 : acpi_idle_enter_bm+0x262/0x291 [kernel] (inexact)
>>  0xc04b717d : cpuidle_idle_call+0x8d/0x110 [kernel] (inexact)
>>  0xc0101e9a : cpu_idle+0x5a/0x90 [kernel] (inexact)
>>  0xc05c24ba : start_secondary+0x176/0x1ec [kernel] (inexact)
>>
>> Almost got to the key APIs.   But the systemtap tracing above is
>> assited by source code reading:   drivers/input/keyboard/*.c (among
>> the different keyboard, the commonly used AT/PS2 is atkbd.c) and also
>> drivers/char/tty_io.c (looking through all the "read" function ptrs in
>> the fops structure within this file).   The latter is the path taken
>> when the keyboard input comes from remote login terminal).
>>
>> Searching through the source (for "keyboard") indicate many other
>> places which can directly access the keyboard via port I/O API
>> (inp_b()) as well.
>>
>> Well I could be wrong.....as someone always seemed to be able to
>> suggest some ideas which proved me wrong....any comments?
>>
>> On Tue, Jun 29, 2010 at 10:31 AM, Rahul Kumar <mailforgroup@xxxxxxxxx> wrote:
>>> Hi,
>>>
>>> What will happen when getchar () (or some other operation) is called
>>> from userspace.
>>> I would like to know all the trace until you receive the character
>>> from kernel to userspace.
>>>
>>> My rough understanding is:
>>> getchar calls library function which calls system call...etc.
>>> I need some proper explanation. Can any one clarify me on this. Thanks.
>>>
>>> --
>>> To unsubscribe from this list: send an email with
>>> "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
>>> Please read the FAQ at http://kernelnewbies.org/FAQ
>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Peter Teoh
>>
>



-- 
Regards,
Peter Teoh

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux