Zack's Kernel News

Difficult Bug Hunt

Michael Hocko used git bisect to track down a problem resuming a suspended system. Instead of resuming, the system would just reboot. He posted a patch to revert the commit that seemed to cause the problem.

H. Peter Anvin asked for more details about Michael's system; H. Peter said, "This is one of a series of extremely bizarre suspend to RAM failures we are trying to make sense of." The particular cause of the problem, he said, was "not just bizarre, this is extremely disturbing."

The reason H. Peter found this so disturbing is that the piece of code Michael had reverted did nothing more than flip the NX bit. The NX bit is used in some CPUs to mark areas of memory as being "never executable" and flipping that bit should never affect anything just on its own. The only way it could be involved in a problem with suspend-to-RAM is if there were some deeper malignancy.

Linus joined the discussion and traced the problem to __initdata, a special part of the kernel that marks certain things as being solely related to initialization, so that once initialization is completed, the kernel can free all associated memory.

Apparently, the NX bit had been preventing a particular region of memory from executing as code, and that region of memory had been getting corrupted by __initdata. As long as the NX bit had been set as it was, the corruption problem had been covered up. That's why Michael had been able to bisect the issue and trace it to a patch that flipped the NX bit – and why reverting that patch had seemed to fix the problem. Michael posted a fresh patch to fix the underlying issue with the __initdata, and Linus incorporated it immediately into his tree.

License Discussion

Eric Appleman opened a wriggling can of worms when he suggested gathering Linux kernel copyright holders (i.e., anyone who's contributed code to the kernel) into a group to enforce the GPL against license violators. Luke Leighton said he'd love to join this sort of thing, although he admitted that his copyrighted contributions were few. Almost as an aside, he remarked, "can it be specifically noted, from this moment onwards, that all contributions that I have made to the linux kernel are dual-licensed under both the GPLv2 and also the GPLv3+ license?"

Cole Johnson replied that as far as he knew, "Linus said he will NOT use the GPLv3 for the kernel." This apparently threw Luke into a rage, and he said neither Linus Torvalds nor anybody else could prevent him from releasing his copyrighted code under any license he wanted. Among the variety of relatively heated posts in this thread was Theodore Ts'o reply to the whole idea of dual-licensing with the GPLv3:

It's not just Linus; many senior Linux kernel developers have spoken very clearly that the anti-Tivoization clause in GPLv3 is totally unacceptable …. This means that GPLv3-only code is always going to be incompatible with code released as part of the Linux kernel, because substantial parts of the kernel have and will be available only under a GPLv2 only license.

If anyone wants to release their code under a dual-license, it's easiest if that's how you submitted the code originally. For example, … to encourage its use in other operating systems.

If you have only contributed a few lines … specifying that "these 15 lines of the function I_worship_at_the_altar_of_rms() are under the GPLv2/v3, even through the rest of the file is GPLv2-only" is not something that we generally do. Speaking as a subsystem maintainer, … if someone insisted on line-level copyright statements, I'd just simply reject the patch rather than dealing with the accounting nightmare. If you want to add a GPLv2/GPLv3 dual license to a file, … you'll need to get the consent of everyone who has contributed changes to that file.

Finally, as Jonas has stated, if you are trying to impose the anti-Tivoization clause through the back door, it's not going to have that effect, since people can always choose either license for dual-licensed code, and for the kernel GPLv2 always has to be one of the choices.

A bit later in the discussion, he posted this equally fascinating follow-up [3]:

The more subtle thing to consider is that with dual-licensed code,  *anyone * has the ability to strip one of the licenses from the code in the course of making [a] modification. … That's a completely legal thing to do …. The reason why I dislike someone taking GPLv2/v3 code and stripping out the GPLv2 license is because it makes new versions of code which I had originally written becoming available only under a GPLv3 license.

But there's a flip side to this, which is, the same legal argument  *also * allows a kernel maintainer to take a contribution which is under a GPLv2/v3 or GPLv2+ license, and incorporate it into a GPLv2-only file, and not bother to mark that it originally came from a GPLv2+ or GPLv2/v3 contribution. … you could find that contribution and extract that code and use it in some other GPLv3 project. But we are under no obligation to mark that a particular set of lines in a file originally came from a GPLv2/v3 or GPLv2+ contribution. … That's not to say that certain drivers won't be dual licensed, for specific reasons, but you shouldn't expect that core kernel files will be GPLv3 compatible in the near future.

Rob Landley gave a very bleak yet highly interesting assessment of the modern history of "copyleft" [4]. To Luke, he said: You're aware that copyleft in general is declining, right?

"The GPL" was synonymous with copyleft … and the only thing programmers had to know is whether or not some other license was GPL-compatible. If it was: treat it as GPL. If it wasn't: ignore it.

But there's no "the GPL" anymore. Linux and Samba can't share code, even though they implement two ends of the same protocol. And making your project "GPLv2 or later" means you can't take code from _either_ source. These days the GPL largely serves to _prevent_ code re-use, and people have responded to the perceived problems with "GPL-next" initiatives where they fragment copyleft further with Affero variants, by using creative commons on code, and so on. But copyleft only ever worked as one big universal license, and now it doesn't.

… the most common license on Github is "no license specified," and that's not just ignorance, that's napster-style civil disobedience from a generation of coders who lump copyright in with software patents and consider it all "too dumb to live." (You think GPL enforcement suits are viewed any differently than DMCA takedown notices on youtube, both coming from clueless old people?)

Now add in Android's official "no GPL in userspace" policy, which means that if you preinstall GPL (or LGPL) software in your install image, you can't use the Android trademark to describe your product. (Did I mention that smartphones are replacing the PC? … ) I'm sorry, but Richard Stallman _screwed_up_. GPLv3 succeeded where Sun's CDDL failed: it split copyleft into incompatible warring factions which are collectively shrinking in market share because none of them are as useful as "The GPL" was. … Advocating for GPLv2 to go away is sad, but understandable. Expecting GPLv2 to be replaced by GPLv3 is just delusional.

Infos

  1. Al Viro on George Spelvin's "hackish" solution: http://lkml.indiana.edu/hypermail/linux/kernel/1303.2/02764.html
  2. Tux3 fsync debate: http://lkml.indiana.edu/hypermail/linux/kernel/1305.1/02246.html
  3. Theodore Ts'o on dual-licensed code in the kernel: https://lkml.org/lkml/2013/5/20/218
  4. Rob Landley on copyleft: https://lkml.org/lkml/2013/5/21/139

The Author

The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching 10,000 messages in a week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown.

Read full article as PDF:

090-092_KernelNews.pdf (336.21 kB)

Related content

comments powered by Disqus

Direct Download

Read full article as PDF:

090-092_KernelNews.pdf (336.21 kB)

News

njobs Europe
What:
Where:
Country:
Njobs Netherlands Njobs Deutschland Njobs United Kingdom Njobs Italia Njobs France Njobs Espana Njobs Poland
Njobs Austria Njobs Denmark Njobs Belgium Njobs Czech Republic Njobs Mexico Njobs India Njobs Colombia