- 17 May, 2017 40 commits
-
-
Johan Hovold authored
[ Upstream commit ba340d7b ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: bba5394a ("Input: add support for Hanwang tablets") Signed-off-by:
Johan Hovold <johan@kernel.org> Cc: stable@vger.kernel.org # 2.6.37 Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com>
-
Johan Hovold authored
[ Upstream commit 5cc4a1a9 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: aca951a2 ("[PATCH] input-driver-yealink-P1K-usb-phone") Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 1916d319 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack control-interface endpoints. Fixes: 628329d5 ("Input: add IMS Passenger Control Unit driver") Signed-off-by:
-
Johan Hovold authored
[ Upstream commit ac2ee9ba ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: c04148f9 ("Input: add driver for USB VoIP phones with CM109...") Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 59cf8bed ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory that lie beyond the end of the endpoint array should a malicious device lack the expected endpoints. Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 181302dc ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: 53f3a9e2 ("mmc: USB SD Host Controller (USHC) driver") Cc: stable <stable@vger.kernel.org> # 2.6.37 Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 66822d81 ] Higher sclks seem to be unstable on some boards. bug: https://bugs.freedesktop.org/show_bug.cgi?id=100222Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit e7cc4865 ] While hunting for clues to a use-after-free, Oleg spotted that perf_event_init_context() can loose an error value with the result that fork() can succeed even though we did not fully inherit the perf event context. Spotted-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@kernel.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: oleg@redhat.com Cc: stable@vger.kernel.org Fixes: 889ff015 ("perf/core: Split context's event group list into pinned and non-pinned lists") Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 9b4f603e ] There is a missing newline in show_cpuinfo_cur_freq(), so add it, but while at it clean that function up somewhat too. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Viresh Kumar <viresh.kumar@linaro.org> Cc: All applicable <stable@vger.kernel.org> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 0f424de1 ] OLAND 0x1002:0x6604 0x1028:0x066F 0x00 seems to have problems with higher sclks. Acked-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Eric Biggers authored
[ Upstream commit b9cf625d ] If ext4_convert_inline_data() was called on a directory with inline data, the filesystem was left in an inconsistent state (as considered by e2fsck) because the file size was not increased to cover the new block. This happened because the inode was not marked dirty after i_disksize was updated. Fix this by marking the inode dirty at the end of ext4_finish_convert_inline_dir(). This bug was probably not noticed before because most users mark the inode dirty afterwards for other reasons. But if userspace executed FS_IOC_SET_ENCRYPTION_POLICY with invalid parameters, as exercised by 'kvm-xfstests -c adv generic/396', then the inode was never marked dirty after updating i_disksize. Cc: stable@vger.kernel.org # 3.10+ Fixes: 3c47d541Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit 9bbb25af ] Thomas spotted that fixup_pi_state_owner() can return errors and we fail to unlock the rt_mutex in that case. Reported-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Cc: juri.lelli@arm.com Cc: bigeasy@linutronix.de Cc: xlpang@redhat.com Cc: rostedt@goodmis.org Cc: mathieu.desnoyers@efficios.com Cc: jdesfossez@efficios.com Cc: dvhart@infradead.org Cc: bristot@redhat.com Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/20170304093558.867401760@infradead.orgSigned-off-by:
-
Peter Zijlstra authored
[ Upstream commit c236c8e9 ] While working on the futex code, I stumbled over this potential use-after-free scenario. Dmitry triggered it later with syzkaller. pi_mutex is a pointer into pi_state, which we drop the reference on in unqueue_me_pi(). So any access to that pointer after that is bad. Since other sites already do rt_mutex_unlock() with hb->lock held, see for example futex_lock_pi(), simply move the unlock before unqueue_me_pi(). Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Nicolas Ferre authored
[ Upstream commit 60b89f19 ] On some DDR controllers, compatible with the sama5d3 one, the sequence to enter/exit/re-enter the self-refresh mode adds more constrains than what is currently written in the at91_idle driver. An actual access to the DDR chip is needed between exit and re-enter of this mode which is somehow difficult to implement. This sequence can completely hang the SoC. It is particularly experienced on parts which embed a L2 cache if the code run between IDLE calls fits in it... Moreover, as the intention is to enter and exit pretty rapidly from IDLE, the power-down mode is a good candidate. So now we use power-down instead of self-refresh. As we can simplify the code for sama5d3 compatible DDR controllers, we instantiate a new sama5d3_ddr_standby() function. Signed-off-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Cc: <stable@vger.kernel.org> # v4.1+ Fixes: 017b5522 ("ARM: at91: Add new binding for sama5d3-ddramc") Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Bin Liu authored
[ Upstream commit 0090114d ] The CPPI 4.1 driver polls register to workaround the premature TX interrupt issue, but it causes audio playback underrun when triggered in Isoch transfers. Isoch doesn't do back-to-back transfers, the TX should be done by the time the next transfer is scheduled. So skip this polling workaround for Isoch transfer. Fixes: a655f481 ("usb: musb: musb_cppi41: handle pre-mature TX complete interrupt") Cc: <stable@vger.kernel.org> #4.1+ Reported-by:
Alexandre Bailon <abailon@baylibre.com> Acked-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by:
Bin Liu <b-liu@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Samuel Thibault authored
[ Upstream commit 3243367b ] Some USB 2.0 devices erroneously report millisecond values in bInterval. The generic config code manages to catch most of them, but in some cases it's not completely enough. The case at stake here is a USB 2.0 braille device, which wants to announce 10ms and thus sets bInterval to 10, but with the USB 2.0 computation that yields to 64ms. It happens that one can type fast enough to reach this interval and get the device buffers overflown, leading to problematic latencies. The generic config code does not catch this case because the 64ms is considered a sane enough value. This change thus adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by:
Samuel Thibault <samuel.thibault@ens-lyon.org> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 4ce36271 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Note that the dereference happens in the cmd and wait_init_done callbacks which are called during probe. Fixes: 1ba47da5 ("uwb: add the i1480 DFU driver") Cc: stable <stable@vger.kernel.org> # 2.6.28 Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit daf229b1 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Note that the dereference happens in the start callback which is called during probe. Fixes: de520b8b ("uwb: add HWA radio controller driver") Cc: stable <stable@vger.kernel.org> # 2.6.28 Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 03ace948 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. This specifically fixes the NULL-pointer dereference when probing HWA HC devices. Fixes: df365423 ("wusb: add the Wire Adapter (WA) core") Cc: stable <stable@vger.kernel.org> # 2.6.28 Cc: Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com> Cc: David Vrabel <david.vrabel@csr.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit f259ca3e ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer or accessing memory beyond the endpoint array should a malicious device lack the expected endpoints. Note that the endpoint access that causes the NULL-deref is currently only used for debugging purposes during probe so the oops only happens when dynamic debugging is enabled. This means the driver could be rewritten to continue to accept device with only two endpoints, should such devices exist. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 1dc56c52 ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should the probed device lack endpoints. Note that this driver does not bind to any devices by default. Fixes: ce21bfe6 ("USB: Add LVS Test device driver") Cc: stable <stable@vger.kernel.org> # 3.17 Cc: Pratyush Anand <pratyush.anand@gmail.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit b0addd3f ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 68c32f9c ] Make sure to check the number of endpoints to avoid dereferencing a NULL-pointer should a malicious device lack endpoints. Fixes: cf7776dc ("[PATCH] isdn4linux: Siemens Gigaset drivers - direct USB connection") Cc: stable <stable@vger.kernel.org> # 2.6.17 Cc: Hansjoerg Lipp <hjlipp@web.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
OGAWA Hirofumi authored
[ Upstream commit c0d0e351 ] Recently fallocate patch was merged and it uses MSDOS_I(inode)->mmu_private at fat_evict_inode(). However, fat_inode/fsinfo_inode that was introduced in past didn't initialize MSDOS_I(inode) properly. With those combinations, it became the cause of accessing random entry in FAT area. Link: http://lkml.kernel.org/r/87pohrj4i8.fsf@mail.parknet.co.jpSigned-off-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Reported-by:
Moreno Bartalucci <moreno.bartalucci@tecnorama.it> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Shaohua Li authored
[ Upstream commit 61eb2b43 ] Neil Brown pointed out a potential deadlock in raid 10 code with bio_split/chain. The raid1 code could have the same issue, but recent barrier rework makes it less likely to happen. The deadlock happens in below sequence: 1. generic_make_request(bio), this will set current->bio_list 2. raid10_make_request will split bio to bio1 and bio2 3. __make_request(bio1), wait_barrer, add underlayer disk bio to current->bio_list 4. __make_request(bio2), wait_barrer If raise_barrier happens between 3 & 4, since wait_barrier runs at 3, raise_barrier waits for IO completion from 3. And since raise_barrier sets barrier, 4 waits for raise_barrier. But IO from 3 can't be dispatched because raid10_make_request() doesn't finished yet. The solution is to adjust the IO ordering. Quotes from Neil: " It is much safer to: if (need to split) { split = bio_split(bio, ...) bio_chain(...) make_request_fn(split); generic_make_request(bio); } else make_request_fn(mddev, bio); This way we first process the initial section of the bio (in 'split') which will queue some requests to the underlying devices. These requests will be queued in generic_make_request. Then we queue the remainder of the bio, which will be added to the end of the generic_make_request queue. Then we return. generic_make_request() will pop the lower-level device requests off the queue and handle them first. Then it will process the remainder of the original bio once the first section has been fully processed. " Note, this only happens in read path. In write path, the bio is flushed to underlaying disks either by blk flush (from schedule) or offladed to raid1/10d. It's queued in current->bio_list. Cc: Coly Li <colyli@suse.de> Cc: stable@vger.kernel.org (v3.14+, only the raid10 part) Suggested-by:
NeilBrown <neilb@suse.com> Reviewed-by:
Jack Wang <jinpu.wang@profitbricks.com> Signed-off-by:
Shaohua Li <shli@fb.com> Signed-off-by:
-
Guenter Roeck authored
[ Upstream commit dcc7620c ] Upstream commit 98d74f9c ("xhci: fix 10 second timeout on removal of PCI hotpluggable xhci controllers") fixes a problem with hot pluggable PCI xhci controllers which can result in excessive timeouts, to the point where the system reports a deadlock. The same problem is seen with hot pluggable xhci controllers using the xhci-plat driver, such as the driver used for Type-C ports on rk3399. Similar to hot-pluggable PCI controllers, the driver for this chip removes the xhci controller from the system when the Type-C cable is disconnected. The solution for PCI devices works just as well for non-PCI devices and avoids the problem. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit de46e566 ] Make sure to verify that we have the required interrupt-out endpoint for IOWarrior56 devices to avoid dereferencing a NULL-pointer in write should a malicious device lack such an endpoint. Fixes: 946b960d ("USB: add driver for iowarrior devices.") Cc: stable <stable@vger.kernel.org> # 2.6.21 Signed-off-by:
-
Johan Hovold authored
[ Upstream commit b7321e81 ] Make sure to check for the required interrupt-in endpoint to avoid dereferencing a NULL-pointer should a malicious device lack such an endpoint. Note that a fairly recent change purported to fix this issue, but added an insufficient test on the number of endpoints only, a test which can now be removed. Fixes: 4ec0ef3a ("USB: iowarrior: fix oops with malicious USB descriptors") Fixes: 946b960d ("USB: add driver for iowarrior devices.") Cc: stable <stable@vger.kernel.org> # 2.6.21 Signed-off-by:
-
Dmitry Tunin authored
[ Upstream commit 16ff1fb0 ] T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#= 7 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs= 1 P: Vendor=1eda ProdID=2315 Rev=01.08 S: Manufacturer=ATHEROS S: Product=USB2.0 WLAN S: SerialNumber=12345 C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 6 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Signed-off-by:
Dmitry Tunin <hanipouspilot@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 8c76d7cd ] Add missing sanity check to the bulk-in completion handler to avoid an integer underflow that could be triggered by a malicious device. This avoids leaking up to 56 bytes from after the URB transfer buffer to user space. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 654b404f ] Add missing sanity check to the bulk-in completion handler to avoid an integer underflow that can be triggered by a malicious device. This avoids leaking 128 kB of memory content from after the URB transfer buffer to user space. Fixes: 8c209e67 ("USB: make actual_length in struct urb field u32") Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> # 2.6.30 Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 30572418 ] This driver needlessly took another reference to the tty on open, a reference which was then never released on close. This lead to not just a leak of the tty, but also a driver reference leak that prevented the driver from being unloaded after a port had once been opened. Fixes: 4a90f09b ("tty: usb-serial krefs") Cc: stable <stable@vger.kernel.org> # 2.6.28 Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 0b1d250a ] Fix a NULL-pointer dereference in the interrupt callback should a malicious device send data containing a bad port number by adding the missing sanity check. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
John Crispin authored
[ Upstream commit 7c5a3d81 ] There are two copy & paste errors in the definition of the 5GHz LNA and second ethernet pinmux. Fixes: f576fb6a ("MIPS: ralink: cleanup the soc specific pinmux data") Signed-off-by:
John Crispin <john@phrozen.org> Signed-off-by:
Daniel Golle <daniel@makrotopia.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # 3.19.x- Patchwork: https://patchwork.linux-mips.org/patch/15328/Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Paul Burton authored
[ Upstream commit 4b5347a2 ] When building for microMIPS we need to ensure that the assembler always knows that there is code at the target of a branch or jump. Recent toolchains will fail to link a microMIPS kernel when this isn't the case due to what it thinks is a branch to non-microMIPS code. mips-mti-linux-gnu-ld kernel/built-in.o: .spinlock.text+0x2fc: Unsupported branch between ISA modes. mips-mti-linux-gnu-ld final link failed: Bad value This is due to inline assembly labels in spinlock.h not being followed by an instruction mnemonic, either due to a .subsection pseudo-op or the end of the inline asm block. Fix this with a .insn direction after such labels. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Signed-off-by:
Maciej W. Rozycki <macro@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Cc: <stable@vger.kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/15325/Signed-off-by:
-
James Hogan authored
[ Upstream commit 2e6c7747 ] When a 32-bit kernel is configured to support MIPS64r6 (CPU_MIPS64_R6), MIPS_O32_FP64_SUPPORT won't be selected as it should be because MIPS32_O32 is disabled (o32 is already the default ABI available on 32-bit kernels). This results in userland FP breakage as CP0_Status.FR is read-only 1 since r6 (when an FPU is present) so __enable_fpu() will fail to clear FR. This causes the FPU emulator to get used which will incorrectly emulate 32-bit FPU registers. Force o32 fp64 support in this case by also selecting MIPS_O32_FP64_SUPPORT from CPU_MIPS64_R6 if 32BIT. Fixes: 4e9d324d ("MIPS: Require O32 FP64 support for MIPS64 with O32 compat") Signed-off-by:
-
Max Lohrmann authored
[ Upstream commit 13603685 ] As reported by Max, the Windows 2008 R2 chkdsk utility expects VERIFY_16 to be supported, and does not handle the returned CHECK_CONDITION properly, resulting in an infinite loop. The kernel will log huge amounts of this error: kernel: TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x8f, sending CHECK_CONDITION. Signed-off-by:
Max Lohrmann <post@wickenrode.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
[ Upstream commit a04e54f2 ] The following fixes a divide by zero OOPs with TYPE_TAPE due to pscsi_tape_read_blocksize() failing causing a zero sd->sector_size being propigated up via dev_attrib.hw_block_size. It also fixes another long-standing bug where TYPE_TAPE and TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(), which does not call scsi_device_get() to take the device reference. Instead, rename pscsi_create_type_rom() to pscsi_create_type_nondisk() and use it for all cases. Finally, also drop a dump_stack() in pscsi_get_blocks() for non TYPE_DISK, which in modern target-core can get invoked via target_sense_desc_format() during CHECK_CONDITION. Reported-by:
Malcolm Haak <insanemal@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Anton Blanchard authored
[ Upstream commit 85e8a239 ] We see lpfc devices regularly fail during kexec. Fix this by adding a shutdown method which mirrors the remove method. Cc: <stable@vger.kernel.org> Signed-off-by:
Anton Blanchard <anton@samba.org> Reviewed-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Tested-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Michael Ellerman authored
[ Upstream commit 97ee351b ] Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in the zImage linker script, otherwise pointers to our TOC variables (__toc_start) could be incorrect. If the actual start of the TOC and __toc_start don't have the same value we crash early in the zImage wrapper. Cc: stable@vger.kernel.org Suggested-by:
Alan Modra <amodra@gmail.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
