Bug 1054537
| Summary: | [abrt] kernel BUG at mm/mlock.c:512! | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Karl Auerbach <karl> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 19 | CC: | gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Unspecified | ||||||||
| URL: | https://retrace.fedoraproject.org/faf/reports/bthash/589792e53edc2228ff3031833e6ecd8b6dbc32d7 | ||||||||
| Whiteboard: | abrt_hash:5fa9d6a9e8d781f6c9c0047963bf94d9ced80bd2 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-06-16 15:19:14 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Karl Auerbach
2014-01-17 01:44:58 UTC
Created attachment 851372 [details]
File: dmesg
Created attachment 851413 [details]
Simple program to cause this kernel issue
This is a C program that must be run with root privilege. It runs fine on older kernels but causes a kernel problem on the most recent one.
The code creates a raw socket with transmit and receive ring buffers.
The rings are then made visible via mmap().
When munmap() is called things go awry.
The code in this example was quickly lifted from a larger body of code that has been running for several years.
Could you try this with a kernel from the rawhide nodebug repo and see if it recreates on that? If so, it would be best to report it directly to upstream. I just tried the kernel from rawhide nodebug repo: Linux v-f19-x64.cavebear.com 3.13.0-0.rc8.git2.2.fc21.x86_64 #1 SMP Wed Jan 15 16:18:47 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux And it had the same issue: [ 3364.076609] kernel BUG at mm/mlock.c:512! [ 3364.076664] invalid opcode: 0000 [#1] SMP etc etc Under the prior kernel things still go bad, but with a slightly different reported location: Linux v-f19-x64.cavebear.com 3.12.6-200.fc19.x86_64 #1 SMP Mon Dec 23 16:33:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [ 132.747009] kernel BUG at include/linux/page-flags.h:413! [ 132.747085] invalid opcode: 0000 [#1] SMP [ 132.747152] Modules linked in: nfsv3 nfs_acl nfs lockd sunrpc fscache nf_conntrack_netbios_ns nf_conntrack_broadcast ipt_MASQUERADE ip6t_REJECT xt_conntrack bnep bluetooth rfkill 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 snd_hda_codec_hdmi snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm snd_page_alloc kvm snd_timer sp5100_tco r8169 i2c_piix4 microcode snd ppdev parport_pc mii edac_core soundcore wmi parport shpchp edac_mce_amd k10temp serio_raw asus_atk0110 acpi_cpufreq uinput radeon i2c_algo_bit [ 132.748420] drm_kms_helper ata_generic ttm pata_acpi drm pata_atiixp i2c_core [ 132.748537] CPU: 3 PID: 1793 Comm: a.out Not tainted 3.12.6-200.fc19.x86_64 #1 etc etc I'm starting to search for the kernel version at which this problem started. So far I know that 3.9.5-301.fc19.x86_64 (the release version for F19) that things were OK. So stuff went awry sometime after 3.9.5-301.fc19.x86_64 and before 3.12.5-200.fc19.x86_64 Is there an archive of the Fedora kernel RPMs so that I can pull the various versions that came out and give 'em a try? If so could someone give me a pointer? http://koji.fedoraproject.org/koji/packageinfo?packageID=8 has all the builds we've done. I've now narrowed it down to a specific Fedora kernel release. The problem first occurs with: kernel-3.12.5-200.fc19.x86_64 http://koji.fedoraproject.org/koji/buildinfo?buildID=485557 There is not a problem with its predecessor, 3.11.10-200.fc19.x86_64 By-the-way, I don't think I mentioned: 1. That things seem to go wrong in a call to munmap() 2. That after the kernel event the machine is often still somewhat active, but it hangs during a restart - the reset button or a power cycle is needed. I've kinda reached the limit of my expertise (or lack of same) here. I have done some additional testing to isolate when this bug crept in. I built kernels directly from the sources at kernels.org and used the default .config values. Kernel 3.11.10 was OK. Kernel 3.12.1 was not. There were no intervening kernels. So this jumped in during the hop from 3.11.10 to 3.12.1 I perused the change log but nothing jumped out at me, but then again, I am way beyond my depth here. *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those. This bug still exists in 3.13.5-100.fc19. I have heard that a patch has been submitted upstream; I don't know whether this has been accepted and propagated: https://bugzilla.kernel.org/show_bug.cgi?id=70021 *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.14.4-100.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those. Should be fixed with 3.14 (commit 9050d7eba40b3d79551668f54e68fd6f51945ef3) |