- 13 Sep, 2016 2 commits
-
-
Aleksandr Makarov authored
[ Upstream commit 40d9c325 ] These product IDs are listed in Windows driver. 0x6803 corresponds to WeTelecom WM-D300. 0x6802 name is unknown. Signed-off-by:
Aleksandr Makarov <aleksandr.o.makarov@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com>
-
Aleksandr Makarov authored
[ Upstream commit 6695593e ] Add support for WeTelecom WM-D200. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=22de ProdID=6801 Rev=00.00 S: Manufacturer=WeTelecom Incorporated S: Product=WeTelecom Mobile Products C: #Ifs= 4 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) I: If#= 3 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage Signed-off-by:
-
- 12 Sep, 2016 10 commits
-
-
Alan Stern authored
[ Upstream commit 53e5f36f ] UBSAN complains about a left shift by -1 in proc_do_submiturb(). This can occur when an URB is submitted for a bulk or control endpoint on a high-speed device, since the code doesn't bother to check the endpoint type; normally only interrupt or isochronous endpoints have a nonzero bInterval value. Aside from the fact that the operation is illegal, it shouldn't matter because the result isn't used. Still, in theory it could cause a hardware exception or other problem, so we should work around it. This patch avoids doing the left shift unless the shift amount is >= 0. The same piece of code has another problem. When checking the device speed (the exponential encoding for interrupt endpoints is used only by high-speed or faster devices), we need to look for speed >= USB_SPEED_SUPER as well as speed == USB_SPEED HIGH. The patch adds this check. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Vittorio Zecca <zeccav@gmail.com> Tested-by:
Bjørn Mork <bjorn@mork.no> CC: <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 7ac61a06 ] Any readings from the raw interface of the KXSD9 driver will return an empty string, because it does not return IIO_VAL_INT but rather some random value from the accelerometer to the caller. Cc: stable@vger.kernel.org Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Ian Abbott authored
[ Upstream commit f0f4b0cc ] Commit ebb657ba ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use") introduced a backwards compatibility issue in the use of asynchronous commands on the AO subdevice when `start_src` is `TRIG_EXT`. Valid values for `start_src` are `TRIG_INT` (for internal, software trigger), and `TRIG_EXT` (for external trigger). When set to `TRIG_EXT`. In both cases, the driver relies on an internal, software trigger to set things up (allowing the user application to write sufficient samples to the data buffer before the trigger), so it acts as a software "pre-trigger" in the `TRIG_EXT` case. The software trigger is handled by `ni_ao_inttrig()`. Prior to the above change, when `start_src` was `TRIG_INT`, `start_arg` was required to be 0, and `ni_ao_inttrig()` checked that the software trigger number was also 0. After the above change, when `start_src` was `TRIG_INT`, any value was allowed for `start_arg`, and `ni_ao_inttrig()` checked that the software trigger number matched this `start_arg` value. The backwards compatibility issue is that the internal trigger number now has to match `start_arg` when `start_src` is `TRIG_EXT` when it previously had to be 0. Fix the backwards compatibility issue in `ni_ao_inttrig()` by always allowing software trigger number 0 when `start_src` is something other than `TRIG_INT`. Thanks to Spencer Olson for reporting the issue. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Reported-by:
Spencer Olson <olsonse@umich.edu> Fixes: ebb657ba ("staging: comedi: ni_mio_common: clarify the cmd->start_arg validation and use") Cc: stable <stable@vger.kernel.org> Reviewed-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by:
-
Ian Abbott authored
[ Upstream commit 5ca05345 ] For counter subdevices, the `s->insn_write` handler is being set to the wrong function, `ni_tio_insn_read()`. It should be `ni_tio_insn_write()`. Signed-off-by:
Éric Piel <piel@delmic.com> Fixes: 10f74377 ("staging: comedi: ni_tio: make ni_tio_winsn() a proper comedi (*insn_write)" Cc: <stable@vger.kernel.org> # 3.17+ Signed-off-by:
-
Ian Abbott authored
[ Upstream commit 80e162ee ] `daqboard2000_find_boardinfo()` is supposed to check if the DaqBoard/2000 series model is supported, based on the PCI subvendor and subdevice ID. The current code is wrong as it is comparing the PCI device's subdevice ID to an expected, fixed value for the subvendor ID. It should be comparing the PCI device's subvendor ID to this fixed value. Correct it. Fixes: 7e8401b2 ("staging: comedi: daqboard2000: add back subsystem_device check") Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit 3b7c7e52 ] There is an allocation with GFP_KERNEL flag in mos7840_write(), while it may be called from interrupt context. Follow-up for commit 19125283 ("USB: kobil_sct: fix non-atomic allocation in write path") Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit 5a5a1d61 ] There is an allocation with GFP_KERNEL flag in mos7720_write(), while it may be called from interrupt context. Follow-up for commit 19125283 ("USB: kobil_sct: fix non-atomic allocation in write path") Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
-
Zefan Li authored
[ Upstream commit 06f4e948 ] A new task inherits cpus_allowed and mems_allowed masks from its parent, but if someone changes cpuset's config by writing to cpuset.cpus/cpuset.mems before this new task is inserted into the cgroup's task list, the new task won't be updated accordingly. Signed-off-by:
Zefan Li <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Miklos Szeredi authored
[ Upstream commit 0956254a ] When a copy up of a directory occurs which has the opaque xattr set, the xattr remains in the upper directory. The immediate behavior with overlayfs is that the upper directory is not treated as opaque, however after a remount the opaque flag is used and upper directory is treated as opaque. This causes files created in the lower layer to be hidden when using multiple lower directories. Fix by not copying up the opaque flag. To reproduce: ----8<---------8<---------8<---------8<---------8<---------8<---- mkdir -p l/d/s u v w mnt mount -t overlay overlay -olowerdir=l,upperdir=u,workdir=w mnt rm -rf mnt/d/ mkdir -p mnt/d/n umount mnt mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt touch mnt/d/foo umount mnt mount -t overlay overlay -olowerdir=u:l,upperdir=v,workdir=w mnt ls mnt/d ----8<---------8<---------8<---------8<---------8<---------8<---- output should be: "foo n" Reported-by:
Derek McGowan <dmcg@drizz.net> Link: https://bugzilla.kernel.org/show_bug.cgi?id=151291Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Theodore Ts'o authored
[ Upstream commit 829fa70d ] A number of fuzzing failures seem to be caused by allocation bitmaps or other metadata blocks being pointed at the superblock. This can cause kernel BUG or WARNings once the superblock is overwritten, so validate the group descriptor blocks to make sure this doesn't happen. Cc: stable@vger.kernel.org Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
- 11 Sep, 2016 1 commit
-
-
Al Viro authored
[ Upstream commit 76cc404b ] Cc: stable@vger.kernel.org # 3.15+ Reviewed-by:
Jeff Layton <jeff.layton@primarydata.com> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 03 Sep, 2016 6 commits
-
-
Sasha Levin authored
Signed-off-by: -
Simon Horman authored
[ Upstream commit c2e771b0 ] Like the NFP6000, the NFP4000 as an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP4000's PF's config space size to 0x600 bytes as is already done for the NFP6000. The NFP4000's VF is 0x6004 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same device ID as the NFP6000's VF. Thus, its config space is already limited by the existing use of quirk_nfp6000(). Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Simon Horman authored
[ Upstream commit 69874ec2 ] Add the device ID for the PF of the NFP4000. The device ID for the VF, 0x6003, is already present as PCI_DEVICE_ID_NETRONOME_NFP6000_VF. Signed-off-by:
-
Jason S. McMullan authored
[ Upstream commit 9f33a2ae ] The NFP6000 has an erratum where reading/writing to PCI config space addresses above 0x600 can cause the NFP to generate PCIe completion timeouts. Limit the NFP6000's config space size to 0x600 bytes. Signed-off-by:
Jason S. McMullan <jason.mcmullan@netronome.com> [simon: edited changelog] Signed-off-by:
-
Jason S. McMullan authored
[ Upstream commit a755e169 ] Device IDs for the Netronome NFP3200, NFP3240, NFP6000, and NFP6000 SR-IOV devices. Signed-off-by:
-
Jason S. McMullan authored
[ Upstream commit c20aecf6 ] If a device quirk modifies the pci_dev->cfg_size to be less than PCI_CFG_SPACE_EXP_SIZE (4096), but greater than PCI_CFG_SPACE_SIZE (256), the PCI sysfs interface truncates the readable size to PCI_CFG_SPACE_SIZE. Allow sysfs access to config space up to cfg_size, even if the device doesn't support the entire 4096-byte PCIe config space. Note that pci_read_config() and pci_write_config() limit access to dev->cfg_size even though pcie_config_attr contains 4096 (the maximum size). Signed-off-by:
-
- 02 Sep, 2016 1 commit
-
-
Hubert Feurstein authored
[ Upstream commit 0c818594 ] This patch initialises the fep->netdev pointer. This pointer was not initialised at all, but is used in fec_enet_timeout_work and in some error paths. Signed-off-by:
Hubert Feurstein <h.feurstein@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
- 01 Sep, 2016 20 commits
-
-
Vegard Nossum authored
[ Upstream commit 088bf2ff ] seq_read() is a nasty piece of work, not to mention buggy. It has (I think) an old bug which allows unprivileged userspace to read beyond the end of m->buf. I was getting these: BUG: KASAN: slab-out-of-bounds in seq_read+0xcd2/0x1480 at addr ffff880116889880 Read of size 2713 by task trinity-c2/1329 CPU: 2 PID: 1329 Comm: trinity-c2 Not tainted 4.8.0-rc1+ #96 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: kasan_object_err+0x1c/0x80 kasan_report_error+0x2cb/0x7e0 kasan_report+0x4e/0x80 check_memory_region+0x13e/0x1a0 kasan_check_read+0x11/0x20 seq_read+0xcd2/0x1480 proc_reg_read+0x10b/0x260 do_loop_readv_writev.part.5+0x140/0x2c0 do_readv_writev+0x589/0x860 vfs_readv+0x7b/0xd0 do_readv+0xd8/0x2c0 SyS_readv+0xb/0x10 do_syscall_64+0x1b3/0x4b0 entry_SYSCALL64_slow_path+0x25/0x25 Object at ffff880116889100, in cache kmalloc-4096 size: 4096 Allocated: PID = 1329 save_stack_trace+0x26/0x80 save_stack+0x46/0xd0 kasan_kmalloc+0xad/0xe0 __kmalloc+0x1aa/0x4a0 seq_buf_alloc+0x35/0x40 seq_read+0x7d8/0x1480 proc_reg_read+0x10b/0x260 do_loop_readv_writev.part.5+0x140/0x2c0 do_readv_writev+0x589/0x860 vfs_readv+0x7b/0xd0 do_readv+0xd8/0x2c0 SyS_readv+0xb/0x10 do_syscall_64+0x1b3/0x4b0 return_from_SYSCALL_64+0x0/0x6a Freed: PID = 0 (stack is not available) Memory state around the buggy address: ffff88011688a000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88011688a080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88011688a100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff88011688a180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88011688a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Disabling lock debugging due to kernel taint This seems to be the same thing that Dave Jones was seeing here: https://lkml.org/lkml/2016/8/12/334 There are multiple issues here: 1) If we enter the function with a non-empty buffer, there is an attempt to flush it. But it was not clearing m->from after doing so, which means that if we try to do this flush twice in a row without any call to traverse() in between, we are going to be reading from the wrong place -- the splat above, fixed by this patch. 2) If there's a short write to userspace because of page faults, the buffer may already contain multiple lines (i.e. pos has advanced by more than 1), but we don't save the progress that was made so the next call will output what we've already returned previously. Since that is a much less serious issue (and I have a headache after staring at seq_read() for the past 8 hours), I'll leave that for now. Link: http://lkml.kernel.org/r/1471447270-32093-1-git-send-email-vegard.nossum@oracle.comSigned-off-by:
Vegard Nossum <vegard.nossum@oracle.com> Reported-by:
Dave Jones <davej@codemonkey.org.uk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Chen-Yu Tsai authored
[ Upstream commit b53e7d00 ] The bootloader (U-boot) sometimes uses this timer for various delays. It uses it as a ongoing counter, and does comparisons on the current counter value. The timer counter is never stopped. In some cases when the user interacts with the bootloader, or lets it idle for some time before loading Linux, the timer may expire, and an interrupt will be pending. This results in an unexpected interrupt when the timer interrupt is enabled by the kernel, at which point the event_handler isn't set yet. This results in a NULL pointer dereference exception, panic, and no way to reboot. Clear any pending interrupts after we stop the timer in the probe function to avoid this. Cc: stable@vger.kernel.org Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by:
Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by:
-
Mike Snitzer authored
[ Upstream commit 299f6230 ] v4.8-rc3 commit 99f3c90d ("dm flakey: error READ bios during the down_interval") overlooked the 'drop_writes' feature, which is meant to allow reads to be issued rather than errored, during the down_interval. Fixes: 99f3c90d ("dm flakey: error READ bios during the down_interval") Reported-by:
Qu Wenruo <quwenruo@cn.fujitsu.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jan Beulich authored
[ Upstream commit 9a035a40 ] This should really only be done for XS_TRANSACTION_END messages, or else at least some of the xenstore-* tools don't work anymore. Fixes: 0beef634 ("xenbus: don't BUG() on user mode induced condition") Reported-by:
Richard Schütz <rschuetz@uni-koblenz.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Jan Beulich <jbeulich@suse.com> Tested-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
John Stultz authored
[ Upstream commit a4f8f666 ] It was reported that hibernation could fail on the 2nd attempt, where the system hangs at hibernate() -> syscore_resume() -> i8237A_resume() -> claim_dma_lock(), because the lock has already been taken. However there is actually no other process would like to grab this lock on that problematic platform. Further investigation showed that the problem is triggered by setting /sys/power/pm_trace to 1 before the 1st hibernation. Since once pm_trace is enabled, the rtc becomes unmeaningful after suspend, and meanwhile some BIOSes would like to adjust the 'invalid' RTC (e.g, smaller than 1970) to the release date of that motherboard during POST stage, thus after resumed, it may seem that the system had a significant long sleep time which is a completely meaningless value. Then in timekeeping_resume -> tk_debug_account_sleep_time, if the bit31 of the sleep time happened to be set to 1, fls() returns 32 and we add 1 to sleep_time_bin[32], which causes an out of bounds array access and therefor memory being overwritten. As depicted by System.map: 0xffffffff81c9d080 b sleep_time_bin 0xffffffff81c9d100 B dma_spin_lock the dma_spin_lock.val is set to 1, which caused this problem. This patch adds a sanity check in tk_debug_account_sleep_time() to ensure we don't index past the sleep_time_bin array. [jstultz: Problem diagnosed and original patch by Chen Yu, I've solved the issue slightly differently, but borrowed his excelent explanation of the issue here.] Fixes: 5c83545f "power: Add option to log time spent in suspend" Reported-by:
Janek Kozicki <cosurgi@gmail.com> Reported-by:
Chen Yu <yu.c.chen@intel.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: linux-pm@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Cc: Xunlei Pang <xpang@redhat.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: stable <stable@vger.kernel.org> Cc: Zhang Rui <rui.zhang@intel.com> Link: http://lkml.kernel.org/r/1471993702-29148-3-git-send-email-john.stultz@linaro.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Vincent Stehlé authored
[ Upstream commit c0082e98 ] An assertion in layout_in_gaps() verifies that the gap_lebs pointer is below the maximum bound. When computing this maximum bound the idx_lebs count is multiplied by sizeof(int), while C pointers arithmetic does take into account the size of the pointed elements implicitly already. Remove the multiplication to fix the assertion. Fixes: 1e51764a ("UBIFS: add new flash file system") Cc: <stable@vger.kernel.org> Signed-off-by:
Vincent Stehlé <vincent.stehle@intel.com> Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit fae16989 ] Commit fe6b0dfa ("Input: tegra-kbc - use reset framework") accidentally converted _deassert to _assert, so there is no code to wake up this hardware. Fixes: fe6b0dfa ("Input: tegra-kbc - use reset framework") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Laxman Dewangan <ldewangan@nvidia.com> Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Daniel Vetter authored
[ Upstream commit 6f00975c ] Somehow this one slipped through, which means drivers without modeset support can be oopsed (since those also don't call drm_mode_config_init, which means the crtc lookup will chase an uninitalized idr). Reported-by:
Alexander Potapenko <glider@google.com> Cc: Alexander Potapenko <glider@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Helge Deller authored
[ Upstream commit 3eb53b20 ] When building gccgo in userspace, errno.h gets parsed and the go include file sysinfo.go is generated. Since EREFUSED is defined to the same value as ECONNREFUSED, and ECONNREFUSED is defined later on in errno.h, this leads to go complaining that EREFUSED isn't defined yet. Fix this trivial problem by moving the define of EREFUSED down after ECONNREFUSED in errno.h (and clean up the indenting while touching this line). Signed-off-by:
Helge Deller <deller@gmx.de> Cc: stable@vger.kernel.org Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit c57653dc ] Some module using div_u64() was failing to link because the libgcc 64-bit divide assist routine was not being exported for modules Reported-by: avinashp@quantenna.com Cc: stable@vger.kernel.org Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit 840c054f ] The syscall ABI includes the gcc functional calling ABI since a syscall implies userland caller and kernel callee. The current gcc ABI (v3) for ARCv2 ISA required 64-bit data be passed in even-odd register pairs, (potentially punching reg holes when passing such values as args). This was partly driven by the fact that the double-word LDD/STD instructions in ARCv2 expect the register alignment and thus gcc forcing this avoids extra MOV at the cost of a few unused register (which we have plenty anyways). This however was rejected as part of upstreaming gcc port to HS. So the new ABI v4 doesn't enforce the even-odd reg restriction. Do note that for ARCompact ISA builds v3 and v4 are practically the same in terms of gcc code generation. In terms of change management, we infer the new ABI if gcc 6.x onwards is used for building the kernel. This also needs a stable backport to enable older kernels to work with new tools/user-space Cc: <stable@vger.kernel.org> Signed-off-by:
-
Liav Rehana authored
[ Upstream commit 86147e3c ] User mode callee regs are explicitly collected before signal delivery or breakpoint trap. r25 is special for kernel as it serves as task pointer, so user mode value is clobbered very early. It is saved in pt_regs where generally only scratch (aka caller saved) regs are saved. The code to access the corresponding pt_regs location had a subtle bug as it was using load/store with scaling of offset, whereas the offset was already byte wise correct. So fix this by replacing LD.AS with a standard LD Cc: <stable@vger.kernel.org> Signed-off-by:
Liav Rehana <liavr@mellanox.com> Reviewed-by:
Alexey Brodkin <abrodkin@synopsys.com> [vgupta: rewrote title and commit log] Signed-off-by:
-
Vineet Gupta authored
[ Upstream commit 0d7b8855 ] Reported by Anton as LTP:munmap01 failing with Illegal Instruction Exception. --------------------->8-------------------------------------- mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x200d2000 munmap(0x200d2000, 24576) = 0 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x200d2000} --- potentially unexpected fatal signal 4. Path: /munmap01 CPU: 0 PID: 61 Comm: munmap01 Not tainted 3.13.0-g5d5c46d9a556 #8 task: 9f1a8000 ti: 9f154000 task.ti: 9f154000 [ECR ]: 0x00020100 => Illegal Insn [EFA ]: 0x0001354c [BLINK ]: 0x200515d4 [ERET ]: 0x1354c @off 0x1354c in [/munmap01] VMA: 0x00010000 to 0x00018000 [STAT32]: 0x800802c0 ... --------------------->8-------------------------------------- The issue was 1. munmap01 accessed unmapped memory (on purpose) with signal handler installed for SIGSEGV 2. The faulting instruction happened to be in Delay Slot 00011864 <main>: 11908: bl.d 13284 <tst_resm> 1190c: stb r16,[r2] 3. kernel sets up the reg file for signal handler and correctly clears the DE bit in pt_regs->status32 placeholder 4. However RESTORE_CALLEE_SAVED_USER macro is not adjusted for ARCv2, and it over-writes the above with orig/stale value of status32 5. After RTIE, userspace signal handler executes a non branch instruction with DE bit set, triggering Illegal Instruction Exception. Reported-by:
Anton Kolesov <akolesov@synopsys.com> Signed-off-by:
-
Dmitry Torokhov authored
[ Upstream commit 47af45d6 ] The commit 40974618 ("Input: i8042 - break load dependency ...") correctly set up ps2_cmd_mutex pointer for the KBD port but forgot to do the same for AUX port(s), which results in communication on KBD and AUX ports to clash with each other. Fixes: 40974618 ("Input: i8042 - break load dependency ...") Reported-by:
Bruno Wolff III <bruno@wolff.to> Tested-by:
-
Christian König authored
[ Upstream commit 13f479b9 ] This bug seems to be present for a very long time. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Linus Walleij authored
[ Upstream commit 2527ecc9 ] The UserMode (UM) Linux build was failing in gpiolib-of as it requires ioremap()/iounmap() to exist, which is absent from UM. The non-existence of IO memory is negatively defined as CONFIG_NO_IOMEM which means we need to depend on HAS_IOMEM. Cc: stable@vger.kernel.org Cc: Geert Uytterhoeven <geert@linux-m68k.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Kent Overstreet authored
[ Upstream commit acc9cf8c ] This patch fixes a cachedev registration-time allocation deadlock. This can deadlock on boot if your initrd auto-registeres bcache devices: Allocator thread: [ 720.727614] INFO: task bcache_allocato:3833 blocked for more than 120 seconds. [ 720.732361] [<ffffffff816eeac7>] schedule+0x37/0x90 [ 720.732963] [<ffffffffa05192b8>] bch_bucket_alloc+0x188/0x360 [bcache] [ 720.733538] [<ffffffff810e6950>] ? prepare_to_wait_event+0xf0/0xf0 [ 720.734137] [<ffffffffa05302bd>] bch_prio_write+0x19d/0x340 [bcache] [ 720.734715] [<ffffffffa05190bf>] bch_allocator_thread+0x3ff/0x470 [bcache] [ 720.735311] [<ffffffff816ee41c>] ? __schedule+0x2dc/0x950 [ 720.735884] [<ffffffffa0518cc0>] ? invalidate_buckets+0x980/0x980 [bcache] Registration thread: [ 720.710403] INFO: task bash:3531 blocked for more than 120 seconds. [ 720.715226] [<ffffffff816eeac7>] schedule+0x37/0x90 [ 720.715805] [<ffffffffa05235cd>] __bch_btree_map_nodes+0x12d/0x150 [bcache] [ 720.716409] [<ffffffffa0522d30>] ? bch_btree_insert_check_key+0x1c0/0x1c0 [bcache] [ 720.717008] [<ffffffffa05236e4>] bch_btree_insert+0xf4/0x170 [bcache] [ 720.717586] [<ffffffff810e6950>] ? prepare_to_wait_event+0xf0/0xf0 [ 720.718191] [<ffffffffa0527d9a>] bch_journal_replay+0x14a/0x290 [bcache] [ 720.718766] [<ffffffff810cc90d>] ? ttwu_do_activate.constprop.94+0x5d/0x70 [ 720.719369] [<ffffffff810cf684>] ? try_to_wake_up+0x1d4/0x350 [ 720.719968] [<ffffffffa05317d0>] run_cache_set+0x580/0x8e0 [bcache] [ 720.720553] [<ffffffffa053302e>] register_bcache+0xe2e/0x13b0 [bcache] [ 720.721153] [<ffffffff81354cef>] kobj_attr_store+0xf/0x20 [ 720.721730] [<ffffffff812a2dad>] sysfs_kf_write+0x3d/0x50 [ 720.722327] [<ffffffff812a225a>] kernfs_fop_write+0x12a/0x180 [ 720.722904] [<ffffffff81225177>] __vfs_write+0x37/0x110 [ 720.723503] [<ffffffff81228048>] ? __sb_start_write+0x58/0x110 [ 720.724100] [<ffffffff812cedb3>] ? security_file_permission+0x23/0xa0 [ 720.724675] [<ffffffff812258a9>] vfs_write+0xa9/0x1b0 [ 720.725275] [<ffffffff8102479c>] ? do_audit_syscall_entry+0x6c/0x70 [ 720.725849] [<ffffffff81226755>] SyS_write+0x55/0xd0 [ 720.726451] [<ffffffff8106a390>] ? do_page_fault+0x30/0x80 [ 720.727045] [<ffffffff816f2cae>] system_call_fastpath+0x12/0x71 The fifo code in upstream bcache can't use the last element in the buffer, which was the cause of the bug: if you asked for a power of two size, it'd give you a fifo that could hold one less than what you asked for rather than allocating a buffer twice as big. Signed-off-by:
Kent Overstreet <kent.overstreet@gmail.com> Tested-by:
Eric Wheeler <bcache@linux.ewheeler.net> Cc: stable@vger.kernel.org Signed-off-by:
-
Eric Wheeler authored
[ Upstream commit d9dc1702 ] register_cache() is supposed to return an error string on error so that register_bcache() will will blkdev_put and cleanup other user counters, but it does not set 'char *err' when cache_alloc() fails (eg, due to memory pressure) and thus register_bcache() performs no cleanup. register_bcache() <----------\ <- no jump to err_close, no blkdev_put() | | +->register_cache() | <- fails to set char *err | | +->cache_alloc() ---/ <- returns error This patch sets `char *err` for this failure case so that register_cache() will cause register_bcache() to correctly jump to err_close and do cleanup. This was tested under OOM conditions that triggered the bug. Signed-off-by:
-
Christian König authored
[ Upstream commit ae5b80d2 ] Looks like some RV6xx have problems with that. bug: https://bugs.freedesktop.org/show_bug.cgi?id=97099Reviewed-by:
-
Christian König authored
[ Upstream commit 9ef8537e ] Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven for working a lot with the PLLs and figuring this out. Reviewed-by:
-
