This is an idea that has been brewing for some time: Andrew has mentioned it a couple of times, I've talked to some people about it, and today Davem sent a suggestion along similar lines to me for 2.6.12.

Namely that we could adopt the even/odd numbering scheme that we used to do on a minor number basis, and instead of dropping it entirely like we did, we could have just moved it to the release number, as an indication of what was the intent of the release.

The problem with major development trees like 2.4.x vs 2.5.x was that the release cycles were too long, and that people hated the back- and forward-porting. That said, it did serve a purpose - people kind of knew where they stood, even though we always ended up having to have big changes in the stable tree too, just to keep up with a changing landscape.

So the suggestion on the table would be to go back to even/odd, but do it at the "micro-level" of single releases, rather than make it a two- or three-year release cycle.

In this setup, all kernels would still be _stable_, in the sense that we don't anticipate any real breakage (if we end up having to rip up so much basic stuff that we have to break anything, we'd go back to the 2.7.x kind of numbering scheme). So we should fear odd releases, but track them, to make sure that they are good (if you don't track them, and problems won't be fixed in the even version either)

But we'd basically have stricter concerns for an even release, and in particular the plan would be that the diff files would alternate between bigger ones (the 2.6.10->11 full diff was almost 5MB) and smaller ones (a 2.6.11->12 release would be a "stability only" thing, and hopefully the diff file would be much smaller).

We'd still do the -rcX candidates as we go along in either case, so as a user you wouldn't even _need_ to know, but the numbering would be a rough guide to intentions. Ie I'd expect that distributions would always try to base their stuff off a 2.6.<even> release.

It seems like a sensible approach, and it's not like the 2.4.x vs 2.5.x kind of even/odd thing didn't _work_, the problems really were an issue of too big granularity making it hard for user and developers alike. So I see this as a tweak of the "let's drop the notion althogether for now" decision, and just modify it to "even/odd is meaningful at all levels".

In other words, we'd have an increasing level of instability with an odd release number, depending on how long-term the instability is.

• 2.6.<even>: even at all levels, aim for having had minimally intrusive patches leading up to it (timeframe: a week or two)

with the odd numbers going like:

• 2.6.<odd>: still a stable kernel, but accept bigger changes leading up to it (timeframe: a month or two).
• 2.<odd>.x: aim for big changes that may destabilize the kernel for several releases (timeframe: a year or two)
• <odd>.x.x: Linus went crazy, broke absolutely _everything_, and rewrote the kernel to be a microkernel using a special message-passing version of Visual Basic. (timeframe: "we expect that he will be released from the mental institution in a decade or two").

The reason I put a shorter timeframe on the "all-even" kernel is because I don't want developers to be too itchy and sitting on stuff for too long if they did something slightly bigger. In theory, the longer the better there, but in practice this release numbering is still nothing but a hint of the _intent_ of the developers - it's still not a guarantee of "we fixed all bugs", and anybody who expects that (and tries to avoid all odd release entirely) is just setting himself up for not testing - and thus bugs.

I would maintain that we're still fixing stuff faster than we're breaking stuff. If you look at the fixes which are going into the tree (and there are a HUGE number of fixes), many of them are addressing problems which have been there for a long time.

So as long as we remain in this state, we don't need to do anything. The technology gets closer to a product until we reach the stage where the fixage rate equals the breakage rate. And we're not there yet.

(It's nice that patches are called "fix the frobnozzle gadget", but this analysis would be a lot easier if people would also label their patches "break the frobnozzle gadget" when that's what they do. Oh well).

So I'd suspect that on average, kernel releases are getting more stable. But the big big problem we have is that even though we fixed ten things for each one thing we broke, those single breakages tend to be prominent, and people get upset. It's fairly bad PR that Dell Inspiron keyboards don't work in 2.6.11, for example...

And people will incorrectly (and even wildly) generalise as a result of such silly little isolated bugs. We can wholly address such problems with a 2.6.x.y productisation series.

And something else:

I don't think 2.2 and 2.4 models are applicable any more. There are more of us, we're better (and older) than we used to be, we're better paid (and hence able to work more), our human processes are better and the tools are better. This all adds up to a qualitative shift in the rate and accuracy of development. We need to take this into account when thinking about processes.

