- 22 Jul, 2013 29 commits
-
-
Konrad Rzeszutek Wilk authored
commit 098b1aea upstream. There are two tool-stack that can instruct the Xen PCI frontend and backend to change states: 'xm' (Python code with a daemon), and 'xl' (C library - does not keep state changes). With the 'xm', the path to disconnect a single PCI device (xm pci-detach <guest> <BDF>) is: 4(Connected)->7(Reconfiguring*)-> 8(Reconfigured)-> 4(Connected)->5(Closing*). The * is for states that the tool-stack sets. For 'xl', it is similar: 4(Connected)->7(Reconfiguring*)-> 8(Reconfigured)-> 4(Connected) Both of them also tear down the XenBus structure, so the backend state ends up going in the 3(Initialised) and calls pcifront_xenbus_remove. When a PCI device is plugged back in (xm pci-attach <guest> <BDF>) both of them follow the same pattern: 2(InitWait*), 3(Initialized*), 4(Connected*)->4(Connected). [xen-pcifront ignores the 2,3 state changes and only acts when 4 (Connected) has been reached] Note that this is for a _single_ PCI device. If there were two PCI devices and only one was disconnected 'xm' would show the same state changes. The problem is that git commit 3d925320 ("xen/pcifront: Use Xen-SWIOTLB when initting if required") introduced a mechanism to initialize the SWIOTLB when the Xen PCI front moves to Connected state. It also had some aggressive seatbelt code check that would warn the user if one tried to change to Connected state without hitting first the Closing state: pcifront pci-0: PCI frontend already installed! However, that code can be relaxed and we can continue on working even if the frontend is instructed to be the 'Connected' state with no devices and then gets tickled to be in 'Connected' state again. In other words, this 4(Connected)->5(Closing)->4(Connected) state was expected, while 4(Connected)->.... anything but 5(Closing)->4(Connected) was not. This patch removes that aggressive check and allows Xen pcifront to work with the 'xl' toolstack (for one or more PCI devices) and with 'xm' toolstack (for more than two PCI devices). Acked-by:
Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org [v2: Added in the description about two PCI devices] Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Laszlo Ersek authored
commit 0b0c002c upstream. ... because the "clock_event_device framework" already accounts for idle time through the "event_handler" function pointer in xen_timer_interrupt(). The patch is intended as the completion of [1]. It should fix the double idle times seen in PV guests' /proc/stat [2]. It should be orthogonal to stolen time accounting (the removed code seems to be isolated). The approach may be completely misguided. [1] https://lkml.org/lkml/2011/10/6/10 [2] http://lists.xensource.com/archives/html/xen-devel/2010-08/msg01068.html John took the time to retest this patch on top of v3.10 and reported: "idle time is correctly incremented for pv and hvm for the normal case, nohz=off and nohz=idle." so lets put this patch in. Signed-off-by:
Laszlo Ersek <lersek@redhat.com> Signed-off-by:
John Haxby <john.haxby@oracle.com> Signed-off-by:
-
Zach Bobroff authored
commit d3768d88 upstream. ExitBootServices is absolutely supposed to return a failure if any ExitBootServices event handler changes the memory map. Basically the get_map loop should run again if ExitBootServices returns an error the first time. I would say it would be fair that if ExitBootServices gives an error the second time then Linux would be fine in returning control back to BIOS. The second change is the following line: again: size += sizeof(*mem_map) * 2; Originally you were incrementing it by the size of one memory map entry. The issue here is all related to the low_alloc routine you are using. In this routine you are making allocations to get the memory map itself. Doing this allocation or allocations can affect the memory map by more than one record. [ mfleming - changelog, code style ] Signed-off-by:
Zach Bobroff <zacharyb@ami.com> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Helge Deller authored
commit 92b59929 upstream. If the value which should be moved into a space register is zero, we can optimize the inline assembly to become "mtsp %r0,%srX". Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Helge Deller authored
commit dac76f1b upstream. The LMMIO length reported by PAT and the length given by the LBA MASK register are not consistent. This leads e.g. to a not-working ATI FireGL card with the radeon DRM driver since the memory can't be mapped. Fix this by correctly adjusting the resource sizes. Signed-off-by:
-
John David Anglin authored
commit e8d8fc21 upstream. I still see the occasional random segv on rp3440. Looking at one of these (a code 15), it appeared the problem must be with the cache handling of anonymous pages. Reviewing this, I noticed that the space register %sr1 might be being clobbered when we flush an anonymous page. Register %sr1 is used for TLB purges in a couple of places. These purges are needed on PA8800 and PA8900 processors to ensure cache consistency of flushed cache lines. The solution here is simply to move the %sr1 load into the TLB lock region needed to ensure that one purge executes at a time on SMP systems. This was already the case for one use. After a few days of operation, I haven't had a random segv on my rp3440. Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
-
Christoph Lameter authored
commit 0f8f8094 upstream. Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26. In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes init_lock_keys() dereference beyond kmalloc_caches[26]. This leads to an unbootable system (kernel panic at initializing SLAB) if one of kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] is not NULL. Fix this by making sure that init_lock_keys() does not dereference beyond kmalloc_caches[26] arrays. Signed-off-by:
Christoph Lameter <cl@linux.com> Reported-by:
Tetsuo Handa <penguin-kernel@I-Love.SAKURA.ne.jp> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Pekka Enberg <penberg@kernel.org> Signed-off-by:
-
Helge Deller authored
commit 5b879d78 upstream. When running the LTP testsuite one may hit this kernel BUG() with the write06 testcase: kernel BUG at mm/filemap.c:2023! CPU: 1 PID: 8614 Comm: writev01 Not tainted 3.10.0-rc7-64bit-c3000+ #6 IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401e6e84 00000000401e6e88 IIR: 03ffe01f ISR: 0000000010340000 IOR: 000001fbe0380820 CPU: 1 CR30: 00000000bef80000 CR31: ffffffffffffffff ORIG_R28: 00000000bdc192c0 IAOQ[0]: iov_iter_advance+0x3c/0xc0 IAOQ[1]: iov_iter_advance+0x40/0xc0 RP(r2): generic_file_buffered_write+0x204/0x3f0 Backtrace: [<00000000401e764c>] generic_file_buffered_write+0x204/0x3f0 [<00000000401eab24>] __generic_file_aio_write+0x244/0x448 [<00000000401eadc0>] generic_file_aio_write+0x98/0x150 [<000000004024f460>] do_sync_readv_writev+0xc0/0x130 [<000000004025037c>] compat_do_readv_writev+0x12c/0x340 [<00000000402505f8>] compat_writev+0x68/0xa0 [<0000000040251d88>] compat_SyS_writev+0x98/0xf8 Reason for this crash is a gcc miscompilation in the fault handlers of pa_memcpy() which return the fault address instead of the copied bytes. Since this seems to be a generic problem with gcc-4.7.x (and below), it's better to simplify the fault handlers in pa_memcpy to avoid this problem. Here is a simple reproducer for the problem: int main(int argc, char **argv) { int fd, nbytes; struct iovec wr_iovec[] = { { "TEST STRING ",32}, { (char*)0x40005000,32} }; // random memory. fd = open(DATA_FILE, O_RDWR | O_CREAT, 0666); nbytes = writev(fd, wr_iovec, 2); printf("return value = %d, errno %d (%s)\n", nbytes, errno, strerror(errno)); return 0; } In addition, John David Anglin wrote: There is no gcc PR as pa_memcpy is not legitimate C code. There is an implicit assumption that certain variables will contain correct values when an exception occurs and the code randomly jumps to one of the exception blocks. There is no guarantee of this. If a PR was filed, it would likely be marked as invalid. Signed-off-by:
-
Helge Deller authored
commit a83f58bc upstream. Signed-off-by:
-
Tejun Heo authored
commit 14611e51 upstream. task->cgroups is a RCU pointer pointing to struct css_set. A task switches to a different css_set on cgroup migration but a css_set doesn't change once created and its pointers to cgroup_subsys_states aren't RCU protected. task_subsys_state[_check]() is the macro to acquire css given a task and subsys_id pair. It RCU-dereferences task->cgroups->subsys[] not task->cgroups, so the RCU pointer task->cgroups ends up being dereferenced without read_barrier_depends() after it. It's broken. Fix it by introducing task_css_set[_check]() which does RCU-dereference on task->cgroups. task_subsys_state[_check]() is reimplemented to directly dereference ->subsys[] of the css_set returned from task_css_set[_check](). This removes some of sparse RCU warnings in cgroup. v2: Fixed unbalanced parenthsis and there's no need to use rcu_dereference_raw() when !CONFIG_PROVE_RCU. Both spotted by Li. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Acked-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
-
Li Zefan authored
commit 1c8158ee upstream. commit 5db9a4d9 Author: Tejun Heo <tj@kernel.org> Date: Sat Jul 7 16:08:18 2012 -0700 cgroup: fix cgroup hierarchy umount race This commit fixed a race caused by the dput() in css_dput_fn(), but the dput() in cgroup_event_remove() can also lead to the same BUG(). Signed-off-by:
-
Joachim Eastwood authored
commit e39506b4 upstream. Commit 80af9e6d (pcmcia at91_cf: fix raw gpio number usage) forgot to change the parameter in gpio_get_value after adding gpio validation. Signed-off-by:
Joachim Eastwood <manabian@gmail.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by:
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by:
-
Jason Wang authored
commit 35848f68 upstream. Even if guest were compiled without SMP support, it could not assume that host wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for UP guest. Signed-off-by:
Jason Wang <jasowang@redhat.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
George Cherian authored
commit 5388a3a5 upstream. Do a release_mem_region of the hcd resource. Without this the subsequent insertion of module fails in request_mem_region. Signed-off-by:
George Cherian <george.cherian@ti.com> Acked-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Mathias Nyman authored
commit 025f880c upstream. Fail and free the container context in case dma_pool_alloc() can't allocate the raw context data part of it This patch should be backported to kernels as old as 2.6.31, that contain the commit d115b048 "USB: xhci: Support for 64-byte contexts". Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Cc: John Youn <johnyoun@synopsys.com> Signed-off-by:
-
Roger Quadros authored
commit 4e5c9e6f upstream. For PHY mode, the PHYs must be brought out of reset before the EHCI controller is started. This patch fixes the issue where USB devices are not found on Beagleboard/Beagle-xm if USB has been started previously by the bootloader. (e.g. by "usb start" command in u-boot) Tested on Beagleboard, Beagleboard-xm and Pandaboard. Issue present on 3.10 onwards. Reported-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
UCHINO Satoshi authored
commit d68c277b upstream. Without this memory barrier, the file-storage thread may fail to escape from the following while loop, because it may observe new common->thread_wakeup_needed and old bh->state which are updated by the callback functions. /* Wait for the CBW to arrive */ while (bh->state != BUF_STATE_FULL) { rc = sleep_thread(common); if (rc) return rc; } Signed-off-by:
UCHINO Satoshi <satoshi.uchino@toshiba.co.jp> Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
-
Dan Williams authored
commit a254810a upstream. These devices are all Gobi1K devices (according to the Windows INF files) and should be handled by qcserial instead of option. Their network port is handled by qmi_wwan. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Darren Hart authored
commit 29692d05 upstream. Use DMI_BOARD_NAME to determine if we are running on a MinnowBoard and set the uart clock to 50MHz if so. This removes the need to pass the user_uartclk to the kernel at boot time. Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Cc: Jiri Slaby <jslaby@suse.cz> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Theodore Ts'o authored
commit 42c832de upstream. The function ext4_write_inline_data_end() can return an error. So we need to assign it to a signed integer variable to check for an error return (since copied is an unsigned int). Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: Zheng Liu <wenqing.lz@taobao.com> Signed-off-by:
-
Al Viro authored
commit 64cb9273 upstream. Both ext3 and ext4 htree_dirblock_to_tree() is just filling the in-core rbtree for use by call_filldir(). All updates of ->f_pos are done by the latter; bumping it here (on error) is obviously wrong - we might very well have it nowhere near the block we'd found an error in. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Maarten ter Huurne authored
commit 6ca792ed upstream. Subtracting the number of the first data block places the superblock backups one block too early, corrupting the file system. When the block size is larger than 1K, the first data block is 0, so the subtraction has no effect and no corruption occurs. Signed-off-by:
Maarten ter Huurne <maarten@treewalker.org> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Theodore Ts'o authored
commit 39c04153 upstream. Once we decrement transaction->t_updates, if this is the last handle holding the transaction from closing, and once we release the t_handle_lock spinlock, it's possible for the transaction to commit and be released. In practice with normal kernels, this probably won't happen, since the commit happens in a separate kernel thread and it's unlikely this could all happen within the space of a few CPU cycles. On the other hand, with a real-time kernel, this could potentially happen, so save the tid found in transaction->t_tid before we release t_handle_lock. It would require an insane configuration, such as one where the jbd2 thread was set to a very high real-time priority, perhaps because a high priority real-time thread is trying to read or write to a file system. But some people who use real-time kernels have been known to do insane things, including controlling laser-wielding industrial robots. :-) Signed-off-by:
-
Theodore Ts'o authored
commit fe52d17c upstream. Some of the functions which modify the jbd2 superblock were not updating the checksum before calling jbd2_write_superblock(). Move the call to jbd2_superblock_csum_set() to jbd2_write_superblock(), so that the checksum is calculated consistently. Signed-off-by:
-
Larry Finger authored
commit 10d0b903 upstream. A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the same condition twice. The problem was found using cppcheck-1.49, and the proper fix was verified against the pre-mac80211 version of the code. This patch was originally included as commit 1288aa4e, but was accidentally reverted in a later patch. Reported-by: David Binderman <dcb314@hotmail.com> [original report] Reported-by: Andrea Morello <andrea.merello@gmail.com> [report of accidental reversion] Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Larry Finger authored
commit 73e088ed upstream. The driver loads its firmware from files rtlwifi/rtl8723fw*.bin, but the MODULE_FIRMWARE macros refer to rtlwifi/RTL8723aefw*.bin. Signed-off-by:
Axel Köllhofer <AxelKoellhofer@web.de> Signed-off-by:
-
Larry Finger authored
commit c4d827c5 upstream. This is a new device for this driver. Reported-by:
Tobias Kluge <zielscheibe@gmail.com> Signed-off-by:
-
Pavel Shilovsky authored
commit 689c3db4 upstream. If we request reading or writing on a file that needs to be reopened, it causes the deadlock: we are already holding rw semaphore for reading and then we try to acquire it for writing in cifs_relock_file. Fix this by acquiring the semaphore for reading in cifs_relock_file due to we don't make any changes in locks and don't need a write access. Signed-off-by:
Pavel Shilovsky <pshilovsky@samba.org> Acked-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
Steve French authored
commit 6658b9f7 upstream. Certain servers may not set the NumberOfLinks field in query file/path info responses. In such a case, cifs_inode_needs_reval() assumes that all regular files are hardlinks and triggers revalidation, leading to excessive and unnecessary network traffic. This change hardcodes cf_nlink (and subsequently i_nlink) when not returned by the server, similar to what already occurs in cifs_mkdir(). Signed-off-by:
David Disseldorp <ddiss@suse.de> Signed-off-by:
-
- 13 Jul, 2013 11 commits
-
-
Greg Kroah-Hartman authored
-
Michal Hocko authored
commit fa460c2d upstream. This reverts commit e4715f01. mem_cgroup_put is hierarchy aware so mem_cgroup_put(memcg) already drops an additional reference from all parents so the additional mem_cgrroup_put(parent) potentially causes use-after-free. Signed-off-by:
Michal Hocko <mhocko@suse.cz> Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Hugh Dickins <hughd@google.com> Cc: Tejun Heo <tj@kernel.org> Cc: Glauber Costa <glommer@openvz.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Srivatsa S. Bhat authored
commit f51e1eb6 upstream. Toralf Förster reported that the cpufreq ondemand governor behaves erratically (doesn't scale well) after a suspend/resume cycle. The problem was that the cpufreq subsystem's idea of the cpu frequencies differed from the actual frequencies set in the hardware after a suspend/resume cycle. Toralf bisected the problem to commit a66b2e50 (cpufreq: Preserve sysfs files across suspend/resume). Among other (harmless) things, that commit skipped the call to cpufreq_update_policy() in the resume path. But cpufreq_update_policy() plays an important role during resume, because it is responsible for checking if the BIOS changed the cpu frequencies behind our back and resynchronize the cpufreq subsystem's knowledge of the cpu frequencies, and update them accordingly. So, restore the call to cpufreq_update_policy() in the resume path to fix the cpufreq regression. Reported-and-tested-by:
Toralf Förster <toralf.foerster@gmx.de> Signed-off-by:
Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Ben Hutchings authored
commit 2ee3e26c upstream. Commit 39c60a09 '[SCSI] sd: fix array cache flushing bug causing performance problems' added temp as a pointer to "temporary " and used sizeof(temp) - 1 as its length. But sizeof(temp) is the size of the pointer, not the size of the string constant. Change temp to a static array so that sizeof() does what was intended. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Gleb Natapov authored
commit 03617c18 upstream. Some userspaces do not preserve unusable property. Since usable segment has to be present according to VMX spec we can use present property to amend userspace bug by making unusable segment always nonpresent. vmx_segment_access_rights() already marks nonpresent segment as unusable. Reported-by:
Stefan Pietsch <stefan.pietsch@lsexperts.de> Tested-by:
Gleb Natapov <gleb@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit 24750082 upstream. A freebsd NFSv4.0 client was getting rare IO errors expanding a tarball. A network trace showed the server returning BAD_XDR on the final getattr of a getattr+write+getattr compound. The final getattr started on a page boundary. I believe the Linux client ignores errors on the post-write getattr, and that that's why we haven't seen this before. Reported-by:
Rick Macklem <rmacklem@uoguelph.ca> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Andy Adamson authored
commit 62f288a0 upstream. We need to ensure that we clear NFS4_SLOT_TBL_DRAINING on the back channel when we're done recovering the session. Regression introduced by commit 774d5f14 (NFSv4.1 Fix a pNFS session draining deadlock) Signed-off-by:
Andy Adamson <andros@netapp.com> [Trond: Changed order to start back-channel first. Minor code cleanup] Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Greg Kroah-Hartman authored
Revert "serial: 8250_pci: add support for another kind of NetMos Technology PCI 9835 Multi-I/O Controller" commit 828c6a10 upstream. This reverts commit 8d2f8cd4. As reported by Stefan, this device already works with the parport_serial driver, so the 8250_pci driver should not also try to grab it as well. Reported-by:
Stefan Seyfried <stefan.seyfried@googlemail.com> Cc: Wang YanQing <udknight@gmail.com> Signed-off-by:
-
Peter Hurley authored
commit 64e377dc upstream. Commit 19ffd68f ('pty: Remove redundant itty reset') introduced a regression whereby the other pty's linkage is not cleared on teardown. This triggers a false positive diagnostic in testing. Properly reset the itty linkage. Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Zhang Yi authored
commit 13d60f4b upstream. The futex_keys of process shared futexes are generated from the page offset, the mapping host and the mapping index of the futex user space address. This should result in an unique identifier for each futex. Though this is not true when futexes are located in different subpages of an hugepage. The reason is, that the mapping index for all those futexes evaluates to the index of the base page of the hugetlbfs mapping. So a futex at offset 0 of the hugepage mapping and another one at offset PAGE_SIZE of the same hugepage mapping have identical futex_keys. This happens because the futex code blindly uses page->index. Steps to reproduce the bug: 1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0 and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs mapping. The mutexes must be initialized as PTHREAD_PROCESS_SHARED because PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as their keys solely depend on the user space address. 2. Lock mutex1 and mutex2 3. Create thread1 and in the thread function lock mutex1, which results in thread1 blocking on the locked mutex1. 4. Create thread2 and in the thread function lock mutex2, which results in thread2 blocking on the locked mutex2. 5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2 still blocks on mutex2 because the futex_key points to mutex1. To solve this issue we need to take the normal page index of the page which contains the futex into account, if the futex is in an hugetlbfs mapping. In other words, we calculate the normal page mapping index of the subpage in the hugetlbfs mapping. Mappings which are not based on hugetlbfs are not affected and still use page->index. Thanks to Mel Gorman who provided a patch for adding proper evaluation functions to the hugetlbfs code to avoid exposing hugetlbfs specific details to the futex code. [ tglx: Massaged changelog ] Signed-off-by:
Zhang Yi <zhang.yi20@zte.com.cn> Reviewed-by:
Jiang Biao <jiang.biao2@zte.com.cn> Tested-by:
Ma Chenggong <ma.chenggong@zte.com.cn> Reviewed-by:
'Mel Gorman' <mgorman@suse.de> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Greg Kroah-Hartman authored
commit 7b175c46 upstream. This hopefully will help point developers to the proper way that patches should be submitted for inclusion in the stable kernel releases. Reported-by:
David Howells <dhowells@redhat.com> Acked-by:
-
