LKML Summary Podcast

Audio: COMING SOON

For the weekend of June 13th 2010, I’m Jon Masters with a summary of the past week’s LKML traffic.

In today’s issue: Linux 2.6.35-rc3, ext3, floppy, Kconfig, Memory Corruption, and Suspend Blockers.

Linux 2.6.35-rc3. Linus Torvalds announced the latest RC of 2.6.35 on Friday, June 11th 2010 at 8:01pm Best Coast Time (PDT). Quoting Linus, “So I’ve been hardnosed now for a week – perhaps over so – and hopefully that means that 2.6.35-rc3 will be better than -rc2 was. Not only do we have a number of regressions handled, we don’t have that silly memory corruptor that bit so many people with -rc2 and confused people with its many varied forms of bugs it seemed to take, depending on just what random memory it happened to corrupt. One effect of being strict is that this is likely the smallest -rc3 we’ve had in a long long time.” Linus has been on a bit of a crusade in recent times to reduce the churn post merge-window, which is what he means in describing himself as being “hardnosed” to take patches.

Ext3. Jeff Merkey posted a thread entitled “EXT3 File System Corruption in 2.6.34″, in which – in between his usual extraneous use of 4-letter words and outright offensiveness – he raised an issue that he was seeing on some systems running ext3 and recovering from a power failure. His workload raised an older concern that has been addressed before: file payload corruption following a power failure. The filesystem recovered its journal, but the content of the file was replaced with random other data (not either the original data, or the new data, as might have been expected). Jeff and Eric Sandeen had a discussion about the need to mount with data=ordered vs. the fact that Linus had previously changed the default such that the kernel config option CONFIG_EXT3_DEFAULTS_TO_ORDERED is no longer the default. Ted T’so noted that in lieu of explicit use of syncing within apps, everything is a tradeoff. Users could always mount with “-o sync” to guarantee things hit the disk, “but then the performance will be horrible”.

Floppy. Stephen Hemminger noted a number of issues with the very legacy floppy driver. Linus wondered why anyone really cared about floppies any more, but he agreed that oopsing was always bad. Stephen says he has a few fixes for the immediate issues that he will target for 2.6.36 (most of these were generated under virtualization without using real hardware), and both he and Linus seem quite interested in converting floppy over to threaded irqs, amongst other things. As a super special offer, after reading an online report on a website selling floppy drives (in which one purchaser noted that 3 out of 5 floppy drives had failed within 45 days) Linus even agreed to invest a cool $7.99 to pay for a real floppy disk drive for anyone twisted enough to really want to fix that code, while he himself will not “touch it…with a 10-foot pole”.

Kconfig. Vegard Nossum mailed to let everyone know that he has been accepted into this year’s Google Summer of Code (GSoC) program and will spend the summer working on integrating a “proper boolean constraint satisfiability solver into the configuration editors (menuconfig, etc.) in order to allow partial/incomplete configuration specifications. In short, this means that the user can choose to not specify a particular value for some config options, but let the system deduce their values”. There was some talk of the libzypp library used by Novell’s zypper boolean SAT enabled package manager, though James Bottomley noted that the difference here is that while sometimes package combinations result in an unsatisfiable install, kernel configuration should always be resolvable int a set of valid config options – a checker can be used to flag up broken Kconfig combinations and fix them. This conversation actually began a few weeks back, but had not previously been covered here.

Memory Corruption. It has been well known for some time that certain firmware (PC BIOS software) can be particularly prone to cause low memory (less than 1MB) corruption during suspend or other state transitions, including a mere call into a BIOS-provided System Management Mode (SMM) function. Yuhong Bao noted that the problem was also known to Microsoft, and he pointed to a Microsoft WHDC article covering the problem (and the fact that Windows 7 does not typically make use of low memory for this reason) in a posting entitled “Windows side agrees that lowmem corruption is a problem too”. Ingo Molnar noted that in one corruption case he saw, there was an on screen graphical bitmap that had been spewed all over the low memory. Peter Anvin suggested to just not make use of the first few pages (64K) of “low memory” region at all in order to avoid the increasing number of systems that corrupt it taking down the kernel and causing a system crash. He said that the rest of the lowest 1MB could be kept for ZONE_DMA use only “or something”.

