From: Borislav Petkov <bp@alien8.de>
To: Tan Xiaojun <tanxiaojun@huawei.com>
Cc: dougthompson@xmission.com, mchehab@osg.samsung.com,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] EDAC: use debugfs_remove_recursive instead of debugfs_remove
Date: Tue, 13 Oct 2015 11:45:53 +0200 [thread overview]
Message-ID: <20151013094553.GA20700@pd.tnic> (raw)
In-Reply-To: <561CC4A6.8060401@huawei.com>
On Tue, Oct 13, 2015 at 04:45:26PM +0800, Tan Xiaojun wrote:
> Sorry, I don't describe it well. I do test like that:
> 1)open EDAC config and open CONFIG_EDAC_DEBUG
> 2)insmod a edac_mc module (like i3000_edac or others in drivers/edac/)
> 3)rmmod this module
> 4)we can also see files under /sys/kernel/debug/edac/ like "fake_inject"
>
> If you think this patch is OK, I will do patch in your branch and send V2.
Yes, please. I just triggered:
[ 119.331642] EDAC DEBUG: mc_attr_release: Releasing device mc
[ 159.735172] BUG: unable to handle kernel paging request at ffffffffa0056c80
[ 159.742184] IP: [<ffffffff811fda90>] do_dentry_open.isra.15+0xe0/0x2d0
[ 159.748755] PGD 3e0c067 PUD 3e0d063 PMD 43759e067 PTE 0
[ 159.754059] Oops: 0000 [#1] PREEMPT SMP
[ 159.758026] Modules linked in: binfmt_misc nls_iso8859_15 nls_cp437 btrfs x86_pkg_temp_thermal coretemp kvm_intel xor kvm raid6_pq crc32_pclmul crc32c_intel ghash_clmulni_intel hmac drbg usbhid aesni_intel aes_x86_64 snd_hda_codec_hdmi glue_helper snd_hda_codec_realtek dcdbas lrw snd_hda_codec_generic dell_smm_hwmon gf128mul serio_raw snd_hda_intel ablk_helper iTCO_wdt iTCO_vendor_support cryptd snd_hda_codec efivars button acpi_cpufreq snd_hwdep snd_hda_core snd_pcm snd_timer snd lpc_ich mfd_core processor soundcore i2c_i801 [last unloaded: edac_core]
[ 159.807818] CPU: 5 PID: 2120 Comm: grep Tainted: G W 4.3.0-rc5+ #1
[ 159.815130] Hardware name: Dell Inc. Precision T3600/0PTTT9, BIOS A13 05/11/2014
[ 159.822526] task: ffff880439ef5b00 ti: ffff88001fc18000 task.ti: ffff88001fc18000
[ 159.830009] RIP: 0010:[<ffffffff811fda90>] [<ffffffff811fda90>] do_dentry_open.isra.15+0xe0/0x2d0
[ 159.838984] RSP: 0018:ffff88001fc1bcc8 EFLAGS: 00010282
[ 159.844291] RAX: ffffffffa0056c80 RBX: ffff8804390996c0 RCX: 0000000000000000
[ 159.851418] RDX: ffff880439ef62b0 RSI: 0000000000000000 RDI: 00000000ffffffff
[ 159.858545] RBP: ffff88001fc1bcf0 R08: 0000000000000000 R09: 0000000000000000
[ 159.865679] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
[ 159.872806] R13: ffff88043897baf8 R14: 0000000000008000 R15: ffff8804390996d0
[ 159.879935] FS: 00007fa8aae6a700(0000) GS:ffff88043df40000(0000) knlGS:0000000000000000
[ 159.888019] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 159.893760] CR2: ffffffffa0056c80 CR3: 0000000037b1e000 CR4: 00000000000406e0
[ 159.900894] Stack:
[ 159.902903] ffff8804390996c0 ffff88001fc1bdf0 0000000000000000 0000000000008000
[ 159.910357] ffff88001fc1befc ffff88001fc1bd08 ffffffff811fef02 0000000000000000
[ 159.917807] ffff88001fc1bde0 ffffffff8120e6dd ffffffff810bfdfe ffff880439ef6300
[ 159.925253] Call Trace:
[ 159.927721] [<ffffffff811fef02>] vfs_open+0x52/0x60
[ 159.932691] [<ffffffff8120e6dd>] path_openat+0x20d/0x16e0
[ 159.938180] [<ffffffff810bfdfe>] ? __lock_acquire+0x94e/0x2230
[ 159.944094] [<ffffffff810bfdfe>] ? __lock_acquire+0x94e/0x2230
[ 159.950018] [<ffffffff812114de>] do_filp_open+0x7e/0xe0
[ 159.955333] [<ffffffff81220737>] ? expand_files+0x217/0x300
[ 159.961560] [<ffffffff818360c1>] ? _raw_spin_unlock+0x31/0x50
[ 159.967952] [<ffffffff81221181>] ? __alloc_fd+0xb1/0x180
[ 159.973899] [<ffffffff811ff27c>] do_sys_open+0x12c/0x210
[ 159.979844] [<ffffffff811ff394>] SyS_openat+0x14/0x20
[ 159.985527] [<ffffffff81836bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
[ 159.992506] Code: 00 81 4b 74 00 00 01 00 41 0f b7 45 00 66 25 00 f0 66 3d 00 80 0f 84 54 01 00 00 49 8b 85 d8 01 00 00 48 85 c0 0f 84 e0 00 00 00 <48> 8b 38 e8 88 48 f0 ff 84 c0 0f 84 d0 00 00 00 49 8b 85 d8 01
[ 160.012831] RIP [<ffffffff811fda90>] do_dentry_open.isra.15+0xe0/0x2d0
[ 160.020071] RSP <ffff88001fc1bcc8>
[ 160.024164] CR2: ffffffffa0056c80
[ 160.028106] ---[ end trace afc84e562a248374 ]---
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
prev parent reply other threads:[~2015-10-13 10:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-13 2:22 [PATCH] EDAC: use debugfs_remove_recursive instead of debugfs_remove Tan Xiaojun
2015-10-13 7:41 ` Borislav Petkov
2015-10-13 8:45 ` Tan Xiaojun
2015-10-13 9:45 ` Borislav Petkov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151013094553.GA20700@pd.tnic \
--to=bp@alien8.de \
--cc=dougthompson@xmission.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=tanxiaojun@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox