Hi Greg,
Nice try, but please read the file I pointed you at and resend it with
the needed information...
I've read through that file, but am having trouble seeing what the
problem is. Here's what I've checked:
- It must be obviously correct and tested.
> - It cannot be bigger than 100 lines, with context.
- It must fix only one thing.
Check.
- It must fix a real bug that bothers people (not a, "This could be a
problem..." type thing).
Yep, we've seen this in the wild, as mentioned in the second changelog.
- 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.
It's a hang on boot.
- New device IDs and quirks are also accepted.
- No "theoretical race condition" issues, unless an explanation of how the
race can be exploited is also provided.
Nope, neither of these.
- It cannot contain any "trivial" fixes in it (spelling changes,
whitespace cleanups, etc).
Just the addition of a NULL check, as required to fix the issue.
- It must follow the Documentation/SubmittingPatches rules.
I believe it's all ok here...
- It or an equivalent fix must already exist in Linus' tree (upstream).
Yep, 78c5c68a.
And as for the process:
- Send the patch, after verifying that it follows the above rules, to
[email protected]. You must note the upstream commit ID in the
changelog of your submission.
Done, upstream commit is there.
- To have the patch automatically included in the stable tree, add the tag
Cc: [email protected]
in the sign-off area. Once the patch is merged it will be applied to
the stable tree without anything else needing to be done by the author
or subsystem maintainer.
- If the patch requires other patches as prerequisites which can be
cherry-picked than this can be specified in the following format in
the sign-off area:
Cc: <[email protected]> # .32.x: a1f84a3: sched: Check for idle
Cc: <[email protected]> # .32.x: 1b9508f: sched: Rate-limit newidle
Cc: <[email protected]> # .32.x: fd21073: sched: Fix affinity logic
Cc: <[email protected]> # .32.x
Signed-off-by: Ingo Molnar <[email protected]>
The tag sequence has the meaning of:
git cherry-pick a1f84a3
git cherry-pick 1b9508f
git cherry-pick fd21073
git cherry-pick <this commit>
This isn't a mainline submission for automatic inclusion in stable, so
this doesn't apply.
- 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 and by the relevant subsystem maintainer.
- Security patches should not be sent to this alias, but instead to the
documented [email protected] address.
.. and these bits are about process.
Or have I missed something? I'm about to have a brown-paper-bag moment,
right? :)
Cheers,
Jeremy
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