It's important to remember that all those kernel developers out there *aren't going to stop typing*. They're just going to keep on spewing out near-production-quality code with the very reasonable expectation that it'll become publically available in less than three years. We need processes which will allow that.

And another else:

Many people on this mailing list want a super-stable kernel as their first (and sometimes only) priority (the product group). But others have other requirements: to make their code avaialble, or to get their hardware supported, or to fix that scalability problem (the technology group). The product group's interests are in conflict with the technology group's.

There will be no solution to this problem which is completely satisfactory to either party.

it exacerbates an on-going issue: we are moving away from "release early, release often", as this proposal just pushes the list of pending stuff back even further.

Developers right now are sitting on big piles, and pushing that back even further means every odd release means you are creating a 2.4.x/2.5.x backport situation every two releases.

To take a radical position on the other side, I would prefer a weekly snapshot as the release, staging invasive things in -mm.

And I think -mm is not enough, even. We have to come up with new ways to manage this ever-increasing flow of data into our tree.

If we want a calming period, we need to do development like 2.4.x is done today. It's sane, understandable and it works.

2.6.x-pre: bugfixes and features
2.6.x-rc: bugfixes only

the reason it does _not_ work is that all the people we want testing sure as _hell_ won't be testing -rc versions.

That's the whole point here, at least to me. I want to have people test things out, but it doesn't matter how many -rc kernels I'd do, it just won't happen. It's not a "real release".

In contrast, making it a real release, and making it clear that it's a release in its own right, might actually get people to use it.

Might. Maybe.

I agree that this is one of the main problems.

But look at how to solve it. The _logical_ solution is to have a third line of defense: we have the -mm trees (wild and wacky patches), and we have my tree (hopefully not wacky any more), and it would be good to have a third level tree (which I'm just not interested in, because that one doesn't do any development any more) which only takes the "so totally not wild that it's really boring" patches.

In fact, if somebody maintained that kind of tree, especially in BK, it would be trivial for me to just pull from it every once in a while (like ever _day_ if necessary). But for that to work, then that tree would have to be about so _obviously_ not wild patches that it's a no-brainer.

So what's the problem with this approach? It would seem to make everybody happy: it would reduce my load, it would give people the alternate "2.6.x base kernel plus fixes only" parallell track, and it would _not_ have the testability issue (because I think a lot of people would be happy to test that tree, and if it was always based on the last 2.6.x release, there would be no issues.

Anybody?

I'll tell you what the problem is: I don't think you'll find anybody to do the parallell "only trivial patches" tree. They'll go crazy in a couple of weeks. Why? Because it's a _damn_ hard problem. Where do you draw the line? What's an acceptable patch? And if you get it wrong, people will complain _very_ loudly, since by now you've "promised" them a kernel that is better than the mainline. In other words: there's almost zero glory, there are no interesting problems, and there will absolutely be people who claim that you're a dick-head and worse, probably on a weekly basis.

That said, I think in theory it's a great idea. It might even be technically feasible if there was some hard technical criteria for each patch that gets accepted, so that you don't have the burn-out problem.

So let's loook at how we could set that up. We need:

• a sucker who wants to do this, or a company that pays for somebody good to do this (and remember: "good" here doesn't necessarily have to mean technical genius, it's about taking abuse and being stable). The whole setup should be such that there can never be any question about the patches for _other_ reasons (to avoid the sucker becoming a target for abuse), so this person really to some degree would be fairly mechanical.

  Don't make it automated, though. That just gets us down the path of flaming about the scripts and automation. And I'm not claiming that we should aim for somebody _stupid_, I'm just claiming that it takes a certain kind of person to do something that is not all that glamorous, and that puts you in the spot.

  We don't ever want to have that spark of "wouldn't this be cool" in this project.

• some very _technical_ and objective rules on patches. And they should limit the patches severely, so that people can never blame the sucker who does the job. For example, I would suggest that "size" be one hard technical rule. If the patch is more than 100 lines (with context) in size, it's not trivial any more. Really. Two big screenfuls (or four, for people who still use the ISO-ANSI standard 80x24 vt100)

  Also, I'd suggest that a _hard_ rule (ie nobody can override it) would also be that the problem causes an oops, a hang, or a real security problem that somebody can come up with an exploit for (ie no "there could be a two-instruction race" crap. Only "there is a race, and here's how you exploit it"). The exploit wouldn't need to be full code that gets root, but an explanation of it, at least.

