Bug 1074710
| Summary: | Default kernel config has CONFIG_DEBUG_VM set, which may raise compatibility issues with non-GPL kernel modules | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Daniel Dadap <ddadap> |
| 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: | rawhide | CC: | gansalmon, itamar, jhubbard, jonathan, kernel-maint, kevin.abbey, madhu.chinakonda, mchehab |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | kernel-3.14.2-200.fc20 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-05-01 22:31:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Daniel Dadap
2014-03-10 23:35:39 UTC
Did you bring this issue up with the upstream authors of the commit? They may not have realized the impacts of the change they performed in terms of the GPL issues. If you did bring it up, could you please provide a link to a list archive with the discussion? We had the same thought--the patch authors may not have noticed that they made get_page() and other routines effectively GPL-only. However, we then noticed that other major distros were not setting CONFIG_DEBUG_VM, so we decided to contact Fedora first, to get your views on this. We've had CONFIG_DEBUG_VM set for a very long time. It is true we are one of the few distros to do so, but that also makes us the primary source for finding and reporting the bugs DEBUG_VM looks for. It has caught a few issues over time and having the added information available is always helpful to those debugging the problem. When last discussed, some of the core MM developers were surprised but generally supportive of us having this enabled. I would strongly suggest you contact upstream on their change first. Fedora may be the only major distro hitting this, but the code in question is not Fedora specific by any means. Getting resolution upstream is going to more beneficial to a wider set of users and thirdy party module developers. The initial response from the patch author was that he wants to keep it EXPORT_SYMBOL_GPL. I've added Josh to that email thread, but I don't expect that upstream is going to change this, from the sound of it. Oh, and here is the link to the upstream discussion thread, on linux-mm, as requested: http://permalink.gmane.org/gmane.linux.kernel.mm/114539 I just got notified that upstream has accepted the patch for 3.15-rc1, so I think we can now consider this fixed!
-----Original Message-----
From: akpm [akpm]
Sent: Tuesday, April 01, 2014 4:09 PM
To: mm-commits.org; sasha.levin; jwboyer; John Hubbard
Subject: + mm-page_allocc-change-mm-debug-routines-back-to-export_symbol.patch added to -mm tree
Subject: + mm-page_allocc-change-mm-debug-routines-back-to-export_symbol.patch added to -mm tree
To: jhubbard,jwboyer,sasha.levin
From: akpm
Date: Tue, 01 Apr 2014 16:08:44 -0700
The patch titled
Subject: mm/page_alloc.c: change mm debug routines back to EXPORT_SYMBOL has been added to the -mm tree. Its filename is
mm-page_allocc-change-mm-debug-routines-back-to-export_symbol.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_allocc-change-mm-debug-routines-back-to-export_symbol.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-page_allocc-change-mm-debug-routines-back-to-export_symbol.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated there every 3-4 working days
(In reply to John Hubbard from comment #6) > I just got notified that upstream has accepted the patch for 3.15-rc1, so I > think we can now consider this fixed! Well, sort of. That will fix it for 3.15, but it still leaves 3.14 broken. I'll keep an eye out and as soon as the patch lands in Linus' tree I'll backport it. I suspect there might be some further pushback, but I hope to be pleasantly surprised. Added to the F20 3.14.1 rebase. kernel-3.14.1-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.14.1-200.fc20 Package kernel-3.14.1-200.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kernel-3.14.1-200.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5502/kernel-3.14.1-200.fc20 then log in and leave karma (feedback). kernel-3.14.2-200.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/kernel-3.14.2-200.fc20 kernel-3.14.2-200.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. I am unable to compile the nvidia driver. I found another report online: --------------------------------------------------------------------------- Linux drivers 334.21 kernel module fails to compile with kernel 3.14.2-200.fc20.x86_64 https://forums.geforce.com/default/topic/738458/linux-drivers-334-21-kernel-module-fails-to-compile-with-kernel-3-14-2-200-fc20-x86_64/?offset=1 --------------------------------------------------------------------------- I have reverted to the prior kernel I had installed. This rebuilt with no problem so I assume the new kernel is different? 3.12.7-300.fc20.x86_64 The report that you listed show an ACPI-related compilation failure, which is an entirely separate issue from the one being tracking in this bug:
/var/lib/dkms/nvidia/334.21/build/nv-acpi.c:58:21: error: variable ‘nv_acpi_driver_template’ has initializer but incomplete type
static const struct acpi_driver nv_acpi_driver_template = {
We fixed that ACPI compilation problem about a month ago, so I'd like to request that you download a recent version of the NVIDIA driver, and that should fix your problem. If that fails, please file a new bug in order to track the issue.
Thank you for the note. I have found a difference in Release dates between the Long lived branch and the short lived branch. The most recent driver from nvidia is currently in the Long lived branch. I downloaded today and the installer/compile works properly. I assume that the short lived branch did not yet receive the update since it fails, in my prior attempt. I will check the next version of the short lived branch when it becomes available....or just continue to use the long lived branch. http://www.nvidia.com/object/unix.html Linux x86_64/AMD64/EM64T --------------------------------------------- Latest Long Lived Branch version: 331.67 Version: 331.67 Release Date: 2014.4.9 Operating System: Linux 64-bit Language: English (US) File Size: 60.00 MB --------------------------------------------- Latest Short Lived Branch version: 334.21 - Version: 334.21 Release Date: 2014.3.3 Operating System: Linux 64-bit Language: English (US) File Size: 67.00 MB --------------------------------------------- Thank you. Kevin Our system here shows that the next version of the short-lived branch (something later than 334.21) should have that fix. I'm a little surprised that 334.21 is the latest one posted. But yes, a fix should get there pretty soon. There likely won't be any further releases from the short-lived 334 branch, since it will soon be superseded by the 337 short-lived branch. The long-lived branches continue getting updates for some time after their initial release, while the short-lived branches typically do not get updated once a new short-lived branch is available. |