kernel weekly news – 04.02.12

Posted: February 4, 2012 in kernel

Hello everyone!

-Dave Airlie has drm fixes, Chris Mason updates btrfs, John
W. Linville has wireless ups for 3.3, Martin Schwidefsky announces
s390 patches for -rc2 and David Miller updates networking:

1) Setting link attributes can modify the size of the attributes
that would be reported on a subsequent getlink netlink operation,
therefore min_ifinfo_dump_size needs to be adjusted. From
Stefan Gula.

2) Resegmentation of TSO frames while trimming can violate invariants
expected by callers, namely that the number of segments can only
stay the same or decrease, never increase. If MSS changes, however,
we can trim data but then end up with more segments. Fix this by
only segmenting to the MSS already recorded in the SKB. That’s
the simplest fix for now and if we want to get more fancy in the
future that’s a more involved change.

This probably explains some retransmit counter inaccuracies.

From Neal Cardwell.

3) Fix too-many-wakeups in POLL with AF_UNIX sockets, from Eric Dumazet.

4) Fix CAIF crashes wrt. namespace handling. From Eric Dumazet and
Eric W. Biederman.

5) TCP port selection fixes from Flavio Leitner.

6) More socket memory cgroup build fixes in certain randonfig situations.
From Glauber Costa.

7) Fix TCP memory sysctl regression reported by Ingo Molnar, also from
Glauber Costa.

-Greg KH has USB and TTY updates for -rc1, Guenter Roeck has a hwmon pull
request for -rc2, Linus Walleij announces the release of all the pinctrl
fixes accumulated since -rc1, Arnaldo Carvalho de Melo has perf/urgent
and perf/core fixes and …

-Linus Torvalds announces the release of 3.3-rc2:

Ok, so for no real reason at all – except me being disorganized and
just not thinking about it – rc2 is several days delayed. It’s closer
to two weeks rather than the standard one week I try to have between

So as a result of that, this -rc2 is a bit bigger than the ones
historically, but that’s really just because timing-wise it’s more
like an -rc3. And for that, it’s right in line with normal trends, and
possibly even on the smaller side.

Anyway, apart from that mind-fart, there’s nothing particularly odd
here. The diffstat is pretty flat – indicative of mostly small changes
spread out. Which is what I like seeing, and we don’t always see at
this point. There’s some file movement (8250-based serial and the arm
mx5 -> imx merge), but otherwise really not a lot of excitement. Good.

One thing that has happened is that I’ve liked seeing the merge
message things that have come in through signed tags so much that I’ve
decided to try to write more explanations even for the merges that
don’t get that kind of love from their subsystem maintainers. Some
subsystem maintainers (David with networking is a good example) have
tended to write nice good explanations in their pull requests, and
I’ve started to try to make those kinds of things part of my merge

I’m not sure how many people really look at merges, and maybe it’s a
waste of my time, but I thought I’d try it. I’ve also spent more
effort trying to explain even fairly trivial merge conflicts (although
the truly trivial “touched next to each other” that just aren’t
interesting from a code standpoint I generally have left without

Of course, if the submaintainer doesn’t really give me much to work
with, and the merge was all clean and didn’t have any issues, we still
have fairly bare merge messages. But on the whole I’m trying to act as
a good example of what a merge message *should* look like, since I’ve
been complaining about some submaintainers not doing a particularly
good job at explaining their reverse merges even when they actually
made sense (most of the time, the reverse merge is just ugly and
shouldn’t have been done at all, but when the merge makes sense,
please do spend the time explaining it).

Anyway, I’m planning on continuing doing this at least for now,
although see above about the “submaintainer doesn’t really give me
much to work with” case. Signed tags are obviously preferred – and
while the signature itself is part of the reason, I think the whole
“you can use them to explain your pull request” should actually be
seen as a bigger part. But I’ll try to do it even for the unsigned
case if you just give me something to work with (and if there are
conflicts, I’m hoping that my more verbose explanation of the conflict
resolution is useful too).

Making appreciative noises – if you really do care – may be a good
idea just to convince me that it’s worth the effort in the long run,
but I have to say that even just looking at the logs (which is
something I do a fair amount) is what convinced me to start, so I
suspect I’ll try to continue doing this even if nobody else cares.

Other comments about -rc2? Not much. I declined one or two pull
requests because they didn’t seem to be appropriate for post-merge,
but I’m obviously always up for debate (even if sometimes I just
ignore arguments, and other times it just results in me swearing at
you – neither situation is necessarily an indication of much more than
my mood at the time, of course).

Go forth and test.


-Roland Dreier has Infiniband updates, James Morris updates linux-security
(MPI library fixes), John Stultz has changes for 3.4 regarding clocksource,
timekeeping and RTC, and Ingo Molnar has perf. scheduler and x86 fixes .

-Ireland’s own Dave Airlie updates drm with nouveau and radeon goodies,
Sage Weil has ceph updates for -rc3, and this ends my work this week.
Be good to each other.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s