• a vetting process. You'd have ten people, and five of them would have to sign off on the patch, and even a single veto would shoot it down.

  Again, this is really to protect the sucker, and make it possible to work: I don't think this can work with a creative person (everybody else calls me "flaky", and I much prefer that "creative" word, it sounds so much better), which I personally believe means that we don't _want_ people like Alan, Andrea, Andrew etc etc that have historically maintained their own trees that sometimes have tried to do something like this.

• Finally: this tree never has any history past the "last release". When a new kernel comes, the tree is frozen, and never to be touched again.

  If somebody _else_ wants to base things off this special "sucker tree", and make a fourth level tree that is based on the _previous_ stable tree, that's fine, but that's a separate process. He would be totally free to do so, but the rule is that this particular maintenance program _never_ gets stuck on an old kernel, like the vendor trees always are.

  This is not a long-range tree, it would _purely_ be about one thing and one thing only: the last stable kernel. The people involved (sucker and vetters all) would never have to remember two different trees, or care about problems that aren't in the top-of-tree. Keep ti simple, and keep the rules clear.

Does this mean that some patches would never go into this tree? Yes. It would mean that patches that some people might feel very _strongly_ are good patches would never ever show up in this tree, but on the other hand, I can see this tree being useful regardless, and I think the lack of flexibility in this case is actually the whole _point_ of the tree. The lack of flexibility is the very thing that makes this be the kind of base that anybody else can then hang their own patches on top of. There should never be a situation where "I'd like that tree, but I think xxxx was done wrong".

