(2014/06/12 21:43), Josh Poimboeuf wrote: >>> I tried removing the FTRACE_OPS_FL_ENABLED clearing line in >>> ftrace_startup, but I saw more warnings. This one happened when >>> attempting to kprobe a kpatched function: >> >> Oops! yes, this should happen... > > Instead of a warning here I'd expect to see register_kprobe return an > error and a staprun failure.
Actually, since kprobes has "disabled" state, not only register_kprobe but also enable_kprobe also can be failed. :) >>> WARNING: CPU: 3 PID: 4444 at kernel/kprobes.c:953 arm_kprobe+0xa7/0xe0() >>> Failed to init kprobe-ftrace (-16) >>> Modules linked in: stap_b2ea0de23f179d8ded86fcc19fcc533_4444(OE) >>> kpatch_meminfo_string(OE) kpatch(OE) rfcomm fuse ccm ipt_MASQUERADE >>> xt_CHECKSUM tun ip6t_rpfilter ip6t_REJECT xt_conntrack bnep ebtable_nat >>> ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat >>> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle >>> ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat >>> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack >>> iptable_mangle iptable_security iptable_raw arc4 iwldvm mac80211 iTCO_wdt >>> iTCO_vendor_support x86_pkg_temp_thermal coretemp kvm_intel kvm >>> snd_hda_codec_hdmi iwlwifi snd_hda_codec_realtek snd_hda_codec_generic >>> snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_seq uvcvideo >>> btusb cfg80211 bluetooth videobuf2_vmalloc videobuf2_memops >>> videobuf2_core v4l2_common videodev snd_seq_device snd_pcm sdhci_pci >>> media sdhci joydev nfsd i2c_i801 serio_raw pcspkr mmc_core microcode >>> snd_timer e1000e lpc_ich thinkpad_acpi mfd_core shpchp snd wmi tpm_tis >>> soundcore tpm ptp rfkill mei_me auth_rpcgss mei pps_core nfs_acl lockd >>> sunrpc dm_crypt i915 i2c_algo_bit drm_kms_helper drm crct10dif_pclmul >>> crc32_pclmul crc32c_intel ghash_clmulni_intel i2c_core video [last >>> unloaded: kpatch_meminfo_string] >>> CPU: 3 PID: 4444 Comm: stapio Tainted: G U W OE 3.15.0-IPMODIFY+ #1 >>> Hardware name: LENOVO 2356BH8/2356BH8, BIOS G7ET63WW (2.05 ) 11/12/2012 >>> 0000000000000000 000000009cd22363 ffff880427bdfd80 ffffffff816f31ed >>> ffff880427bdfdc8 ffff880427bdfdb8 ffffffff8108914d ffffffffa08258e0 >>> ffffffffa08258f0 0000000000000000 0000000000000000 0000000000000000 >>> Call Trace: >>> [<ffffffff816f31ed>] dump_stack+0x45/0x56 >>> [<ffffffff8108914d>] warn_slowpath_common+0x7d/0xa0 >>> [<ffffffff810891cc>] warn_slowpath_fmt+0x5c/0x80 >>> [<ffffffff816ff9d7>] arm_kprobe+0xa7/0xe0 >>> [<ffffffff817007f7>] register_kprobe+0x557/0x5d0 >>> [<ffffffff81254da0>] ? meminfo_proc_open+0x30/0x30 >>> [<ffffffffa0820c95>] _stp_ctl_write_cmd+0x8d5/0x930 >>> [stap_b2ea0de23f179d8ded86fcc19fcc533_4444] >>> [<ffffffff811e5daa>] vfs_write+0xba/0x1e0 >>> [<ffffffff811e6965>] SyS_write+0x55/0xd0 >>> [<ffffffff81703179>] system_call_fastpath+0x16/0x1b >>> >>> >>> And this one happened after unregistering a probe and then attempting to >>> register kpatch: >> >> Did you see this on unpatching? it seems to happen on disabling a hash... > > No, I think it was in the patching path, after removing the kprobe. > kpatch was calling ftrace_set_filter_ip(), and had not called > register_ftrace_function() yet. OK, anyway, I'll make a test case for checking it. Thanks! -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
