From: Kai <mh2494@ms8.hinet.net>
To: linux-kernel@vger.kernel.org
Subject: Bad Page State In File System Related Opeartions (3.10.35)
Date: Sun, 15 Feb 2015 22:20:56 +0800 [thread overview]
Message-ID: <54E0AB48.6050205@ms8.hinet.net> (raw)
While doing data transfer between several hosts with different file
systems/protocols, I always get errors as below:
[ 5257.087865] BUG: Bad page state in process ftpd pfn:2150f
[ 5257.093524] page:ffffea0000749b48 count:0 mapcount:0
mapping: (null) index:0x2
[ 5257.101547] page flags: 0x4000000000000004(referenced)
[ 5257.107003] Modules linked in: iscsi_tcp libiscsi_tcp libiscsi
iscsi_target_mod(O) target_core_mod(O) iscsi_extent_pool(PO)
iscsi_rodsp(PO) configfs nfsd exportfs rpcsec_gss_krb5 cifs udf isofs
loop hid_generic usbhid hid usblp usb_storage btrfs zlib_deflate
libcrc32c hfsplus md4 hmac tn40xx(O) ixgbe(O) be2net igb(O) i2c_algo_bit
e1000e(O) dca fuse vfat fat crc32c_intel cryptd ecryptfs sha512_generic
sha256_generic sha1_generic ecb aes_x86_64 authenc des_generic
ansi_cprng cts md5 cbc cpufreq_conservative cpufreq_powersave
cpufreq_performance cpufreq_ondemand acpi_cpufreq mperf processor
thermal_sys cpufreq_stats freq_table dm_snapshot crc_itu_t crc_ccitt
quota_v2 quota_tree psnap p8022 llc tunnel4 ipv6 zram(C) sg etxhci_hcd
xhci_hcd ehci_pci ehci_hcd uhci_hcd usbcore usb_common [last unloaded:
configfs]
[ 5257.184511] CPU: 0 PID: 17627 Comm: ftpd Tainted: P WC O
3.10.35 #1
[ 5257.191668] Hardware name: To be filled by O.E.M. To be filled by
O.E.M./To be filled by O.E.M., BIOS 4.6.4 09/28/2012
[ 5257.202404] ffffffff8149bbc3 0000000000000000 ffffffff8149a6d1
0000000000000001
[ 5257.209964] ffffffff810b2cac 000000000000001f 0000000000000246
000213da00000000
[ 5257.217425] 0000000000000000 ffff880073171fd8 0000000000000030
0000000000000001
[ 5257.224967] Call Trace:
[ 5257.227426] [<ffffffff8149bbc3>] ? dump_stack+0xd/0x17
[ 5257.232701] [<ffffffff8149a6d1>] ? bad_page+0xd4/0xeb
[ 5257.237940] [<ffffffff810b2cac>] ? get_page_from_freelist+0x57c/0x660
[ 5257.244635] [<ffffffff8133b315>] ? ata_qc_issue+0x195/0x3e0
[ 5257.250509] [<ffffffff810b2ee1>] ? __alloc_pages_nodemask+0x151/0x7f0
[ 5257.257237] [<ffffffff81000fa0>] ? __switch_to+0x3d0/0x460
[ 5257.262976] [<ffffffff8149f67e>] ? __schedule+0x25e/0x5c0
[ 5257.268655] [<ffffffff810b590c>] ? __do_page_cache_readahead+0xec/0x250
[ 5257.275611] [<ffffffff813b11d3>] ? dm_any_congested+0x63/0x80
[ 5257.281676] [<ffffffff810b5cdc>] ? ra_submit+0x1c/0x30
[ 5257.287086] [<ffffffff810ac8c1>] ? generic_file_aio_read+0x481/0x6f0
[ 5257.293756] [<ffffffff810e775a>] ? do_sync_read+0x6a/0xa0
[ 5257.299719] [<ffffffff810e8940>] ? vfs_read+0xa0/0x160
[ 5257.305335] [<ffffffff810ee921>] ? kernel_read+0x41/0x60
[ 5257.311060] [<ffffffffa01bbca9>] ? ecryptfs_decrypt_page+0x1f9/0x390
[ecryptfs]
[ 5257.318731] [<ffffffff810587b5>] ? __wake_up_common+0x55/0x90
[ 5257.324998] [<ffffffff810591c3>] ? __wake_up+0x43/0x70
[ 5257.330498] [<ffffffffa01b9968>] ? ecryptfs_readpage+0xd8/0x120
[ecryptfs]
[ 5257.337953] [<ffffffff81115878>] ?
__generic_file_splice_read+0x3c8/0x540
[ 5257.345346] [<ffffffff81113e60>] ? page_cache_pipe_buf_release+0x20/0x20
[ 5257.352143] [<ffffffff813c9a46>] ? kernel_sendpage+0x16/0x30
[ 5257.358282] [<ffffffff813c9a82>] ? sock_sendpage+0x22/0x30
[ 5257.364188] [<ffffffff81113cfd>] ? pipe_to_sendpage+0x4d/0x80
[ 5257.370355] [<ffffffff81113e4c>] ? page_cache_pipe_buf_release+0xc/0x20
[ 5257.377369] [<ffffffff81113de1>] ? splice_from_pipe_feed+0xb1/0x110
[ 5257.384019] [<ffffffff81113cb0>] ? splice_from_pipe_begin+0x10/0x10
[ 5257.390536] [<ffffffff8111400e>] ? __splice_from_pipe+0x3e/0x80
[ 5257.396793] [<ffffffff81115ab8>] ? splice_from_pipe+0x58/0x70
[ 5257.402884] [<ffffffff81115a24>] ? generic_file_splice_read+0x34/0x70
[ 5257.409627] [<ffffffff811149eb>] ? splice_direct_to_actor+0x9b/0x1c0
[ 5257.416250] [<ffffffff81114390>] ? do_splice_from+0x130/0x130
[ 5257.422227] [<ffffffff81115b53>] ? do_splice_direct+0x53/0x70
[ 5257.428234] [<ffffffff810e7d1f>] ? do_sendfile+0x1bf/0x560
[ 5257.433901] [<ffffffff8102c5cf>] ? sys32_fstat64+0x1f/0x30
[ 5257.439750] [<ffffffff810e9b45>] ? SyS_sendfile64+0x55/0xa0
[ 5257.445602] [<ffffffff814a2391>] ? sysenter_dispatch+0x7/0x1e
The paths of the call-traces are random. However, the processes hitting
the bad pages are usually cp, somtimes the processes accessing files
like ftpd in this case.
When the fields count, mapcount, and map of a page are all 0 or NULL, is
it valid that the page has the flag referenced set? I am wondering if
this is a use-after-free case.
I also find that, after I remove the hfsplus volumes, this issue disappears.
I have traced into the kernel code for any potnetial racing with the
finction mark_page_accessed() but find nothing.
Would any one suggest about this issue? All the suggestions and comments
are appreciated.
Kai Gnep
---
Avast 防毒軟體已檢查此封電子郵件的病毒。
http://www.avast.com
reply other threads:[~2015-02-15 16:42 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=54E0AB48.6050205@ms8.hinet.net \
--to=mh2494@ms8.hinet.net \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®