Might something like this make people happier? (I wrote "happy" rather than "happier" at first, but let's face it, people are better at whining than they are at being happy ;)

We're not aiming for "perfect". Just _trying_ to be perfect is what would kill the whole scheme in the first place. We'd be aiming for "known rules".

Whether people _agree_ with those rules is then actually not a huge issue. There will _always_ be things that people don't agree with. Aiming for consistency is worthwhile in itself.

(Of course, the rules _do_ matter in the sense that there has to be some point to the consistency. You can have a consistent rule that "the ChangeLog entries must rhyme", and I think it's a great rule, and I encourage anybody who wants to to set up such a "rhyming kernel tree", but that doesn't mean that it makes a lot of difference to people ;).

So havign strict rules that allow _one_ kind of consistency that people agree is good is a fine idea.

And Adrian, you can always have a different tree that has another set of rules - and if you use BK you can merge the two and have the "combination of the rules" tree. The reason I would _stronly_ urge very tight rules is that if they aren't tight, it ends up having all the problems we've always seen in other trees.

For example, if the "tight rules tree" allowed reverting an otheriwse good patch because it had a bug (instead of trying to fix the bug), then I would never be able to pull that tree into mine. It would take development _backwards_, and thus it might be sensible for a vendor, but it would automatically mean that it's not a good base for the next kernel version.

And if I can't just say "ok, I'll always take the 'tight rules' tree", then we'd get into the forward-and-backward porting hell again, which would make the whole tree totally pointless. See my point?

Almost without exception maintainers will forget the backport (there are some notable exceptions). Almost without exception maintainers will not be aware that their backport fix clashes with another fix because that isn't their concern.

Linus will try and sneak stuff in that is security but not mentioned which has to be dug out (because the bad guys read the patches too).

And finally Linus throws the occasional gem into the backporting mix because he will (rightly) do the long term fix that rearranges a lot of code when the .x.y patch needs to be the ugly band aid.

So for example Linus will happily changed remap_vm_area to fix a security bug by changing the API entirely and making it do some other things. Or in the case of the exec bug he did a fix that defaulted any missed fixes to unsafe. Fine for upstream where the goal is cleanness, bad for .x.y because the arch people hadn't caught up and did have remaining holes.

You also have to review the dependancy tree for a backport and what was tested - so I skipped the NFS df fix as one example as it had never been tested standalone only on a pile of other NFS fixes.

Alan, I think your problem is that you really think that the tree _I_ want is what _you_ want.

I look at this from a _layering_ standpoint. Not from a "stable tree" standpoint at all.

We're always had the "wild" kernels, and 90% of the time the point of the "wild" kernels has been to let people test out the experimental stuff, that's not always ready for merging. Like it or not, I've considered even the -ac kernel historically very much a "wild" thing, not a "bugfixes" thing.

What I'd like to set up is the reverse. The same way the "wild" kernels tend to layer on top of my standard kernel, I'd like to have a lower level, the "anti-wild" kernel. Something that is comprised of patches that _everybody_ can agree on, and that doesn't get anything else. AT ALL.

And that means that such a kernel would not get all patches that you'd want. That's fine. That was never the aim of it. The _only_ point of this kernel would be to have a baseline that nobody can disagree with.

In other words, it's not a "let's fix all serious bugs we can fix", but a "this is the least common denominator that is basically acceptable to everybody, regardless of what their objectives are".

So if you want to fix a security issue, and the fix is too big or invasive or ugly for the "least common denominator" thing, then it simply does not _go_ into that kernel. At that point, it goes into an -ac kernel, or into my kernel, or into a vendor kernel. See?

The point is not to make a perfect kernel. Two reasons:

• aiming for perfect doesn't work, and would just stress out the maintainer of the sucker-tree. In contrast, aiming for "is this _totally_ non-offensive to everybody" is something that can be done by consensus fairly easily - it's enough that one person says "no", and the issue is solved. No stress, no gray areas.
• perfect doesn't _exist_. As you yourself point out, different people have different goals. The development kernel is not supposed to just revert a patch unless the patch itself was fundamentally flawed. And the development kernel is generally much more geared towards "let's fix this right" rather than "let's apply an ugly bandaid that makes it harder to fix it properly later".

So as long as you see this sucker-tree as a _replacement_ for the -ac kernels, you will _never_ be happy. But my whole point is that it's not a replacement at all. It's a starting point for others. It's something that should be fairly easy to set up, and exactly _because_ the aim is to be inoffensive, it's somethign where people can basically rely on the fact that they don't have to think about things that go into the sucker-tree: we'll set it up so that it's an acceptable base-line for everybody.

Is it an acceptable _solution_ for everybody? No. It's not even aiming to be. It's aiming to be a "let's get at 45% of the way, with 5% of the effort". And the way we make the effort low is by having the hard rules, and having the "single vote throws it out" approach. That's also what limits the tree, but hey, that's ok.

So how do you get to your solution? You could have a "slightly more wild" tree that takes the "other" patches. That "slightly more wild" tree would be for somebody _else_ to maintain (ie it might be you), and that would be the fixes that aren't acceptable to everybody.

In other words: I'm talking about scalability of development, not about fixing every single serious bug. I think this one will catch the embarrassing brown-paper-bag kinds of things, and maybe 90% of the "duh, we had this race forever, but we never even realized", but it wouldn't solve the ones where we had "damn, we did the locking wrong".

But let's face it - _most_ security bugs are of the "duh" variety. That's easy to overlook, because those are the ones you don't worry about, but the fact is, if we can get a tree that makes it possible for most people to just get those fixes without thinking about it, then that's a _good_ thing.

So think of it as a piece in the puzzle, not the whole picture.

Btw, I also think that this means that the sucker-tree should never aim to be a "2.6.x.y" kind of release tree. If we do a "2.6.x.y" release, the sucker tree would be _included_ in that release (and it may indeed be all of it - most of the time it probably would be), but we should not assume that "2.6.x.y" _has_ to be just the sucker tree.

We might want to release a "2.6.x.y" that contains a patch that is too big or too intrusive (or otherwise controversial) to really be valid in the sucker-tree.

And I'd want that to be very much explicit in the "charter" for the sucker-tree. Exactly because the whole point (to me, at least) is to make it _easy_ to maintain. There should never be any discussion at all about patches: either they are universally loved, or they are not. And if the sucker-tree is seen as a 2.6.x.y release tree, then that will _inevitably_ mean that people will start discussing whether one patch or the other is supposed to go in.

My personal gut feeling is that 90% of the patches I _ever_ see are "obvious". If we also cut them down to "must fix an oops/hang/roothole", I think we'll actually get quite far with a sucker tree. We'll never get all the way, but exactly because the tree wouldn't _try_ to get all the way, it would be a lot easier to maintain.

And let's face it, just getting 50% of the way and having somethign that catches the brown-paper-bag stuff so that nobody else every needs to worry about them is really worthwhile.

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm1/

• Added the new bk-audit tree. Contains updates to the kernel's audit feature. Maintained by David Woodhouse.
• The Dell keyboard problems should be fixed. Testing needed.
• Dmitry's bk-dtor-input tree is no longer active and has been dropped.

This is to announce Open-iSCSI project: High-Performance iSCSI Initiator for Linux.

MOTIVATION

Our initial motivations for the project were: (1) implement the right user/kernel split, and (2) design iSCSI data path for performance. Recently we added (3): get accepted into the mainline kernel.

As far as user/kernel, the existing iSCSI initiators bloat the kernel with ever-growing control plane code, including but not limited to: iSCSI discovery, Login (Authentication and Operational), session and connection management, connection-level error processing, iSCSI Text, Nop-Out/In, Async Message, iSNS, SLP, Radius... Open-iSCSI puts the entire control plane in the user space. This control plane talks to the data plane via well defined interface over the netlink transport.

(Side note: prior to closing on the netlink we considered: sysfs, ioctl, and syscall. Because the entire control plane logic resides in the user space, we needed a real bi-directional transport that could support asynchronous API to transfer iSCSI control PDUs: Login, Logout, Nop-in, Nop-Out, Text, Async Message.

Performance.
This is the major goal and motivation for this project. As it happens, iSCSI has to compete with Fibre Channel, which is a more entrenched technology in the storage space. In addition, the "soft" iSCSI implementation have to show good results in presence of specialized hardware offloads.

Our today's performance numbers are:

• 450MB/sec Read on a single connection (2-way 2.4Ghz Opteron, 64KB block size);
• 320MB/sec Write on a single connection (2-way 2.4Ghz Opteron, 64KB block size);
• 50,000 Read IOPS on a single connection (2-way 2.4Ghz Opteron, 4KB block size).

Prior to starting from-scratch the data path code we did evaluate the sfnet Initiator. And eventually decided against patching it. Instead, we reused its Discovery, Login, etc. control plane code. Technically, it was the shortest way to achieve the (1) and (2) goals stated above. We believe that it remains the easiest and the most practical thing on the larger scale of: iSCSI for Linux.

STATUS

There's a 100% working code that interoperates with all (count=5) iSCSI targets we could get our hands on.

The software was tested on AMD Opteron (TM) and Intel Xeon (TM).

Code is available online via either Subversion source control database or the latest development release (i.e., the tarball containing Open-iSCSI sources, including user space, that will build and run on kernels starting 2.6.10).

http://www.open-iscsi.org

Features:

• highly optimized and small-footprint data path;
• multiple outstanding R2Ts;
• thread-less receive;
• sendpage() based transmit;
• zero-copy header processing on receive;
• no data path memory allocations at runtime;
• persistent configuration database;
• SendTargets discovery;
• CHAP;
• DataSequenceInOrder=No;
• PDU header Digest;
• multiple sessions;
• MC/S (note: disabled in the patch);
• SCSI-level recovery via Abort Task and session re-open.

TODO

The near term plan is: test, test, and test. We need to stabilize the existing code, after 5 months of development this seems to be the right thing to do.

Other short-term plans include:

a) process community feedback, implement comments and apply patches;

b) cleanup user side of the iSCSI open interface; use API calls (instead of directly constructing events);

