Stable kernel updates 2.6.27.18 and 2.6.28.6

[Posted February 17, 2009 by corbet]

Another round of stable kernel updates (2.6.27.18 and 2.6.28.6) has been released. Once again, both updates contain a long list of important fixes; users are "strongly encouraged" to upgrade.

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 17, 2009 19:22 UTC (Tue) by PO8 (guest, #41661) [Link] (15 responses)

As an example of what I'd love to see with these posts:

2.6.28.6 contains quite a few fixes to core networking code and network drivers, as well as the usual device driver fixes including some important hda updates. 2.6.27.18 contains most of these fixes and some minor upgrades including a quirks fix for the Apple wireless keyboard.

Is this summary complete and accurate? I don't know; I'd have to read the detailed changelogs, and I didn't want to spend more than a couple of minutes on this example. But it would be a real service if either Greg KH or LWN could provide a summary like this with new kernel releases.

service

Posted Feb 17, 2009 22:07 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

it would be a real service if

and how much would this real service be worth?

service

Posted Feb 17, 2009 23:00 UTC (Tue) by xorbe (guest, #3165) [Link]

Would you like to sponsor a paid survey? ;-)

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 17, 2009 23:31 UTC (Tue) by gregkh (subscriber, #8) [Link] (12 responses)

As I've repeated many times, this information is already there, in the shortlog comments directly below the announcement in the same email.

If you are just wanting me to summarize the summaries already listed, well, that sounds like make-work for no good value.

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 18, 2009 7:26 UTC (Wed) by aleXXX (subscriber, #2742) [Link] (11 responses)

The shortlog contains things like

"writeback: fix break condition"
"mac80211: restrict to AP in outgoing interface heuristic"
"x86: microcode_amd: fix wrong handling of equivalent CPU id"

So I know there have been fixes with WLAN and AMD cpus, but I really have
no idea what problems they caused and whether I may experience these
problems.

So I agree with the original poster that a sentence like "if you
experience problems with <foo> and <bar>, you should update" would help.
With this minor release there are about 50 patches, and I think not all
of these 50 patches can be really critical for every 2.6.28.x user (but I
don't know).

Alex

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 18, 2009 7:39 UTC (Wed) by gregkh (subscriber, #8) [Link] (9 responses)

Did you read the full changelog for those specific comments in question? If they don't suffice, you always have the code, and even further, the email address of the person who wrote it if you have questions.

Writing up a full description as you are asking for, of the issues involved in 50+ patches a release, when I'm doing about 2-3 releases a week, would take more time than all of the other work to do the stable releases. As such, it is not something that I am going to be doing, sorry.

You are still answering the wrong question

Posted Feb 18, 2009 7:51 UTC (Wed) by khim (subscriber, #9252) [Link] (8 responses)

You are still thinking as kernel developer. Users are not interested in knowing the details of bug. They do want to know if this bug affects them or not. And the only answer developers can give is: if the patch does not change the code you are actually using - then the answer is "no", you don't need it; othwerwise the answer is "we don't know".

This answer tends to upset the user but it's honest truth: you do have a way to trigger bug (otherwise it'll not go in -stable), but if there are only one way to trigger it or ten thousands ways is unknown - and nobody is paid to discover this answer. In most cases it's just impossibe to answer anyway so any investigation will be waste of time.

You are still answering the wrong question

Posted Feb 18, 2009 8:07 UTC (Wed) by gregkh (subscriber, #8) [Link] (5 responses)

> You are still thinking as a kernel developer.

Thank you, I'll take that as a compliment :)

You are still answering the wrong question

Posted Feb 18, 2009 12:56 UTC (Wed) by efexis (guest, #26355) [Link] (4 responses)

I must respectfully disagree with this, seemingly becoming more popular complaint. I've learnt more about linux internals and changes in the state of the art regarding the kernel from LWN than probably nearly everywhere else put together; there are indepth articles covering a /huge/ amount of detail. If people really wanted to know more, they would, and I'm living proof. Linux isn't the right operating system for those who want to be spoon fed, and I'm glad there still exists a platform for those who do want to learn.

We have this forum so that if anyone notices that something fixes something for them, they can post a "wahey I can use my xyz card now at full speed", and share that knowledge, something that often does happen. There's no information cap here. Really anyone can join in.

Yes, but it's only interesting if you want to know about kernel development...

Posted Feb 18, 2009 16:25 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

I've learnt more about linux internals and changes in the state of the art regarding the kernel from LWN than probably nearly everywhere else put together; there are indepth articles covering a /huge/ amount of detail. If people really wanted to know more, they would, and I'm living proof.

This is all well and good but the key insight is simple and does not requite deep knowledge. Linux is not a microkernel. It's big, monolythic kernel. This approach has advantages but disadvantage is huge: any bug can potentially affect any other part of kernel. In some cases you can prove that this or that bug is contained and some checks guarantee it'll not propagate and crash the kernel and/or create security hole - but these are exceptional situations, not rule. And this basically means that each and every -stable update is "must-have" update.

This is kind of hard to swallow for users who are accustomed to skip updates of other programs and sometimes use old version for years, but the difference is simple: other programs are sheltered from each other by kernel (and system policy, of course). There are no such protection in the kernel itself. So you either need to trust developers and upgrade or check each and every patch from -stable kernel to know if it'll affect your particular system with your particular kernel configuration options. There are no easy and simple shortcuts.

Yes, but it's only interesting if you want to know about kernel development...

Posted Feb 18, 2009 17:09 UTC (Wed) by efexis (guest, #26355) [Link]

Ish, yeah, but within limits. I've moved many partitions over to ext4, so I keep an eye out for patches that contain ext4 updates. Most of my systems don't use LVM/MD code, and most are PATA rather than SATA/SCSI, so updates involving those aren't really important to me. Networking, scheduling,... are all working fine, so updates there depend on how I'm feeling at the time, although on my online servers (rather than home/development machines), networking updates are more important because of the security implications, although many aspects that I know are compiled out exclude my need to do those updates, such as the nbd update... knowing all these type things, I can get a good idea of how important me applying - or equally, not applying - certain updates is.

Yes, it may seem to many to be a bit like rocket surgery, but you either do it yourself, or you put the trust in someone elses judgement (such as a distro etc). People can't expect sweeping statements of whether updates are important to all people in all cases, or list all the possible scenarios that an update is important for. You have to know your own system, or use somebody elses.

Yes, but it's only interesting if you want to know about kernel development...

Posted Feb 18, 2009 17:14 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Bugs in parts of the kernel you don't have compiled in cannot affect the
functioning of the kernel you're running, so no, not every -stable update
is crucial.

What's your point?

Posted Feb 18, 2009 17:23 UTC (Wed) by khim (subscriber, #9252) [Link]

I've said this quite explicitly before and you don't need any explanations for that - changelog includes this information as well...

You are still answering the wrong question

Posted Feb 18, 2009 15:45 UTC (Wed) by MisterIO (guest, #36192) [Link] (1 responses)

The thing to say to users who don't understand what's written in the short and long log is very simple : "Update!".

You are still answering the wrong question

Posted Feb 18, 2009 17:29 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Or use the kernel from your distro and hope its maintainers understand it well enough.

Do you volunteer to write such summaries?

Posted Feb 18, 2009 7:43 UTC (Wed) by khim (subscriber, #9252) [Link]

So I agree with the original poster that a sentence like "if you experience problems with <foo> and <bar>, you should update" would help.

Quite often you don't know what problem the patch actually fixes. The story goes like this:
1. My kernel oopsed and here is the log.
2. Oh, shit - we are checking this variable without appropriate mutex!
3. Have this patch fixed your problem?
4. Yup - does not happen anymore.
5. Fix goes to main and to stable.

See? Nobody knows what actually triggers the bug - the bug was there, it was genuine bug and it can be triggered in some conditions (may be obscure ones). Now it's fixed. That's all the information known about the bug. Sometimes more information is known (actually usually more information is known) but rarely (if ever) you can say: you can only trigger this problem doing this and that. One obvious exception is where patch touches the code not included in your kernel - but this case does not need any changelogs to check.

To create "simple sentence" like you've suggested you need detective work - and there are no volunteers.

With this minor release there are about 50 patches, and I think not all of these 50 patches can be really critical for every 2.6.28.x user (but I don't know).

Problem is: nobody knows. You have the source, you can check. Or you can leave it to your ditribution maintainers...

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 18, 2009 8:22 UTC (Wed) by job (guest, #670) [Link] (4 responses)

I'm curious. The same wording ("strongly encouraged") has been used for several releases now. The seem to be specifically chosen. Do they carry some special meaning?

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 18, 2009 12:37 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

that wording evolved due to complaints here on LWN from people who said that there were important patches in a release and that Greg wasn't makeing a strong enough statement in the release notes about the need to upgrade.

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 18, 2009 13:04 UTC (Wed) by efexis (guest, #26355) [Link]

I was getting a row of cheerleaders goin "go on upgrade, it's the newest latest version!!! Gimme a 2! Gimme a 6! Gimme a 28! Gimme a 6!" and generally feeling good about the encouragement I was getting.

Way to burst my bubble.

Stable kernel updates 2.6.27.18 and 2.6.28.6

Posted Feb 18, 2009 15:50 UTC (Wed) by MisterIO (guest, #36192) [Link]

I just hope it won't evolve anymore, or we'll be seeing something like : "Users are very super encouraged to upgrade"

This means you must update...

Posted Feb 18, 2009 16:29 UTC (Wed) by khim (subscriber, #9252) [Link]

This wording is used when patch touches the code which is running on most system. If the update only touches some obscure driver or network protocol (and so chances are high you'll never use fixed code) the wording will be different. But if patch touches "kernel core" (even if it's done via one patch out of 50) then the "strong recommendation" is the only way to go...