kernel weekly news – 21.05.2011

Posted: May 21, 2011 in kernel

Hello ev’ryone! This week we’ll start with

-Dan Williams announcing quite a big iSCSI update, Trond Myklebust
has NFS client bugfixes, David Miller has updates for the networking
tree –

 Some stragglers, the bridging one is pretty important as it hits
virtualization users:

1) Do not run ipv4 options parser on ipv6 packets in bridging,
   from Stephen Hemminger.

2) Regression fix, changes to TOS/tclass handling made ECN stop
   being done on ipv6 connections.  Fix from Steinar H. Gunderson.

3) On-wire packets for bridging modes were defined in a way (lacking
   necessary __packed directives), such that they didn't work properly
   on some architectures (namely, ARM).  Fix from Vitalii Demianets.

4) Long ago net_device_ops conversion broke several m68k drivers
   based upon the 8390 infrastructure.  Fix from Geert Uytterhoeven.

5) SFC needs to map certain chip memory as uncacheable, from Ben

6) Memory hotplug oops fix in ehea driver from Anton Blanchard.

7) IBSS oops fix in intel wireless drivers, from Stanislaw Gruszka.

8) Command pending queue locking fix in libertas.

Please pull, thanks a lot! 

– , Chris Mason has btrfs updates and
Arnaldo Carvalho de Melo updates the perf/urgent tree.

-Keith Packard updates drm-intel-next, Dave Airlie comes forward with
drm fixes (“two regression fixes, one on Intel Q67 with semaphores, and one in the
switcheroo code. One black screen on radeon problem, oops on undock fix,
and a couple of minor updates to some changed regs on newer radeon hw.”),
new networking fixes are announced by David Miller –
“1) SFC crashes on ‘ethtool -d’, from Ben Hutchings.

2) VMXNET3 driver doesn’t set LRO correctly on probe, this hits a lot
of VMWare users. Fix from Thomas Jarosch.

3) IPVS needs to use correct SEQ release interface, otherwise it leaks
netns references. Fix from Hans Schillstrom.

4) Users can (via tun/tap for example) trigger the warnings generated
by the netdevice feature validation checks we make. Make such
warnings of DEBUG level so user’s can spam the logs. Fix from
Michał Mirosław.

There is a dup of bridge netfilter fix (already in your tree) with
commit ID cb68552858c64db302771469b1202ea09e696329 in here because
Pablo applied it to the netfilter tree as well (and in his tree it
appears as commit d8083deb4f1aa0977980dfb834fcc336ef38318f). So when
I merged his tree to get the IPVS namespace leak fix, I got the bridge
netfilter fix dup too.” – and Ben Hutchings updates the linux-firmware tree.

-Thomas Gleixner announces timer fixes for .39, Ingo Molnar has x86 fixes,
also perf fixes, Mauro Carvalho Chehab has media fixes for -rc7, Grant
Likel y has a sparc two-piece patchset and Joel Becker updates the
ocfs2 for 2.6.39-rc .

-Benjamin Herrenschmidt has few updates for the powerpc tree aaaaaand….

-Linus announces 2.6.39 :

 So it's delayed a few days, and I really was struggling with the
decision of whether I wanted to cut a final release at all: it could
easily have made more sense to just do an -rc8. However, since I'm
going to be at LinuxCon Japan in two weeks, the choice for me ended up
whether I should just release, or drag it out *three* more weeks, or
have some really messy merge window with a break in between.

None of those choices really looked all that great.  There were
certainly more code changes since -rc7 than I really was all that
happy with, and some outstanding discussion. Doing another -rc
wouldn't necessarily have been a bad idea, but then I just decided
that if I held off making the release, next week my timing choices
would have been even worse.

So there it is. The one thing that pushed me over the edge is that
this release window has been fairly "easy". -rc2 was calm, -rc3 was
_really_ calm, and -rc7 was tiny. And while this has more commits than
-rc7 had, I didn't feel like that changed the overall picture much: we
really did have much less churn after the merge window closed than we
usually do. Which actually makes me pretty happy about the state of

(Just to put that "calm after the merge window" in quantitative
numbers: doing some git statistics, we have fewer commits after -rc1
than any of the last ten releases).

As to the merge window for 2.6.40 (which is obviously open now):
because of the delay, the normal 14 days would be with the last two
days when I'm already in Japan. Which is certainly not unthinkable
(I'll have my laptop and access to wifi, and could do some final
tweaks that way even if I wouldn't want to do a bigger portion of a
merge window while traveling). But I do want to warn that if I get the
feeling that I've merged "enough", I might just make it easier for
myself and cut it two days short and release just before I leave on
Memorial day (which for the non-US based of you is May 30th this

Having a slightly shorter (and actually smaller, not just more
hurried) merge window and release cycle for 2.6.40 might not be a
horrible fate. Of course, I just know that you're all actively trying
to sabotage that dream of mine.

But I can still dream, can't I?


-Steven Rostedt has updates for the trace tree (actually just one update),
Dave Jones has a bunch of updates for kvm, aimed at .40, Konrad Rzeszutek Wilk
updates parts of the xen tree, Geert Uytterhoeven has updates for the m68k tree,
also aimed at 2.6.40 and Roland Dreier updates the infiniband tree for .40 as well.

-Last moment news : Ingo Molnar – core/{iommu,locking} changes for .40,
also irq, timersscheduler, perf, basically most of Ingo’s expertise, Greg Kroah-Hartman,
besides starting the review cycle for some kernel versions, starts the big driver-core merge
for .40 and Kent Overstreet has bcache pull request :

 Bcache is a patch to use SSDs to cache arbitrary block devices.  Its
main claim to fame is that it's designed for the performance
characteristics of SSDs - it avoids random writes and extraneous IO at
all costs, instead allocating buckets sized to your erase blocks and
filling them up seqentially. It uses a hybrid btree/log, instead of a
hash table as some other caches.

It does both writethrough and writeback caching - it can use most of
your SSD for buffering random writes, which are then flushed
sequentially to the backing device. Skips sequential IO, too.

Posting a new version has been long overdue, there's quit a bit of new

Backing devices now have a bcache specific superblock, and bcache now
opens them and provides a new stacked device to use instead of the old
way of hooking into an existing block device - and that code has been

This means you can't accidently use a backing device without the cache,
which is particularly important with writeback caching.

Journalling is done. Bcache does not need a journal for consistency -
it was reliably recovering from unclean shutdown months ago. It's purely
for performance - previously random synchronous btree updates required
writes to multiple leaves, now they can all get staged in the journal.
We can do btree writes much more efficiently and we get a significant
boost in random write performance.

The sysfs interface completely changed, again, for multiple cache device
support. Multiple cache devices aren't working yet, I've got all the
metadata changes done (keys with variable numbers of pointers), struct
cache and cache_set pulled apart - at this point it's just a lot of
detail work left which shouldn't break existing code.

The code should be substantially ready for mainline, but I'm going to
hold off probably another couple months - I expect more disk format
changes, and the userspace interfaces might change again and I'd like to
have multiple cache devices done.

After that there's also a roadmap sketched out for thin provisioning,
and building on top of that some ideas for bcachefs. Basically, the idea
is to stick the inode number in bcache's key and use bcache's
allocator/index/garbage collection for the bottom of a very high
performance filesystem... it's a ways off but it's starting to look very

The code's currently based off of 2.6.34 (!). Git repository is up at

-Very latest news : Steven Whitehouse – gfs2, James Bottomley-
scsi updates, and a nice weekend to you and I’ll see you
next week!


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