c) eliminate runtime control path memory allocations (for Nop-In, Nop-Out, etc.);

d) implement Write path optimizations (delayed because of the self-imposed submission deadline);

e) oProfile the data path, use the reports for further optimization;

f) complete the readme.

Comments, code reviews, patches - are greatly appreciated!

THANKS

Special thanks to our first reviewers: Christoph Hellwig and Mike Christie.

Special thanks to Ming Zhang for help in testing and for insightful questions.

Fbsplash - The Framebuffer Splash - is a feature that allows displaying images in the background of consoles that use fbcon. The project is partially descended from bootsplash.

Unlike bootsplash, fbsplash has no in-kernel image decoder. Picture decompression is handled by a userspace helper which provides raw image data to the kernel. There is also no support for things like the silent mode and progress bars, as these are best handled by userspace programs.

Truecolor, directcolor and pseudocolor modes are supported. Fbsplash has no dependency on a specific framebuffer driver. It has been tested with at least vesafb, rivafb and radeonfb.

Technical details about the userspace<->kernelspace interface can be found in patch 07/07, which contains the documentation.

The userspace utilities that make use of fbsplash can be found on: http://dev.gentoo.org/~spock/projects/splashutils/

Which all fits very nicely with MEMLOCK rlimit and a tiny wrapper that sets !SCHED_OTHER and execs the audio app..

