commit 2606524141e4ff9b6a5d0bcbd9d601dfc5a8285c Author: Greg Kroah-Hartman Date: Sat Feb 22 10:33:35 2014 -0800 Linux 3.4.82 commit df1cc7da2a599bde8f28f94601b7ec4c85ec441b Author: Paul Gortmaker Date: Mon Feb 10 13:39:53 2014 -0500 genirq: Add missing irq_to_desc export for CONFIG_SPARSE_IRQ=n commit 2c45aada341121438affc4cb8d5b4cfaa2813d3d upstream. In allmodconfig builds for sparc and any other arch which does not set CONFIG_SPARSE_IRQ, the following will be seen at modpost: CC [M] lib/cpu-notifier-error-inject.o CC [M] lib/pm-notifier-error-inject.o ERROR: "irq_to_desc" [drivers/gpio/gpio-mcp23s08.ko] undefined! make[2]: *** [__modpost] Error 1 This happens because commit 3911ff30f5 ("genirq: export handle_edge_irq() and irq_to_desc()") added one export for it, but there were actually two instances of it, in an if/else clause for CONFIG_SPARSE_IRQ. Add the second one. Signed-off-by: Paul Gortmaker Cc: Jiri Kosina Link: http://lkml.kernel.org/r/1392057610-11514-1-git-send-email-paul.gortmaker@windriver.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit 17ff13b428cc2900bc04570f3a74d746856f35e6 Author: Steven Rostedt (Red Hat) Date: Tue Feb 11 13:38:54 2014 -0500 ring-buffer: Fix first commit on sub-buffer having non-zero delta commit d651aa1d68a2f0a7ee65697b04c6a92f8c0a12f2 upstream. Each sub-buffer (buffer page) has a full 64 bit timestamp. The events on that page use a 27 bit delta against that timestamp in order to save on bits written to the ring buffer. If the time between events is larger than what the 27 bits can hold, a "time extend" event is added to hold the entire 64 bit timestamp again and the events after that hold a delta from that timestamp. As a "time extend" is always paired with an event, it is logical to just allocate the event with the time extend, to make things a bit more efficient. Unfortunately, when the pairing code was written, it removed the "delta = 0" from the first commit on a page, causing the events on the page to be slightly skewed. Fixes: 69d1b839f7ee "ring-buffer: Bind time extend and data events together" Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit 7db019a232f3577a92a2a81d34e4add1c4b80483 Author: Krzysztof Kozlowski Date: Thu Jan 30 14:32:45 2014 +0100 power: max17040: Fix NULL pointer dereference when there is no platform_data commit ac323d8d807060f7c95a685a9fe861e7b6300993 upstream. Fix NULL pointer dereference of "chip->pdata" if platform_data was not supplied to the driver. The driver during probe stored the pointer to the platform_data: chip->pdata = client->dev.platform_data; Later it was dereferenced in max17040_get_online() and max17040_get_status(). If platform_data was not supplied, the NULL pointer exception would happen: [ 6.626094] Unable to handle kernel of a at virtual address 00000000 [ 6.628557] pgd = c0004000 [ 6.632868] [00000000] *pgd=66262564 [ 6.634636] Unable to handle kernel paging request at virtual address e6262000 [ 6.642014] pgd = de468000 [ 6.644700] [e6262000] *pgd=00000000 [ 6.648265] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 6.653552] Modules linked in: [ 6.656598] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 3.10.14-02717-gc58b4b4 #505 [ 6.664334] Workqueue: events max17040_work [ 6.668488] task: dfa11b80 ti: df9f6000 task.ti: df9f6000 [ 6.673873] PC is at show_pte+0x80/0xb8 [ 6.677687] LR is at show_pte+0x3c/0xb8 [ 6.681503] pc : [] lr : [] psr: 600f0113 [ 6.681503] sp : df9f7d58 ip : 600f0113 fp : 00000009 [ 6.692965] r10: 00000000 r9 : 00000000 r8 : dfa11b80 [ 6.698171] r7 : df9f7ea0 r6 : e6262000 r5 : 00000000 r4 : 00000000 [ 6.704680] r3 : 00000000 r2 : e6262000 r1 : 600f0193 r0 : c05b3750 [ 6.711194] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 6.718485] Control: 10c53c7d Table: 5e46806a DAC: 00000015 [ 6.724218] Process kworker/0:1 (pid: 31, stack limit = 0xdf9f6238) [ 6.730465] Stack: (0xdf9f7d58 to 0xdf9f8000) [ 6.914325] [] (show_pte+0x80/0xb8) from [] (__do_kernel_fault.part.9+0x44/0x74) [ 6.923425] [] (__do_kernel_fault.part.9+0x44/0x74) from [] (do_page_fault+0x2c4/0x360) [ 6.933144] [] (do_page_fault+0x2c4/0x360) from [] (do_DataAbort+0x34/0x9c) [ 6.941825] [] (do_DataAbort+0x34/0x9c) from [] (__dabt_svc+0x38/0x60) [ 6.950058] Exception stack(0xdf9f7ea0 to 0xdf9f7ee8) [ 6.955099] 7ea0: df0c1790 00000000 00000002 00000000 df0c1794 df0c1790 df0c1790 00000042 [ 6.963271] 7ec0: df0c1794 00000001 00000000 00000009 00000000 df9f7ee8 c0306268 c0306270 [ 6.971419] 7ee0: a00f0113 ffffffff [ 6.974902] [] (__dabt_svc+0x38/0x60) from [] (max17040_work+0x8c/0x144) [ 6.983317] [] (max17040_work+0x8c/0x144) from [] (process_one_work+0x138/0x440) [ 6.992429] [] (process_one_work+0x138/0x440) from [] (worker_thread+0x134/0x3b8) [ 7.001628] [] (worker_thread+0x134/0x3b8) from [] (kthread+0xa4/0xb0) [ 7.009875] [] (kthread+0xa4/0xb0) from [] (ret_from_fork+0x14/0x2c) [ 7.017943] Code: e1a03005 e2422480 e0826104 e59f002c (e7922104) [ 7.024017] ---[ end trace 73bc7006b9cc5c79 ]--- Signed-off-by: Krzysztof Kozlowski Fixes: c6f4a42de60b981dd210de01cd3e575835e3158e Signed-off-by: Greg Kroah-Hartman commit d6e20e8145341ed1b5d605a8d9ab8463b0ca6ed8 Author: Mikulas Patocka Date: Fri Jan 24 16:41:36 2014 -0500 time: Fix overflow when HZ is smaller than 60 commit 80d767d770fd9c697e434fd080c2db7b5c60c6dd upstream. When compiling for the IA-64 ski emulator, HZ is set to 32 because the emulation is slow and we don't want to waste too many cycles processing timers. Alpha also has an option to set HZ to 32. This causes integer underflow in kernel/time/jiffies.c: kernel/time/jiffies.c:66:2: warning: large integer implicitly truncated to unsigned type [-Woverflow] .mult = NSEC_PER_JIFFY << JIFFIES_SHIFT, /* details above */ ^ This patch reduces the JIFFIES_SHIFT value to avoid the overflow. Signed-off-by: Mikulas Patocka Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1401241639100.23871@file01.intranet.prod.int.rdu2.redhat.com Signed-off-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman commit cd6f6b709eebe70d80a3e542d218228bcf189654 Author: Oleg Nesterov Date: Thu Feb 6 03:42:45 2014 +0530 md/raid5: Fix CPU hotplug callback registration commit 789b5e0315284463617e106baad360cb9e8db3ac upstream. Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); register_cpu_notifier(&foobar_cpu_notifier); put_online_cpus(); This is wrong, since it is prone to ABBA deadlocks involving the cpu_add_remove_lock and the cpu_hotplug.lock (when running concurrently with CPU hotplug operations). Interestingly, the raid5 code can actually prevent double initialization and hence can use the following simplified form of callback registration: register_cpu_notifier(&foobar_cpu_notifier); get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu); put_online_cpus(); A hotplug operation that occurs between registering the notifier and calling get_online_cpus(), won't disrupt anything, because the code takes care to perform the memory allocations only once. So reorganize the code in raid5 this way to fix the deadlock with callback registration. Cc: linux-raid@vger.kernel.org Fixes: 36d1c6476be51101778882897b315bd928c8c7b5 Signed-off-by: Oleg Nesterov [Srivatsa: Fixed the unregister_cpu_notifier() deadlock, added the free_scratch_buffer() helper to condense code further and wrote the changelog.] Signed-off-by: Srivatsa S. Bhat Signed-off-by: NeilBrown Signed-off-by: Greg Kroah-Hartman commit 5a0d43c3374c287711f4191922835e18fc8ae3ec Author: Dan Carpenter Date: Wed Jan 29 16:16:39 2014 +0300 KVM: return an error code in kvm_vm_ioctl_register_coalesced_mmio() commit aac5c4226e7136c331ed384c25d5560204da10a0 upstream. If kvm_io_bus_register_dev() fails then it returns success but it should return an error code. I also did a little cleanup like removing an impossible NULL test. Fixes: 2b3c246a682c ('KVM: Make coalesced mmio use a device per zone') Signed-off-by: Dan Carpenter Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit cc512a4a4a197603c83e9c920832d06ffe81f9b9 Author: Mike Marciniszyn Date: Wed Feb 12 11:54:15 2014 -0500 IB/qib: Add missing serdes init sequence commit 2f75e12c4457a9b3d042c0a0d748fa198dc2ffaf upstream. Research has shown that commit a77fcf895046 ("IB/qib: Use a single txselect module parameter for serdes tuning") missed a key serdes init sequence. This patch add that sequence. Reviewed-by: Dennis Dalessandro Signed-off-by: Mike Marciniszyn Signed-off-by: Roland Dreier Signed-off-by: Greg Kroah-Hartman commit c5bdb3a52d40d1ef3b3f6fb3617d20bb47cee46c Author: Jens Axboe Date: Wed Feb 12 09:34:01 2014 -0700 block: add cond_resched() to potentially long running ioctl discard loop commit c8123f8c9cb517403b51aa41c3c46ff5e10b2c17 upstream. When mkfs issues a full device discard and the device only supports discards of a smallish size, we can loop in blkdev_issue_discard() for a long time. If preempt isn't enabled, this can turn into a softlock situation and the kernel will start complaining. Add an explicit cond_resched() at the end of the loop to avoid that. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e7a95613d77dcbcbefe99b465c6488550caf2c85 Author: Jan Moskyto Matejka Date: Fri Feb 7 19:15:11 2014 +0100 Modpost: fixed USB alias generation for ranges including 0x9 and 0xA commit 03b56329f9bb5a1cb73d7dc659d529a9a9bf3acc upstream. Commit afe2dab4f6 ("USB: add hex/bcd detection to usb modalias generation") changed the routine that generates alias ranges. Before that change, only digits 0-9 were supported; the commit tried to fix the case when the range includes higher values than 0x9. Unfortunately, the commit didn't fix the case when the range includes both 0x9 and 0xA, meaning that the final range must look like [x-9A-y] where x <= 0x9 and y >= 0xA -- instead the [x-9A-x] range was produced. Modprobe doesn't complain as it sees no difference between no-match and bad-pattern results of fnmatch(). Fixing this simple bug to fix the aliases. Also changing the hardcoded beginning of the range to uppercase as all the other letters are also uppercase in the device version numbers. Fortunately, this affects only the dvb-usb-dib0700 module, AFAIK. Signed-off-by: Jan Moskyto Matejka Signed-off-by: Greg Kroah-Hartman commit f0fbd5c4c3cc62df9dca096c5d20943ba608e735 Author: Raymond Wanyoike Date: Sun Feb 9 11:59:46 2014 +0300 usb: option: blacklist ZTE MF667 net interface commit 3635c7e2d59f7861afa6fa5e87e2a58860ff514d upstream. Interface #5 of 19d2:1270 is a net interface which has been submitted to the qmi_wwan driver so consequently remove it from the option driver. Signed-off-by: Raymond Wanyoike Signed-off-by: Greg Kroah-Hartman commit 99c30d65f863a6b6d53f69572c2958ed764994a5 Author: Alan Stern Date: Thu Jan 30 10:43:22 2014 -0500 usb-storage: enable multi-LUN scanning when needed commit 823d12c95c666fa7ab7dad208d735f6bc6afabdc upstream. People sometimes create their own custom-configured kernels and forget to enable CONFIG_SCSI_MULTI_LUN. This causes problems when they plug in a USB storage device (such as a card reader) with more than one LUN. Fortunately, we can tell fairly easily when a storage device claims to have more than one LUN. When that happens, this patch asks the SCSI layer to probe all the LUNs automatically, regardless of the config setting. The patch also updates the Kconfig help text for usb-storage, explaining that CONFIG_SCSI_MULTI_LUN may be necessary. Signed-off-by: Alan Stern Reported-by: Thomas Raschbacher CC: Matthew Dharm CC: James Bottomley Signed-off-by: Greg Kroah-Hartman commit 2aac5d817f6b063a511e6f6270efe861e04b94a2 Author: Alan Stern Date: Thu Jan 30 10:20:29 2014 -0500 usb-storage: restrict bcdDevice range for Super Top in Cypress ATACB commit a9c143c82608bee2a36410caa56d82cd86bdc7fa upstream. The Cypress ATACB unusual-devs entry for the Super Top SATA bridge causes problems. Although it was originally reported only for bcdDevice = 0x160, its range was much larger. This resulted in a bug report for bcdDevice 0x220, so the range was capped at 0x219. Now Milan reports errors with bcdDevice 0x150. Therefore this patch restricts the range to just 0x160. Signed-off-by: Alan Stern Reported-and-tested-by: Milan Svoboda Signed-off-by: Greg Kroah-Hartman commit 65404686fff96a6f84f86628d86686b702faeda1 Author: Alan Stern Date: Tue Jan 21 10:38:45 2014 -0500 usb-storage: add unusual-devs entry for BlackBerry 9000 commit c5637e5119c43452a00e27c274356b072263ecbb upstream. This patch adds an unusual-devs entry for the BlackBerry 9000. This fixes Bugzilla #22442. Signed-off-by: Alan Stern Reported-by: Moritz Moeller-Herrmann Tested-by: Moritz Moeller-Herrmann Signed-off-by: Greg Kroah-Hartman commit 400cbedf7d18881f36408095b5f3387c53aaa2a1 Author: Ulrich Hahn Date: Sun Feb 2 14:42:52 2014 +0100 USB: ftdi_sio: add Tagsys RFID Reader IDs commit 76f24e3f39a1a94bab0d54e98899d64abcd9f69c upstream. Adding two more IDs to the ftdi_sio usb serial driver. It now connects Tagsys RFID readers. There might be more IDs out there for other Tagsys models. Signed-off-by: Ulrich Hahn Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 1c41ee3a84da5eff41aaf5e58b18a3233e4ae637 Author: Bjørn Mork Date: Tue Jan 14 18:56:54 2014 +0100 usb: ftdi_sio: add Mindstorms EV3 console adapter commit 67847baee056892dc35efb9c3fd05ae7f075588c upstream. Signed-off-by: Bjørn Mork Signed-off-by: Greg Kroah-Hartman commit 402d5390c91374880c4028490087b8cffe338be3 Author: Hartmut Knaack Date: Wed Jan 1 23:04:00 2014 +0000 staging:iio:ad799x fix error_free_irq which was freeing an irq that may not have been requested commit 38408d056188be29a6c4e17f3703c796551bb330 upstream. Only free an IRQ in error_free_irq, if it has been requested previously. Signed-off-by: Hartmut Knaack Acked-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit dce0ea4a4732af1333525b76bde5572073d4bbfa Author: Lars Poeschel Date: Tue Jan 7 13:34:37 2014 +0100 tty: n_gsm: Fix for modems with brk in modem status control commit 3ac06b905655b3ef2fd2196bab36e4587e1e4e4f upstream. 3GPP TS 07.10 states in section 5.4.6.3.7: "The length byte contains the value 2 or 3 ... depending on the break signal." The break byte is optional and if it is sent, the length is 3. In fact the driver was not able to work with modems that send this break byte in their modem status control message. If the modem just sends the break byte if it is really set, then weird things might happen. The code for deconding the modem status to the internal linux presentation in gsm_process_modem has already a big comment about this 2 or 3 byte length thing and it is already able to decode the brk, but the code calling the gsm_process_modem function in gsm_control_modem does not encode it and hand it over the right way. This patch fixes this. Without this fix if the modem sends the brk byte in it's modem status control message the driver will hang when opening a muxed channel. Signed-off-by: Lars Poeschel Signed-off-by: Greg Kroah-Hartman commit cc01cae91828041fd1dfa5c1b6bf09221c1659c8 Author: NeilBrown Date: Fri Feb 7 17:10:26 2014 +1100 lockd: send correct lock when granting a delayed lock. commit 2ec197db1a56c9269d75e965f14c344b58b2a4f6 upstream. If an NFS client attempts to get a lock (using NLM) and the lock is not available, the server will remember the request and when the lock becomes available it will send a GRANT request to the client to provide the lock. If the client already held an adjacent lock, the GRANT callback will report the union of the existing and new locks, which can confuse the client. This happens because __posix_lock_file (called by vfs_lock_file) updates the passed-in file_lock structure when adjacent or over-lapping locks are found. To avoid this problem we take a copy of the two fields that can be changed (fl_start and fl_end) before the call and restore them afterwards. An alternate would be to allocate a 'struct file_lock', initialise it, use locks_copy_lock() to take a copy, then locks_release_private() after the vfs_lock_file() call. But that is a lot more work. Reported-by: Olaf Kirch Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman -- v1 had a couple of issues (large on-stack struct and didn't really work properly). This version is much better tested. Signed-off-by: J. Bruce Fields commit e24cfb1b4f4942681c3ce382e83cc090f0ad1550 Author: Paul Bolle Date: Tue Feb 4 23:23:12 2014 +0100 raw: test against runtime value of max_raw_minors commit 5bbb2ae3d6f896f8d2082d1eceb6131c2420b7cf upstream. bind_get() checks the device number it is called with. It uses MAX_RAW_MINORS for the upper bound. But MAX_RAW_MINORS is set at compile time while the actual number of raw devices can be set at runtime. This means the test can either be too strict or too lenient. And if the test ends up being too lenient bind_get() might try to access memory beyond what was allocated for "raw_devices". So check against the runtime value (max_raw_minors) in this function. Signed-off-by: Paul Bolle Acked-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 566d9875cb708d907f8a0b3c2a0dffb96dcb973c Author: Geert Uytterhoeven Date: Tue Jan 28 10:33:03 2014 +0100 spi: Fix crash with double message finalisation on error handling commit 1f802f8249a0da536877842c43c7204064c4de8b upstream. This reverts commit e120cc0dcf2880a4c5c0a6cb27b655600a1cfa1d. It causes a NULL pointer dereference with drivers using the generic spi_transfer_one_message(), which always calls spi_finalize_current_message(), which zeroes master->cur_msg. Drivers implementing transfer_one_message() theirselves must always call spi_finalize_current_message(), even if the transfer failed: * @transfer_one_message: the subsystem calls the driver to transfer a single * message while queuing transfers that arrive in the meantime. When the * driver is finished with this message, it must call * spi_finalize_current_message() so the subsystem can issue the next * transfer Signed-off-by: Geert Uytterhoeven Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 9558f9d82eed2e0015783c553794aeed79dfa0f8 Author: Martin Schwidefsky Date: Mon Feb 3 17:37:15 2014 +0100 s390: fix kernel crash due to linkage stack instructions commit 8d7f6690cedb83456edd41c9bd583783f0703bf0 upstream. The kernel currently crashes with a low-address-protection exception if a user space process executes an instruction that tries to use the linkage stack. Set the base-ASTE origin and the subspace-ASTE origin of the dispatchable-unit-control-table to point to a dummy ASTE. Set up control register 15 to point to an empty linkage stack with no room left. A user space process with a linkage stack instruction will still crash but with a different exception which is correctly translated to a segmentation fault instead of a kernel oops. Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit 021139f22c744a254870dcb23b326037a32a1aa7 Author: Michael Holzheu Date: Thu Jan 30 16:14:02 2014 +0100 s390/dump: Fix dump memory detection commit d7736ff5be31edaa4fe5ab62810c64529a24b149 upstream. Dumps created by kdump or zfcpdump can contain invalid memory holes when dumping z/VM systems that have memory pressure. For example: # zgetdump -i /proc/vmcore. Memory map: 0000000000000000 - 0000000000bfffff (12 MB) 0000000000e00000 - 00000000014fffff (7 MB) 000000000bd00000 - 00000000f3bfffff (3711 MB) The memory detection function find_memory_chunks() issues tprot to find valid memory chunks. In case of CMM it can happen that pages are marked as unstable via set_page_unstable() in arch_free_page(). If z/VM has released that pages, tprot returns -EFAULT and indicates a memory hole. So fix this and switch off CMM in case of kdump or zfcpdump. Signed-off-by: Michael Holzheu Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman commit fb11ab59b2999e2afee7c7fcd3687bf07b2fc988 Author: Johannes Berg Date: Sat Feb 1 00:16:23 2014 +0100 mac80211: fix fragmentation code, particularly for encryption commit 338f977f4eb441e69bb9a46eaa0ac715c931a67f upstream. The "new" fragmentation code (since my rewrite almost 5 years ago) erroneously sets skb->len rather than using skb_trim() to adjust the length of the first fragment after copying out all the others. This leaves the skb tail pointer pointing to after where the data originally ended, and thus causes the encryption MIC to be written at that point, rather than where it belongs: immediately after the data. The impact of this is that if software encryption is done, then a) encryption doesn't work for the first fragment, the connection becomes unusable as the first fragment will never be properly verified at the receiver, the MIC is practically guaranteed to be wrong b) we leak up to 8 bytes of plaintext (!) of the packet out into the air This is only mitigated by the fact that many devices are capable of doing encryption in hardware, in which case this can't happen as the tail pointer is irrelevant in that case. Additionally, fragmentation is not used very frequently and would normally have to be configured manually. Fix this by using skb_trim() properly. Fixes: 2de8e0d999b8 ("mac80211: rewrite fragmentation") Reported-by: Jouni Malinen Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit ce5562e5704bf715fc3084d9f218e5ba3fbf0991 Author: Eric W. Biederman Date: Mon Feb 10 14:25:41 2014 -0800 fs/file.c:fdtable: avoid triggering OOMs from alloc_fdmem commit 96c7a2ff21501691587e1ae969b83cbec8b78e08 upstream. Recently due to a spike in connections per second memcached on 3 separate boxes triggered the OOM killer from accept. At the time the OOM killer was triggered there was 4GB out of 36GB free in zone 1. The problem was that alloc_fdtable was allocating an order 3 page (32KiB) to hold a bitmap, and there was sufficient fragmentation that the largest page available was 8KiB. I find the logic that PAGE_ALLOC_COSTLY_ORDER can't fail pretty dubious but I do agree that order 3 allocations are very likely to succeed. There are always pathologies where order > 0 allocations can fail when there are copious amounts of free memory available. Using the pigeon hole principle it is easy to show that it requires 1 page more than 50% of the pages being free to guarantee an order 1 (8KiB) allocation will succeed, 1 page more than 75% of the pages being free to guarantee an order 2 (16KiB) allocation will succeed and 1 page more than 87.5% of the pages being free to guarantee an order 3 allocate will succeed. A server churning memory with a lot of small requests and replies like memcached is a common case that if anything can will skew the odds against large pages being available. Therefore let's not give external applications a practical way to kill linux server applications, and specify __GFP_NORETRY to the kmalloc in alloc_fdmem. Unless I am misreading the code and by the time the code reaches should_alloc_retry in __alloc_pages_slowpath (where __GFP_NORETRY becomes signification). We have already tried everything reasonable to allocate a page and the only thing left to do is wait. So not waiting and falling back to vmalloc immediately seems like the reasonable thing to do even if there wasn't a chance of triggering the OOM killer. Signed-off-by: "Eric W. Biederman" Cc: Eric Dumazet Acked-by: David Rientjes Cc: Cong Wang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 2af3263a0d1d456ba63d7d167fadd7f08fd8fe1c Author: David Vrabel Date: Tue Feb 4 18:53:56 2014 +0000 xen-blkfront: handle backend CLOSED without CLOSING commit 3661371701e714f0cea4120f6a365340858fb4e4 upstream. Backend drivers shouldn't transistion to CLOSED unless the frontend is CLOSED. If a backend does transition to CLOSED too soon then the frontend may not see the CLOSING state and will not properly shutdown. So, treat an unexpected backend CLOSED state the same as CLOSING. Signed-off-by: David Vrabel Acked-by: Konrad Rzeszutek Wilk Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman