Sorry that nobody has replied you so far.....but I can try:
Mine is 12.04.2 LTS Ubuntu (32-bit) too. But I downloaded the latest
(almost) Linus git tree and recompile the kernel.
3.11.0-rc3+
And then I use ftrace method to trace the kernel execution behavior when
"ls /root" is done. This is my bash script:
echo 0 >/sys/kernel/debug/tracing/tracing_on ####: quick way to re-enable
tracing
echo >/sys/kernel/debug/tracing/trace ####: trace clear
echo blk* "*request*" > /sys/kernel/debug/tracing/set_ftrace_filter
echo function >/sys/kernel/debug/tracing/current_tracer
echo 1 >/sys/kernel/debug/tracing/tracing_on ####: quick way to re-enable
tracing
ls -R /root
echo 0 >/sys/kernel/debug/tracing/tracing_on ####: quick way to re-enable
tracingcat /sys/kernel/debug/tracing/trace
The details are documented in /sys/kernel/debug/tracing/README.
Please read the documentation, as the above script will need to be changed
for a slightly earlier version of the kernel.
>From above script, I focus only on the "blk*" and "*get_request*" function,
which is why all the following traces is generated (for the "ls" operation):
ls-13654 [001] .... 7116.341799: blk_rq_init <-get_request
ls-13654 [001] .... 7116.341799: elv_set_request
<-get_request
ls-13654 [001] .... 7116.341799: cfq_set_request
<-elv_set_request
ls-13654 [001] .... 7116.341799: init_request_from_bio
<-blk_queue_bio
ls-13654 [001] .... 7116.341799: blk_rq_bio_prep
<-init_request_from_bio
ls-13654 [001] .... 7116.341799: blk_recount_segments
<-bio_phys_segments
ls-13654 [001] d... 7116.341799: __elv_add_request
<-blk_queue_bio
ls-13654 [001] d... 7116.341800: cfq_insert_request
<-__elv_add_request
ls-13654 [001] d... 7116.341800: scsi_request_fn
<-__blk_run_queue
ls-13654 [001] d... 7116.341800: blk_peek_request
<-scsi_request_fn
ls-13654 [001] d... 7116.341800: cfq_dispatch_requests
<-blk_peek_request
ls-13654 [001] d... 7116.341800: cfq_remove_request
<-cfq_dispatch_insert
ls-13654 [001] d... 7116.341800: cfq_activate_request
<-blk_peek_request
ls-13654 [001] d... 7116.341801: blk_rq_map_sg
<-scsi_init_sgtable
ls-13654 [001] d... 7116.341801: blk_start_request
<-scsi_request_fn
ls-13654 [001] d... 7116.341801: blk_dequeue_request
<-blk_start_request
ls-13654 [001] d... 7116.341801: blk_add_timer
<-blk_start_request
ls-13654 [001] d... 7116.341802: blk_peek_request
<-scsi_request_fn
ls-13654 [001] d... 7116.341802: cfq_dispatch_requests
<-blk_peek_request
ls-13654 [001] .... 7116.341803: generic_make_request
<-submit_bio
ls-13654 [001] .... 7116.341803: generic_make_request_checks
<-generic_make_request
ls-13654 [001] .... 7116.341803: blk_throtl_bio
<-generic_make_request_checks
ls-13654 [001] .... 7116.341803: blk_queue_bio
<-generic_make_request
ls-13654 [001] .... 7116.341804: blk_queue_bounce
<-blk_queue_bio
ls-13654 [001] d... 7116.341804: get_request <-blk_queue_bio
ls-13654 [001] .... 7116.341804: blk_rq_init <-get_request
ls-13654 [001] .... 7116.341804: elv_set_request
<-get_request
ls-13654 [001] .... 7116.341804: cfq_set_request
<-elv_set_request
ls-13654 [001] .... 7116.341804: init_request_from_bio
<-blk_queue_bio
ls-13654 [001] .... 7116.341804: blk_rq_bio_prep
<-init_request_from_bio
ls-13654 [001] .... 7116.341804: blk_recount_segments
<-bio_phys_segments
ls-13654 [001] d... 7116.341805: __elv_add_request
<-blk_queue_bio
ls-13654 [001] d... 7116.341805: cfq_insert_request
<-__elv_add_request
ls-13654 [001] d... 7116.341805: scsi_request_fn
<-__blk_run_queue
ls-13654 [001] d... 7116.341805: blk_peek_request
<-scsi_request_fn
ls-13654 [001] d... 7116.341805: cfq_dispatch_requests
<-blk_peek_request
ls-13654 [001] d... 7116.341805: cfq_remove_request
<-cfq_dispatch_insert
ls-13654 [001] d... 7116.341806: cfq_activate_request
<-blk_peek_request
ls-13654 [001] d... 7116.341806: blk_rq_map_sg
<-scsi_init_sgtable
ls-13654 [001] d... 7116.341806: blk_start_request
<-scsi_request_fn
ls-13654 [001] d... 7116.341807: blk_dequeue_request
<-blk_start_request
ls-13654 [001] d... 7116.341807: blk_add_timer
<-blk_start_request
ls-13654 [001] d... 7116.341807: blk_peek_request
<-scsi_request_fn
ls-13654 [001] d... 7116.341807: cfq_dispatch_requests
<-blk_peek_request
ls-13654 [001] .... 7116.341808: generic_make_request
<-submit_bio
ls-13654 [001] .... 7116.341808: generic_make_request_checks
<-generic_make_request
ls-13654 [001] .... 7116.341808: blk_throtl_bio
<-generic_make_request_checks
ls-13654 [001] .... 7116.341808: blk_queue_bio
<-generic_make_request
ls-13654 [001] .... 7116.341809: blk_queue_bounce
<-blk_queue_bio
ls-13654 [001] d... 7116.341809: get_request <-blk_queue_bio
ls-13654 [001] .... 7116.341809: blk_rq_init <-get_request
ls-13654 [001] .... 7116.341809: elv_set_request
<-get_request
ls-13654 [001] .... 7116.341809: cfq_set_request
<-elv_set_request
I hope you will know how to read and analyse the caller-callee
relationship. pid of "ls" is 13654.
On Tuesday, October 15, 2013 6:35:40 PM UTC+8, Intekhab shaikh wrote:
>
> Hi,
>
> I am new to Linux Kernel development. So please bare with me for trivial
> things.
> If it is not the right forum to post then please let me know the
> appropriate channel
>
> I am facing issues on Ubuntu 12.04.2 and 12.04.3. For one project I need
> to hook into the make_request function of existing block devices and need
> to do some processing on the read data before passing it onto user mode
> applications.
>
> My_hooked_in_make_request_fn=>clone the existing bio and change bio_endio
> callback to my own callback fn (hook_bio_endio)=> In hook_bio_endio do some
> processing => call original bio's bi_endio function
>
> Code works perfectly fine with 32-bit and 64-bit versions of 2.6.34 and
> 3.2 kernel versions and it also works on 3.6 and 3.8 kernel version but
> only on 64-bit.
>
> Investigations revealed that it is happening because in bio_endio callback
> function I get bio->bi_size as non zero value. And it is same size which is
> requested from block device. I was at-least expecting it to be smaller than
> the requested size.
>
> Why I am getting the same size in hook_bio_endio function? Is it due to IO
> splitting/partially completed IO's? How do I handle it?
>
> I have noticed that for smaller request like 4K hook_bio_endio is
> receiving bi_size as 0 and for 128K or little smaller getting same 128K
> size in bi_size.
>
> Please help me understand why and how it is happening and how to deal with
> it.
>
> Thanks & Regards,
> Intekhab
>
>
--
You received this message because you are subscribed to the Google Groups
"linuxkernelnewbies" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linuxkernelnewbies+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