and as I mentioned a few times if we really want to go for a magic uid/gid-based approach we should at least have one that's useable for all capabilities so it can replace the oracle hack aswell. But the proponents of the patch weren't iterested to invest the tiniest bit of work over what they submited.

as I mentioned a few times, the authors have neither the inclination nor the ability to do that, because they are not kernel hackers. The realtime LSM was written by users (not developers) of the kernel, to solve a specific real world problem. No one ever claimed it was the correct solution from the kernel POV.

I know Jack disagrees but I for one am glad to see the max-RT-prio rlimit patch going in. This probably reflects my sysadmin background, PAM does not scare me at all. Anyway it solves the same problem and will be invisible to any user with a reasonable distro. If musicians end up having to tweak the PAM configuration, then I would say the distro has failed miserably.

That, plus the fact that inherited capabilities could also be used here, except they don't work right. That's a nice, simple and long-standing kernel feature which I think we should have fixed up before piling in more security features.

But I've said that often enough. If nobody has a sufficient need for fixed-up-caps to actually put work into it, nothing happens. And it's a lot of work, because this is a scary feature.

The purpose of LSM is to allow different security models to be implemented. IMHO, a security model here meaning a complete or otherwise significantly enhancing system-wide framework, such as SELinux.

I don't think LSM is a suitable framework for upstream merging of trivial or experimental access control enhancements. They should either be made part of the core kernel under LSM control or incorporated directly into an existing LSM.

One of the reasons I would put forward for this is that it can be dangerous to allow the user to arbitrarily compose security modules.

Also, from an architectural point of view, it's better to think about security models at a high level with broadly defined components (e.g. "DAC" and "MAC"), not as a collection of miscellaneous features.

In the case of this code, I would suggest integrating it into the core kernel, and providing an LSM hook to allow other LSMs to mediate it.

As an example, see the vm_enough_memory hook.

1. is likely to introduce multiuser system security holes like the one created recently when the mlock() rlimits bug was fixed (DoS attacks)
2. requires updates to all the shells
3. forces Windows and Mac musicians to learn and understand PAM
4. is undocumented and has never been tested in any real music studios

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm2/

• UML updates
• fbdev updates
• nfs4 server updates
• new megaraid driver, new iscsi driver, fatfs update, fbdev updates, kitchen sink.
• The below description of what has been added and what has been merged is probably a bit more inaccurate than usual due to my having shuffled things around and confusing myself.
• I dropped the list-of-all-patches from this email due to it being rather long. The unexpurgated version is at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11/2.6.11-mm2/announce.txt

These patches add no execute support to PPC64. They prohibit executing code on the stack, or most any non-text segment for both user space, and kernel.

No execute is supported on Power4 processors and up. These processors support pages that have a no-execute permission bit.

The patches include a base fixup from Anton Blanchard. This includes a fix for the wrong bit being used for no-exec and for read/write on the hardware PTEs.

For distros that compile w/ pt_gnu_stacks, they depend on Ben Herrenschmidt's vDSO patches for signal trampoline. Without it, the application will hang on the first signal due to the return code being put on the signal context stack to return to the kernel on the completion of the signal handler. The changes should be in the latest BK tree.

So here's a first cut at how this 2.6 -stable release process is going to work that Chris and I have come up with. Does anyone have any problems/issues/questions with this?

Everything you ever wanted to know about Linux 2.6 -stable releases.

Rules on what kind of patches are accepted, and what ones are not, into the "-stable" tree:

• It must be obviously correct and tested.
• It can not bigger than 100 lines, with context.
• It must fix only one thing.
• It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.)
• It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
• No "theoretical race condition" issues, unless an explanation of how the race can be exploited.
• It can not contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc.)
• It must be accepted by the relevant subsystem maintainer.
• It must follow Documentation/SubmittingPatches rules.

Procedure for submitting patches to the -stable tree:

• Send the patch, after verifying that it follows the above rules, to stable@kernel.org.
• The sender will receive an ack when the patch has been accepted into the queue, or a nak if the patch is rejected. This response might take a few days, according to the developer's schedules.
• If accepted, the patch will be added to the -stable queue, for review by other developers.
• Security patches should not be sent to this alias, but instead to the documented security@kernel.org.

Review cycle:

• When the -stable maintainers decide for a review cycle, the patches will be sent to the review committee, and the maintainer of the affected area of the patch (unless the submitter is the maintainer of the area) and CC: to the linux-kernel mailing list.
• The review committee has 48 hours in which to ack or nak the patch.
• If the patch is rejected by a member of the committee, or linux-kernel members object to the patch by bringing up issues that the maintainer and members did not realize, the patch will be dropped from the queue.
• At the end of the review cycle, the acked patches will be added to the latest -stable release, and a new -stable release will happen.
• Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure.

Review committee:

• This will be made up of a number of kernel developers who have volunteered for this task, and a few that haven't.

That, and a zillion other specific wordings that people suggested fall under the:
or some "oh, that's not good" issue
rule.

I didn't feel like being all lawyer-like and explicitly spelling out all of the different kinds of bugs that we would be accepting patches for :)

So yes, I don't have a problem with patches to fix regressions.

If you can send in a patch that fixes it in an obvious way and in less than 100 lines of context diff, hell yes.

Remember: all the other constraints still hold. Don't fall into the trap of believing that "if it fixes a regression, it's for -stable". It needs to be _obvious_, and it needs to be small enough that bugs are unlikely.

And that "small enough" is really important. Bugs do happen. Even in "obvious" patches. The whole _point_ of -stable is to try to make them less likely, and the strict constraints are very much a part of that.

This is the start of the stable review cycle for the 2.6.11.3 release. There are 11 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a signed-off-by: line to the patch, please respond with it.

These patches are sent out with a number of different people on the Bcc: line. If you wish to be a reviewer, please email stable@kernel.org to add your name to the list. If you want to be off the reviewer list, also email us.

Responses should be made by Sat, March 12, 23:00 UTC. Anything received after that time, might be too late.

thanks,

the -stable release team (i.e. the ones wearing the joker hat in the corner...)

Timing data on threads at present is pretty crude: when the timer interrupt occurs, a tick is added to either system time or user time for the currently running thread. Thus in an unpacthed kernel one can distinguish three timed states: On-cpu in userspace, on-cpu in system space, and not running.

The actual number of states is much larger. A thread can be on a runqueue or the expired queue (i.e., ready to run but not running), sleeping on a semaphore or on a futex, having its time stolen to service an interrupt, etc., etc.

This patch adds timers per-state to each struct task_struct, so that time in all these states can be tracked. This patch contains the core code do the timing, and to initialise the timers. Subsequent patches enable the code (by adding Kconfig options) and add hooks to track state changes.

