Kernel

[PATCH 2/5] fsfreeze: emergency thaw will deadlock on s_umount
From: Dave Chinner <dchinner(a)redhat.com> The emergency thaw process uses iterate_super() which holds the sb->s_umount lock in read mode. The current thaw_super() code takes the sb->s_umount lock in write mode, hence leading to an instant deadlock. Pass the emergency state into the thaw_bdev/thaw_super code to ... 10 Jun 2010 04:32

[PATCH 5/5] fsfreeze: move emergency thaw code to fs/super.c
From: Dave Chinner <dchinner(a)redhat.com> It makes no sense having the emergency thaw code in fs/buffer.c when all of it's operations are one superblocks and the code it executes is all in fs/super.c. Move the code there and clean it up. Signed-off-by: Dave Chinner <dchinner(a)redhat.com> --- fs/buffer.c ... 10 Jun 2010 04:32

[RFC, PATCH 0/5] fsfreeze: fix sb vs bdev freeze/thaw b0rkage
The following series is for to address bugs in the emergency thawing code, as well as mismatcheѕ with freezing at the block layer and the superblock that break the freeze/thaw nesting order. The first two patches fix the emergency thaw infinite loop reported by Jeff Merkey and the deadlock on sb->s_umount that th... 10 Jun 2010 04:32

oom killer and long-waiting processes
Hi all, I have one question about oom killer: If many processes dealing with network communications, but due to bad network traffic, the processes have to wait for a very long time. And meanwhile they may consume some memeory separately for computation. The number of such processes may be large. ... 10 Jun 2010 21:16

block: Allow drivers to implement BLKDISCARD and add BLKSECDISCARD
Adrian Hunter wrote: From 328a858c01be1e0d08f4a4b1f43d9fd117a295e5 Mon Sep 17 00:00:00 2001 From: Adrian Hunter <adrian.hunter(a)nokia.com> Date: Thu, 3 Jun 2010 10:46:04 +0300 Subject: [PATCH 1/4] block: Allow drivers to implement BLKDISCARD and add BLKSECDISCARD SD/MMC cards provide an erase operatio... 10 Jun 2010 03:27

perf events finer grained context instrumentation / context exclusion
* Frederic Weisbecker <fweisbec(a)gmail.com> wrote: Here is the new version of per context exclusion, based on hooks on irq_enter/irq_exit. I haven't observed slowdowns but I haven't actually measured the impact. One thing that would be nice to see in this discussion is a comparison of before/after pe... 10 Jun 2010 06:42

[PATCH v2 4/5] of/gpio: add default of_xlate function if device has a node pointer
From: Anton Vorontsov <avorontsov(a)ru.mvista.com> Implement generic OF gpio hooks and thus make device-enabled GPIO chips (i.e. the ones that have gpio_chip->dev specified) automatically attach to the OpenFirmware subsystem. Which means that now we can handle I2C and SPI GPIO chips almost* transparently. * "A... 10 Jun 2010 02:22

[PATCH v2 3/5] of/gpio: stop using device_node data pointer to find gpio_chip
Currently the kernel uses the struct device_node.data pointer to resolve a struct gpio_chip pointer from a device tree node. However, the .data member doesn't provide any type checking and there aren't any rules enforced on what it should be used for. There's no guarantee that the data stored in it actually point... 10 Jun 2010 02:22

[PATCH v2 5/5] of/device: Add OF style matching helper function
Add of_driver_match_device() helper function. This function can be used by bus types to determine if a driver works with a device when using OF style matching. If CONFIG_OF is unselected, then it is a nop. Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> CC: Greg Kroah-Hartman <gregkh(a)suse.de> CC: Micha... 10 Jun 2010 02:22

[PATCH v2 0/5] Generalize OF gpio support code
This series makes all gpio drivers usable from the OF support apis by automatically registering a default OF translator when the of_node pointer is assigned. These patches are heavily based on the work that Anton did earlier, but I didn't add the notifiers infrastructure and the OF data now lives directly inside t... 10 Jun 2010 02:22