Suspend Blockers. Ingo Molnar, replying to a separate message from Ted T’so, begun a lengthy thread entitled “suspend blockers & Android integration”. Google’s Android platform implements suspend blockers as a means to do what is implied in the naming: provide a means for applications to prevent the system from entering a suspend state. In the case of Android, this is apparently because it will attempt to suspend even with running applications in many cases where it has not been explicitly told not to, to save power. Google’s feature is interesting, but there have been some obstacles to it going into the upstream kernel, due it’s semi-invasive nature (and the objection of some to adding such features to the kernel). Ingo objected to Ted’s comment that “hundreds of engineering hours have been made trying to accomodate the demands of LKML — and LKML has said no to suspend blockers/wakelocks”, noting the many possible features that might have been added to the kernel if engineering time was the sole driving factor, rather than a pursuit of a more perfect option. Ingo believes “Linux is an engineering effort that has literally cost about ten thousand man years. That’s about a 85 million man hours. It takes effort to keep that kind of work valuable!”. Linux Weekly News had a lengthy article on this topic, so I’m going to suggest you subscribe and read that for more detail.

In today’s miscellaneous items:

*). Linus Walleij posted a patch implementing MTDparts style partition table specification via kernel command line parameter. The rationale here is that not all embedded systems use standard partition tables, as was already the case with MTD partitions. This extends the MTD concept to cover regular block devices on some newer embedded devices.

*). Yanmin Zhang reported a hang in btrfs related to calling sync() at the end of a test cycle. The kernel would ultimately output a hangcheck warning.

*). Some online controller reset patches for megaraid_sas from Bo Yang.

*). Jari Ruusu reported a module reference counting issue affecting block device mount and unmount that was caused by a bug introduced in a patch from Tejun Heo. Al Viro rediscovered the problem (bd_start_claiming grabs an extra reference that is never released), which Tejun had already fixed and was queued up for inclusion in a later kernel tree.

*). Patrick J. LoPresti posted a patch for a NULL pointer dereference bug he thought he had found in the device mapper multi-path code, and wondered aloud whether the Coverity folks were still running their nightly checks (he thought this was something that should have been flagged up by Coverity automatically in the course of such checks). Last time I heard, Coverity had had some issues with automated nightly runs but scan.coverity.com seems to still contain various data pertaining to linux-2.6.

*). Alan Olsen (whose name I had to extract from whois records because his email client is not configured to include it) noted a modpost segfault that Krzysztof Halasa tracked down to a faulty offset calculation in reading module license data. It was wondered why this had been ok with previous GCC releases, but in any case was urgently suggested for 2.6.35.

In today’s announcements:

*). Karel Zak announced the latest RC version of the util-linux-ng package is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/v2.18/ The release candidate removes the rdev, ramsize, vidmode, and rootflags legacy utilities, adds a new libmount library for utlities such as mount (though the library API is not yet officially stable), and adds other commands cuh as findmnt, fsfreeze, swaplable, and so forth.

*). Robert P J Day announced that he has created an “online beginner’s kernel programming course” for $39, the details of which are available at http://www.crashcourse.ca Robert notes on that site that he will require a course text in the form of Robert Love’s upcoming third edition of “Linux Kernel Development”. That seems reasonable – this author already has a copy on pre-order, and it will be officially released on July 5th.

The latest kernel release is 2.6.35-rc3.

That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.

Audio: http://traffic.libsyn.com/jcm/linux_kernel_podcast_20100606.mp3

For the weekend of June 6th 2010, I’m Jon Masters with a summary of the past week’s LKML traffic.

In today’s issue: Linux 2.6.35-rc2, Hibernation, KVM clock, Phoronix benchmarks, Threaded Interrupts, and UML.