Not really `lots of complicated stuff'. Just swap a timer and set a flag on entry:

msp->timers[msp->laststate] += now - msp->lastchange
msp->lastchange = now
msp->laststate = ONCPU_SYS
msp->cflags |= MSA_SYS

And swap timers and clear the flag on exit. The flag's needed to force return to ONCPU_SYS rather than ONCPU_USR if the task preempted or interrupted while in a system call.

If there's a simpler, cheaper, faster way to track time spent in system calls (as opposed to time spent in interrupt handlers, or on the run queue) thn I'd like to know what it is.

And I recognise there're are lots of people who don't want this --- but there are some who do. I've maintained this patch since mid 2003, and have seen a steady trickle of downloads --- one or two a week.

The nvidia framebuffer code added recently is marked as MODULE_LICENSE(GPL), but some things seem a little odd to me..

1. The boilerplate at the top of drivers/video/nvidia/nv_dma.h, drivers/video/nvidia/nv_local.h, and drivers/video/nvidia/nv_hw.c doesn't seem to be a GPL-compatible license. It seems to be an nvidia specific license with an advertising clause, and something that adds restrictions on rights of U.S. Govt end users.
2. Some of these files clearly came from XFree86 judging from the CVS idents in the source. Was this XFree86 code dual-licensed by its original authors? If so, it isn't clear.

As there were no complaints about the patches posted a few days ago, I've released 2.6.11.3 with them in it.

It's available now in the normal kernel.org places:

kernel.org/pub/linux/kernel/v2.6/patch-2.6.11.3.gz

which is a patch against the 2.6.11 release (note, this is different than before, and should fix all of the previous complaints.)

I've also rediffed the 2.6.11.2 patch against the 2.6.11 release, instead of the 2.6.11.1 release, and updated it. There are incremental patches between the 2.6.11.y releases at:

kernel.org/pub/linux/kernel/v2.6/incr

If anyone has any issues with the way the patches are diffed, please let me know.

A detailed changelog can be found at:

kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.11.3

A bitkeeper tree for the 2.6.11.y releases can be found at:

bk://linux-release.bkbits.net/linux-2.6.11

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.11.2 and 2.6.11.3, as it is small enough to do so.

There are 4 patches being posted here in response to this message that start us on the way toward cleaning up the driver model code so that it's actually usable by mere kernel developers :)

The main problem with the class code, is that _everyone_ gets it wrong when trying to use it (and that includes me.) So, because of that, the class_simple wrapper was written. So almost everyone used that. That pretty much proved that the class_simple interface was the proper type of interface for the main class code itself.

Because of that, Kay wrote a first cut at adding the class_simple type of interface to the class core (he posted it to lkml a month or so ago.) I've finally taken that code, tweaked it a bit (fixing a module ownership issue that sprang up due to the class core changes, and changed the locking model) and added it to my bk-driver tree. I've also taken his tty and input patches that convert those subsystems over to the new functions (it's pretty much a simple search and replace for existing class_simple users.)

Then I moved the USB host controller code to use this new interface. That was a bit more complex as it used the struct class and struct class_device code directly. As you can see by the patch, the result is pretty much identical, and actually a bit smaller in the end.

So I'll be slowly converting the kernel over to using this new interface, and when finished, I can get rid of the old class apis (or actually, just make them static) so that no one can implement them improperly again...

I disagree with this last step. What I liked about the driver model is that once you convert (properly) subsystem to using it you automatically get your proper refcounting and memory gets released at proper time. The change as it proposed disconnects class device instance from the meat so separate refcounting implementation is needed. This increases maintenance costs.

I always viewed class_simple as a stop-gap measure to get hotplug events in place until proper implementation is done. Please leave the original interface in place so it can still be used if one wshes to do so.

And what about device_driver and device structure? Are they going to be changed over to be separately allocated linked objects? If not then its enouther reason to keep original class interface - uniformity of driver model interface.

I've release 2.6.11.4 with two security fixes in it. It can be found at the normal kernel.org places.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between 2.6.11.3 and 2.6.11.4, as it is small enough to do so.

As far as I can see, the "super-stable" kernel releases should not affect module ABI in any way, that is, a module compiled for 2.6.11 or 2.6.11.2 should work with 2.6.11.4 and vise versa. Ofcourse I'm talking about modules which are out of the main kernel tree.

But. EXTRAVERSION gets changed with every 2.6.11.x release, thus making out-of-tree modules incompatible just because they contain different kernel version tag.

The question is obvious: Is this a correct/intended behaviour? Maybe, just maybe, EXTRAVERSION should not be taken into account when desciding if a given module compiled for a given kernel?

This is the start of the stable review cycle for the 2.6.11.5 release. There are 9 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let us know. If anyone is a maintainer of the proper subsystem, and wants to add a Signed-off-by: line to the patch, please respond with it.

If you wish to be added or removed from the reviewer list please email stable@kernel.org.

Responses should be made by Fri, March 18, 23:00 UTC. Anything received after that time, might be too late.