Re: Re: [PATCH ftrace/core 0/2] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts

[Masami Hiramatsu]

(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.pt@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/