Linux 2.6.35-rc2. Linus Torvalds announced the release of 2.6.35-rc2 on Saturday, June 6th 2010 at 9:15pm Best Coast Time (PDT). Quoting Linus, “So -rc2 is out there, and hopefully fixes way more problems than it introduces”. Linus expresses some concern at the size of the RC2, which although not as big as the same time last cycle (that was unusally big in general however), was nonetheless larger than he would have liked and less in line with his intention to have a “calmer release cycle this time”. He says he’s going to enforce making RC3 more sane because “the upcoming week is the last week of school for my kids. And when the kids get out of school, I’m going to be offline for a while. And as a result, I _really_ don’t want to pull anything even half-way scary in the next week for -rc3″. He doesn’t specificially mention the Phoronix regression covered later in this episode.

Hibernation. Nigel Cunningham (TuxOnIce) posted some ponderings on idealized algorithms for writing memory images to disk during hibernation in a thread entitled “Proposal for a new alhorithm for reading & writing a hibernation image”, in which he postulated (amongst other things) essentially setting up a new set of page tables while existing pages are being written out to disk such that future writes to memory would result in a page fault that could be used to setup a number of new tables of pages that should later be written out as having changed during the disk write operation. Current algorithms do play games with page faults, but don’t use secondary tables.

KVM clock. Orion Poplawski followed up to a posting from last week in which he noted that guest virtual machines would occasionlly experience wild jumps in time of 6-12 hours. Gleb Netapov, Alexander Graf, John Stultz, Zachary Amsden, and others asked some questions – for example whether ntp was in use or not – and Zachary noted that a theoretical problem existed with the way that some CPUs have seemingly reliable TSC increment until they enter certain power states, at which point the clocking can break. He has some patches in the works to handle this server-side for kvm-clock and he noted that newer kernels should also detect an unreliable host clock quickly on boot. I should add that I have previously experienced similar issues with kvm-clock and raised them directly with the KVM folks quite a few months ago now.

Phoronix benchmarks. Phoronix are known in certain kernel circles for posting “benchmarks” of various new features, especially those targeting the desktop, and so it was not surprising that Alex Buell would wonder aloud why Phoronix were seeing “20 times” performance loss in 2.6.35 release candidate kernels. What was sad, as Robert Hancock noted, was that they wrote an article without choosing to draw the developer’s attention to the problem (although they did note rather specifically when the problem – believed to be causing udev to get into a 100% CPU utilitization loop – was introduced at the end of May). Mike Galbraith and Ingo Molnar replied and infered that such stories were increasingly par for the course as Linux becomes more mainstream. Mike in particular said that, “If eggshells land in our omelet, they can make a buck telling people about it. Who cares? If tasty bacon bits land, they’ll make a buck on that event. Either way, we get some test coverage.” Others (including Ted T’so) were less concerned about “news” stories, and were instead more concerned that there had been a performance problem that had made it to the release candidate stage without being dealt with much sooner.

Thread interrupts. The way of the future for Linux interrupts has been the work that Thomas Gleixner has been organizing to switch over to threaded handlers (specifically, a small quiescent handler intended to quickly placate a device, and a later thread to do the “interrupt” work in thread context). Dmitry Torokhov was very interested in migrating the various input drivers over, but some of those need to do some very long lived polling of devices post interrupt. Dmitry wondered if it was ok to have a threaded handler do that work and just run for a very long time, to which Thomas said, “Sure, why not?” and noted that the only real thing to watch out for was appropriately lowering the priority of the interrupt thread such that other work will take scheduler priority in the interim. Of course the thread should probably not blindly adjust its priority without restoring it to whatever value it started it, just in case the user has specifically configured the intented priority (in the case of RT users).

UML. User Mode Linux (not the silly “modelling” language) has had a few on-and-off issues over the past year. Typically it will break for a few days and be fixed up, but there is some sense that its one-time popularity is truly on the wane. That’s sad, because UML can be useful in an educational context. Most recently, on x86, the UML breakage was caused by a callee register saving optimization trick in the arch-specific “hweight” (hamming weight) function. Borislav Petkov had posted a “bandage” (as Peter Anvin would later describe it), before Jeff Dike, and also others weighed in with various opinions. Peter’s main concern was that it was not at all obvious why UML broke.

In today’s miscellaneous items:

*). Andi Kleen posted a dm-crypt patch intended to facilitate it scaling to multiple CPUs (by means of using per-cpu workqueues), rather than the existing case of all work being bound on a single workqueue. In a separate thread, Neil Brown provided some useful insight into device mapper behavior for layered mappings, explaining why touching an underlying mapping is not a good idea when another is layered on top of it, including side effects.

*). Xudong Hao reported a possibly bridging related regression in 2.6.34 that caused the host kernel to panic when starting KVM guests. Avi Kivity kindly forwarded the mail to the netdev and briding mailing lists for followup.

*). Peter Ovtchenkov inquired as to common bit similaries in seemingly randomly generated UUID pseudofile entries within the kernel. It turns out that version 4 UUIDs specify that the “7th high half-byte” contain 4. Both Lukasz Gromanowski and Ian Campbell followed up to explain this..

*). Michal Marek posted a pull request for some kbuild changes in 2.6.35 (to include the new nconfig interface), to which Linus responded, giving some advice about the best way to do a pull request, and calling out Dave Miller’s networking pull requests as a good example of how to do it. Linus had similarly posted some good recommendations for diffstat generation on May 27th in response to some btrfs update requests.

*). Daisuke Nishimura posted some patches correcting a bad interaction between Andrea Arcangeli’s transparent hugepage patches and memory cgroups (the tail pages during a split did not have correct cgroup LRU entries).

*). Jeff Garzik posted some libata updates. Amongst them was a default disabling of Asynchronous Notification (AN), since, “Proper use is vague, and behavior of firmwares in the field do not match each other.”

*). Rusty Russell suggested to me that support for waiting module removal in modprobe be officially removed, to which I don’t have huge objections. At this point, very few people actually remove modules from production boxes. Rusty and Linus had some other conversation surrouding the in-kernel module loader and locking use therein in a thread overwise devoted to a problem with bne2 network driver initialization that went long (the thread).

*). Luis R. Rodriguez and Stephen Hemminger continued discussing an Ethernet drivers wiki page that could rival the content on compat-wireless today. Stephen wondered why Luis didn’t want this documentation in-tree, and Luis responded that he thought this stuff was better done on a wiki.

*). Dmitry Torokhov noted that “make install” over sshfs is now painfully slow since various git poking is done at the install stage. He wondered if the work implemented by Greg Thelen could be done at build time instead of at install time because it is slowing his build cycles “down to a crawl”.

In today’s announcements:

*). Jeff Merkey posted an announcement (free from any 4-letter-words this time) saying that he had written something called “Cworthy” that was intended to look like an old Netware interface. It’s on Googlecode.com. Jeff also had a few remarks on 2.6.34 that he decided to share under “general comments”.

*). Vladislav Bolkhovitin posted to let everyone know that the ISCSI-SCST project has now implemented a “full set of SCSI Persistent Reservations”. Further information is available at http://scst.sourceforge.net/.

The latest kernel release is 2.6.35-rc2.

Andrew Morton posted an mm-of-the-moment (mmotm) for 2010-06-03-16-36.

Greg Kroah-Hartman announced the release of “long term” stable series kernel 2.6.32.15, which reverted two patches that had unintentionally been included within the previous 2.6.32.14 release. He noted that those not experiencing problems had no real need to upgrade to the latest version at this time.

That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.

Audio: http://traffic.libsyn.com/jcm/linux_kernel_podcast_20100530.mp3

The podcast has returned from a brief break of a few weeks while I was busily working on a certain Enterprise Linux and using my spare time to not be in front of a computer (sailing). There is a backlog of shows in various stages though I’m not yet sure when I’ll get around to posting them online. Thanks for bearing with me and let’s hope we can get back into a routine once more. As always, if you are interested in helping out, drop me a line by email.

For the US Memorial Day Holiday weekend of May 31st 2010, I’m Jon Masters with a summary of the past week’s LKML traffic.

In today’s issue: Linux 2.6.35-rc1, errors, TSC, Unified Ringbuffer, virtio, and YAFFS.

Linux 2.6.35-rc1. Linus Torvalds announced the release of kernel 2.6.35-rc1 on Sunday, May 30th 2010 at 1:21pm Best Coast Time (PDT). Quoting Linus, “…and thus endeth the merge window”. After a two week merge window, Linus says that the “bulk should be there. And please, let’s try to make the merge window mean something this time – don’t send me any new pull request unless they are for real regressions or for major bugs, ok?”. The 2.6.35 release will not feature any new filesystems for a change, but does have all of the ususal driver updates, and of thr 8500 commits, there were about 1000 individual developers involved in the 2.6.35 tree this time around. Linus described the statistics – specifically calling them out in his mail – as demonstrating what is “a healthy development environment”.

Errors. Modern hardware is generally highly reliable, but scalability and the growth of datacenters play havoc with statistics. Given a large enough amount of memory, disks, or other devices, something will eventually go wrong. When it does, it is useful to handle as much as possible with an air of grace. Memory errors are of particular concern, especially with the growth in the amount of RAM in (increasingly) large servers. ECC (Error Correcting Memory) can help, and includes the useful side effect of reporting on correctable errors. Existing userspace utilities, such as Andi Kleen’s mcelog (and other related work in the kernel itself into recoverable memory errors) offer an ability to collect reports of such errors, as well as Machine Check Exceptions (essentially hardware errors, usually related to failing memory, caches, etc.) of various other kinds. At this year’s Linux Foundation Collab Summit (April 15th 2010), there was a mini-summit aimed at figuring out a path for the future of various separate error reporting subsystems, such as MCE (Intel), and EDAC (AMD). Mauro Carvalho Chehab posted a summary of the minutes in the form of an email thread entitled “Hardware Error Kernel Mini-Summit”, in which it is proposed that a new kernel error subsystem be created, abstracting all of the existing mechanisms, and wired up using performance events (perf). The latter piece comes largely at the insistance of Ingo Molnar and Thomas Gleixner, and is not without its controvasy amongst those who feel perf is growing to become some catch-all solution to every problem. Still, it seems likely that there will be some generic replacement to meclog in the future.

TSC. Venkatesh Pallipadi (Google) posted a patch, originally from Dan Magenheimer (Oracle) in which various information about the perceived (or, generally, otherwise) reliability of the TSC known by the kernel was exported via the sysfs. This would allow userspace applications using rdtsc to know whether the counter is generally regarded as a reliable source of time or not. Thomas Gleixner and Ingo Molnar both absolutely hated this, on the grounds that the TSC is known to be generally not a great clocksource (although it is becoming more reliable in many systems) and that just because the reading of it is generally unprivileged and thus widespread does not mean that the kernel should be complicit in encouraging others not to use the standard timestamp reading abstractions. Especially with modern kernels, where there are vsyscalls and other facing mapped page hacks, the overhead of obtaining timestamp information from the kernel is generally fairly reasonable. There was even some suggestion of limiting ring3 access to the TSC by means of a SPR (Special Purpose Register) setting. Dan Magenhiemer noted that the uses of userspace reading of the TSC were more widespread than Thomas and Ingo may have considered, and he called out the dynamic linker used in RHEL5 as one example of a semi-frequent reader of TSC information. Brian Bloniarz, John Stultz, and Peter Anvin took the conversation in a slightly different direction after Brian noted that sometimes userspace needs to know how reliable the current clocksource is considered to be for use in calibration (for example, when using NTP and desiring to know oscillator accuracy). It seemed to be decided that it would therefore be worthwhile to have a general means to determine the accuracy of the current clocksource, not just the Intel-world-view centric TSC. That latter part may well happen.

Unified Ringbuffer. Hardware error detection wasn’t the only topic of general unification efforts this week. Steven Rostedt posted an RFC thread entitled “Unified Ring Buffer” in which he discussed implementing a globally generic kernel ringbuffer that could be used in any subsystem (recall that Steven also implemented a fancy ringbuffer design in ftrace). He posted links to LKML discussion on the effort so far, and an LWN summary article, noting that both the ftrace ringbuffer and the oprofile ringbuffer have so far been unified, but also noting that the introduction of perf events (which require both a lockless, NMI safe, and mmap()able implementation) came with yet another new ringbuffer from Peter Zijlstra. Steven’s original ringbuffer became lockless last year, but currently does not support mmap. So there are two implementations, “neither of which can perform all of the features needed. This is putting a bit of stress on the users of these tools, not to mention the stress on the developers as well”. Steven would like to find a solution to this problem, and so started the thread. Mathieu Desnoyers added that he was happy to help, and had already started working on his own tree (originally intended to help his LTTng tracing tools), while Andi Kleen wondered aloud why Steven would “want a single ring buffer for everyone?”. Steven said the solution might not be to have one implementation, but merely one single interface (with varying backends used, including, as Andi had noted, kfifo based implementations). This lead Ingo Molnar to suggest that grand design planning discussion of ringbuffers was less important than discussing the future direction for tracing and instrumentation (the main users of these ringbuffers, and the real motivation behind them), and to note that performance was currently quite sucky both in ftrace and perf. The conversation seemed to dry up without any specific conclusions. Separately, Peter Zijlstra posted perf ringbuffer optimization patches in a thread entitled “Optimize perf ring-buffer”. Still separately, Chase Douglas posted some “Tracing configuration review” questions for the forthcoming Ubuntu kernel configuration, seeking review comments.

Virtio. Michael S. Tsirkin posted an RFC patch entitled “virtio: put last seen used index into ring itself”, which as it implies modifies the ring buffer used for host/guest communication of vitio (via a feature flag, using available room in the existing structure) such that a guest will update the ring buffer with a host-visible state of where it is in consuming the buffer. The host doesn’t technically require this information, but it can save on unwanted interrupts if the host knows that the guest is not done processing previous ringbuffer entries, and provides useful statistical information. There then followed a lengthy (and somewhat interesting) debate between Michael, Dor Laor, and Rusty Russell concerning the latter’s assertion that the state of the ring buffer could be stored in the same cacheline as the last item in the buffer, rather than in its own cacheline. Rusty contended that this would be more efficient (since occasionally the index and data would be read at the same time), but when he wrote a useful test program was only able to prove that Avi Kivity was right in suggesting separation. Various other dialogue related to the complexity of virtio was discussed.

YAFFS. Charles Manning, ever diligent YAFFS (Yet Another Flash Filesystem – an excellent alternative that this author has had the privilege of poking at with his embedded hat on in the past) developer posted some questions on SLUB behavior. Charles uses a SLUB-like allocator in YAFFS to manage objects, but his objects are separated according to the mount to which they refer. This makes it very easy for him to just throw away a large number of objects on unmount without de-allocating them (”trust me, I know what I’m doing”). He is looking at replacing his custom allocator with SLUB in order to facilitate eventual mainlining of YAFFS, but wants to know whether SLUB could grow some additional “don’t combine this SLUB with others” and ‘”trust me, I know what I’m doing”: Allow the cache to be dumped with objects still allocated” flags. So far, nobody has answered his questions.

In today’s miscellaneous items:

*). Mike Snitzer, Jens Axboe, Vivek Goyal, and Kiyoshi Ueda discussed (in a thread entitled “only initialize full request_queue for request-based device) various approaches to minimalist initialization of Device Mapper devices, specifically given the new split handling of bio vs. request based devices. Only the latter type require “full” queue setup.

*). Ingo Molnar requested that Linus pull the “lockup-detector-for-linus” tree, which contains a unified kernel lockup detector in kernel/watchdog.c that replaces the existing NMI, hung tasks, softlockup, and so forth all in one place. Big thanks go to Don Zickus for his work on this.

*). Discussion continued surrounding some documentation that Henrik Rydberg posted on the Multitouch event slots protocol for multitouch devices. It seems that these input devices become more complex by the day.

*). Don Zickus posted a patch entitled “Makefile.build: make KBUILD_SYMTYPES work again”, in which he provided some fixes to the code that provides a means to determine why kernel symbol versions have changed (i.e. which specific change to which kernel structure or function was the cause). This is of particular use to “Enterprise” distributions doing module versioning.

*). Michel Lespinasse (Google) posted a patch entitled “Stronger CONFIG_DEBUG_SPINLOCK_SLEEP without CONFIG_PREEMPT” in which he proposed tracking the preempt count even when not using CONFIG_PREEMPT, but when nonetheless building with CONFIG_DEBUG_SPINLOCK_SLEEP. Rather than the use of preempt_{dis,en}able actually resulting in preemption, it would merely serve as a means to warn when attempting to sleep incorrectly from within a critical section, but without explicitly enforcing it.

*). Discussion continued surrounding a previous patch from Kay Sievers adding new “devname” module aliases to facilitate module on-demand autoloading. The idea here is that modules can now provide the name of the device entry or entries they will create and so tools like udev can demand load modules as the nodes they support are accessed.

*). Thomas Gleixner finally posted the patch series he had threatend to post previously, entitled “Run interrupt handlers always with interrupts disabled”, that does largely what it says on the tin. It removes the IRQF_DISABLED functionality at interrupt registration and runs all interrupt handles with IRQs off. This should facilitate greater migration over to modern threaded interrupt handlers as needed.

*). Neil Brown posted a patch entitled “VFS: fix recent breakage of FS_REVAL_DOT” in which he provided a fix for a change to NFS client mount behaviors, under which the client would no longer check if a directory within which “ls -l” were being run had changed at the time of the command, without waiting for the cached timestamp attributes to timeout. Al Viro took the patch, but did not like the implementation, so some further discussion ensued.

*). Arve Hjønnevåg posted the latest version of the “suspend block API”, which provides the “same functionality as the android wakelock api”. This is intended to control when a system will be blocked from suspending due to activity, and comes with the benefit of lengthy LKML discussion.

*). Glauber Costa posted version 3 of a patch implementing various MSR (Machine Status Register) KVM specific documentation.

In today’s announcements:

* Smatch 1.55. Dan Carpenter announced release 1.55 of the “smatch” static C source checker tool is now available. The latest version includes an enhanced array overflow check, new checks for precedence bugs caused by macro expansion, rewritten checks for null pointer dereferences, and some kernel specific checks for kunmap, release_resource, etc. http://smatch.sf.net/ or git://repo.or.cz/smatch.git

* Jeff Merkey announced version 2.6.34 of ndiswrapper. Quoting Jeff, “Always here to support the hated projects of Evil Emperor Linus. Needed this f**king think to work on my laptop so fixed the busted sh*t.” His 4-letter-word strewn announcement was greeted by a reply from Simon Horman noting that he would be happy to send Jeff a dictionary if he was looking to “learn some words that are more than four letters long”.

The latest kernel release is 2.6.35-rc1.

Greg Kroah-Hartman posted a series of 2.6.32.14 stable kernel review patches. He notes that he only included patches that were released in kernels up to the 2.6.34 release, since the line had to be drawn somewhere. This is a “long term” stable kernel tree. Many vendors are basing on 2.6.32 now. Greg also posted “take 2″ of some 2.6.27.47 stable series patches, as well as stable review patches for 2.6.33.5.

That’s a summary of today’s Linux Kernel Mailing List traffic, for further information visit www.kernel.org. I’m Jon Masters.