| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Wed, 18 Mar 2009 20:35:47 +0100 From: Frederic Weisbecker <fweisbec@...il.com> To: Jaswinder Singh Rajput <jaswinder@...nel.org> Cc: mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org, jaswinderrajput@...il.com, rostedt@...dmis.org, tglx@...utronix.de, mingo@...e.hu, linux-tip-commits@...r.kernel.org Subject: Re: [tip:tracing/ftrace] tracing: fix oops in tracepoint_update_probe_range() On Wed, Mar 18, 2009 at 11:42:10PM +0530, Jaswinder Singh Rajput wrote: > On Wed, 2009-03-18 at 19:00 +0100, Frederic Weisbecker wrote: > > > Jaswinder, It's hard for me to reproduce it via your config. > > May be it's because I had to update it to match latest -tip tree and > > then I inserted some noise inside. > > > > Could you please send me your bad vmlinux, so that I can have a first look at > > your elf sections and see if there is something helpful inside. > > > > OK I am uploading vmlinux (file size 14729799) and dmesg on : > > http://userweb.kernel.org/~jaswinder/oops_20090318/ > > Are you testing on 32 bit or 64 bit machine. > > I am getting this error on 64 bit AMD box. > > Thanks > -- > JSR > Actually I haven't tested but only looked at my elf sections and haven't seen anything weird. (I run a 64 too). Your sections are normal too: $ objdump -t ./vmlinux | grep __tracepoint | sort -d ffffffff81623b00 l O __ksymtab_gpl 0000000000000010 __ksymtab___tracepoint_block_remap ffffffff8162eeb3 l O __ksymtab_strings 0000000000000019 __kstrtab___tracepoint_block_remap ffffffff816fb800 g .data 0000000000000000 __start___tracepoints ffffffff816fb800 g O .data 0000000000000020 __tracepoint_power_start ffffffff816fb820 g O .data 0000000000000020 __tracepoint_power_end ffffffff816fb840 g O .data 0000000000000020 __tracepoint_power_mark ffffffff816fb860 g O .data 0000000000000020 __tracepoint_sched_wait_task ffffffff816fb880 g O .data 0000000000000020 __tracepoint_sched_wakeup ffffffff816fb8a0 g O .data 0000000000000020 __tracepoint_sched_wakeup_new ffffffff816fb8c0 g O .data 0000000000000020 __tracepoint_sched_switch ffffffff816fb8e0 g O .data 0000000000000020 __tracepoint_sched_migrate_task ffffffff816fb900 g O .data 0000000000000020 __tracepoint_sched_process_fork ffffffff816fb920 g O .data 0000000000000020 __tracepoint_sched_process_free ffffffff816fb940 g O .data 0000000000000020 __tracepoint_sched_process_exit ffffffff816fb960 g O .data 0000000000000020 __tracepoint_sched_process_wait ffffffff816fb980 g O .data 0000000000000020 __tracepoint_softirq_entry ffffffff816fb9a0 g O .data 0000000000000020 __tracepoint_softirq_exit ffffffff816fb9c0 g O .data 0000000000000020 __tracepoint_sched_signal_send ffffffff816fb9e0 g O .data 0000000000000020 __tracepoint_workqueue_insertion ffffffff816fba00 g O .data 0000000000000020 __tracepoint_workqueue_execution ffffffff816fba20 g O .data 0000000000000020 __tracepoint_workqueue_creation ffffffff816fba40 g O .data 0000000000000020 __tracepoint_workqueue_destruction ffffffff816fba60 g O .data 0000000000000020 __tracepoint_sched_kthread_stop ffffffff816fba80 g O .data 0000000000000020 __tracepoint_sched_kthread_stop_ret ffffffff816fbaa0 g O .data 0000000000000020 __tracepoint_irq_handler_entry ffffffff816fbac0 g O .data 0000000000000020 __tracepoint_irq_handler_exit ffffffff816fbae0 g O .data 0000000000000020 __tracepoint_block_bio_bounce ffffffff816fbb00 g O .data 0000000000000020 __tracepoint_block_split ffffffff816fbb20 g O .data 0000000000000020 __tracepoint_block_rq_abort ffffffff816fbb40 g O .data 0000000000000020 __tracepoint_block_rq_insert ffffffff816fbb60 g O .data 0000000000000020 __tracepoint_block_rq_issue ffffffff816fbb80 g O .data 0000000000000020 __tracepoint_block_plug ffffffff816fbba0 g O .data 0000000000000020 __tracepoint_block_unplug_io ffffffff816fbbc0 g O .data 0000000000000020 __tracepoint_block_unplug_timer ffffffff816fbbe0 g O .data 0000000000000020 __tracepoint_block_getrq ffffffff816fbc00 g O .data 0000000000000020 __tracepoint_block_sleeprq ffffffff816fbc20 g O .data 0000000000000020 __tracepoint_block_rq_requeue ffffffff816fbc40 g O .data 0000000000000020 __tracepoint_block_bio_backmerge ffffffff816fbc60 g O .data 0000000000000020 __tracepoint_block_bio_frontmerge ffffffff816fbc80 g O .data 0000000000000020 __tracepoint_block_bio_queue ffffffff816fbca0 g O .data 0000000000000020 __tracepoint_block_rq_complete ffffffff816fbcc0 g O .data 0000000000000020 __tracepoint_block_remap ffffffff816fbce0 g O .data 0000000000000020 __tracepoint_block_bio_complete ffffffff816fbd00 g .data 0000000000000000 __stop___tracepoints You see? __start___tracepoints and __stop___tracepoints embrace very well a good number of tracepoints, so it's not empty. You even have tracepoints for options that you haven't selected. It seems that if CONFIG_TRACEPOINTS is enabled, all tracepoints that are found in a built file will be configured. And there are things such as workqueues that are always built in a kernel, so the tracepoint section is _never_ supposed to be empty if CONFIG_TRACEPOINTS=y Something screwed up somewhere... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists