- 06 Dec, 2014 15 commits
-
-
Andy Lutomirski authored
commit b645af2d upstream. It's possible for iretq to userspace to fail. This can happen because of a bad CS, SS, or RIP. Historically, we've handled it by fixing up an exception from iretq to land at bad_iret, which pretends that the failed iret frame was really the hardware part of #GP(0) from userspace. To make this work, there's an extra fixup to fudge the gs base into a usable state. This is suboptimal because it loses the original exception. It's also buggy because there's no guarantee that we were on the kernel stack to begin with. For example, if the failing iret happened on return from an NMI, then we'll end up executing general_protection on the NMI stack. This is bad for several reasons, the most immediate of which is that general_protection, as a non-paranoid idtentry, will try to deliver signals and/or schedule from the wrong stack. This patch throws out bad_iret entirely. As a replacement, it augments the existing swapgs fudge into a full-blown iret fixup, mostly written in C. It's should be clearer and more correct. Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Andy Lutomirski authored
commit 6f442be2 upstream. On a 32-bit kernel, this has no effect, since there are no IST stacks. On a 64-bit kernel, #SS can only happen in user code, on a failed iret to user space, a canonical violation on access via RSP or RBP, or a genuine stack segment violation in 32-bit kernel code. The first two cases don't need IST, and the latter two cases are unlikely fatal bugs, and promoting them to double faults would be fine. This fixes a bug in which the espfix64 code mishandles a stack segment violation. This saves 4k of memory per CPU and a tiny bit of code. Signed-off-by:
-
Andy Lutomirski authored
commit af726f21 upstream. There's nothing special enough about the espfix64 double fault fixup to justify writing it in assembly. Move it to C. This also fixes a bug: if the double fault came from an IST stack, the old asm code would return to a partially uninitialized stack frame. Fixes: 3891a04aSigned-off-by:
-
Aaro Koskinen authored
commit 26927f76 upstream. If SERIAL_8250 is compiled as a module, the platform specific setup for Loongson will be a module too, and it will not work very well. At least on Loongson 3 it will trigger a build failure, since loongson_sysconf is not exported to modules. Fix by making the platform specific serial code always built-in. Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Reported-by:
Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: Huacai Chen <chenhc@lemote.com> Cc: Markos Chandras <Markos.Chandras@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/8533/Signed-off-by:
-
Aaro Koskinen authored
commit bbaf113a upstream. Fix incorrect cast that always results in wrong address for the new frame on 64-bit kernels. Signed-off-by:
Aaro Koskinen <aaro.koskinen@nsn.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8110/Signed-off-by:
-
Alexander Gordeev authored
commit 2adc7907 upstream. If populate_msi_sysfs() function failed msix_capability_init() must return the error code, but it returns the success instead. This update fixes the described misbehaviour. Signed-off-by:
Alexander Gordeev <agordeev@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit e4742b1e upstream. The new Lenovo T440s laptop has a different PnP ID "LEN0039", and it needs the similar min/max quirk to make its clickpad working. BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=903748Reported-and-tested-by:
Joschi Brauchle <joschibrauchle@gmx.de> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit e76aed9d upstream. https://bugzilla.redhat.com/show_bug.cgi?id=1114768 Cc: stable@vger.kernel.org Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Benjamin Tissoires authored
commit d49cb7ae upstream. commit 421e08c4 fixed the reported min/max for the X and Y axis, but unfortunately, it broke the resolution of those same axis. On the t540p, the resolution is the same regarding X and Y. It is not a problem for xf86-input-synaptics because this driver is only interested in the ratio between X and Y. Unfortunately, xf86-input-cmt uses directly the resolution, and having a null resolution leads to some divide by 0 errors, which are translated by -infinity in the resulting coordinates. Reported-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Hans de Goede authored
commit 0f68f39c upstream. Most of the affected models share pnp-ids for the touchpad. So switching to pnp-ids give us 2 advantages: 1) It shrinks the quirk list 2) It will lower the new quirk addition frequency, ie the recently added W540 quirk would not have been necessary since it uses the same LEN0034 pnp ids as other models already added before it As an added bonus it actually puts the quirk on the actual psmouse, rather then on the machine, which is technically more correct. Cc: stable@vger.kernel.org Signed-off-by:
-
Hans de Goede authored
commit e2f61102 upstream. This is a preparation patch for simplifying the min/max quirk table. Cc: stable@vger.kernel.org Signed-off-by:
-
Hans de Goede authored
commit 43e19888 upstream. Check PNP ID of the PS/2 AUX port and report INPUT_PROP_TOPBUTTONPAD property for for touchpads with top button areas. Signed-off-by:
-
Hans de Goede authored
commit f37c0134 upstream. On some newer laptops with a trackpoint the physical buttons for the trackpoint have been removed to allow for a larger touchpad. On these laptops the buttonpad has clearly marked areas on the top which are to be used as trackpad buttons. Users of the event device-node need to know about this, so that they can properly interpret BTN_LEFT events as being a left / right / middle click depending on where on the button pad the clicking finger is. This commits adds a INPUT_PROP_TOPBUTTONPAD device property which drivers for such buttonpads will use to signal to the user that this buttonpad not only has the normal bottom button area, but also a top button area. Signed-off-by:
-
Hans de Goede authored
commit a7c5868c upstream. Fill in the new serio firmware_id sysfs attribute for pnp instantiated 8042 serio ports. Signed-off-by:
-
Hans de Goede authored
commit 0456c66f upstream. serio devices exposed via platform firmware interfaces such as ACPI may provide additional identifying information of use to userspace. We don't associate the serio devices with the firmware device (we don't set it as parent), so there's no way for userspace to make use of this information. We cannot change the parent for serio devices instantiated though a firmware interface as that would break suspend / resume ordering. Therefore this patch adds a new firmware_id sysfs attribute so that userspace can get a string from there with any additional identifying information the firmware interface may provide. Signed-off-by:
-
- 03 Dec, 2014 7 commits
-
-
Jiri Slaby authored
-
Paolo Bonzini authored
commit c1118b36 upstream. On x86_64, kernel text mappings are mapped read-only with CONFIG_DEBUG_RODATA. In that case, KVM will fail to patch VMCALL instructions to VMMCALL as required on AMD processors. The failure mode is currently a divide-by-zero exception, which obviously is a KVM bug that has to be fixed. However, picking the right instruction between VMCALL and VMMCALL will be faster and will help if you cannot upgrade the hypervisor. Reported-by:
Chris Webb <chris@arachsys.com> Tested-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Fabian Frederick authored
commit 24e4a0f3 upstream. According to commit 5f16f322 ext4: atomically set inode->i_flags in ext4_set_inode_flags() Signed-off-by:
Fabian Frederick <fabf@skynet.be> Signed-off-by:
Dave Kleikamp <dave.kleikamp@oracle.com> Cc: "Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Theodore Ts'o authored
commit 5f16f322 upstream. Use cmpxchg() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race where an immutable file has the immutable flag cleared for a brief window of time. js: there is no change for ext4. This patch defines merely inode_set_flags for jffs in the next patch. I wonder why do we have both inode_set_flags and set_mask_bits? Looks like an improperly resolved merge conflict. Reported-by:
John Sullivan <jsrhbz@kanargh.force9.co.uk> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
-
Qi Yong authored
commit 6d6747f8 upstream. The original minix zmap blocks calculation was correct, in the formula of: sbi->s_nzones - sbi->s_firstdatazone + 1 It is sp->s_zones - (sp->s_firstdatazone - 1) in the minix3 source code. But a later commit 016e8d44 ("fs/minix: Verify bitmap block counts before mounting") has changed it unfortunately as: sbi->s_nzones - (sbi->s_firstdatazone + 1) This would show free blocks one block less than the real when the total data blocks are in "full zmap blocks plus one". This patch corrects that zmap blocks calculation and tidy a printk message while at it. Signed-off-by:
Qi Yong <qiyong@fc-cn.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andreas Rohner authored
commit e2c7617a upstream. Under normal circumstances nilfs_sync_fs() writes out the super block, which causes a flush of the underlying block device. But this depends on the THE_NILFS_SB_DIRTY flag, which is only set if the pointer to the last segment crosses a segment boundary. So if only a small amount of data is written before the call to nilfs_sync_fs(), no flush of the block device occurs. In the above case an additional call to blkdev_issue_flush() is needed. To prevent unnecessary overhead, the new flag nilfs->ns_flushed_device is introduced, which is cleared whenever new logs are written and set whenever the block device is flushed. For convenience the function nilfs_flush_device() is added, which contains the above logic. Signed-off-by:
Andreas Rohner <andreas.rohner@gmx.net> Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Signed-off-by:
-
Al Viro authored
commit d311d79d upstream. It actually goes back to 2004 ([PATCH] Concurrent O_SYNC write support) when sync_page_range() had been introduced; generic_file_write{,v}() correctly synced pos_after_write - written .. pos_after_write - 1 but generic_file_aio_write() synced pos_before_write .. pos_before_write + written - 1 instead. Which is not the same thing with O_APPEND, obviously. A couple of years later correct variant had been killed off when everything switched to use of generic_file_aio_write(). All users of generic_file_aio_write() are affected, and the same bug has been copied into other instances of ->aio_write(). The fix is trivial; the only subtle point is that generic_write_sync() ought to be inlined to avoid calculations useless for the majority of calls. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
- 27 Nov, 2014 7 commits
-
-
Jiri Bohac authored
[ Upstream commit 01462405 ] This fixes an old regression introduced by commit b0d0d915 (ipx: remove the BKL). When a recvmsg syscall blocks waiting for new data, no data can be sent on the same socket with sendmsg because ipx_recvmsg() sleeps with the socket locked. This breaks mars-nwe (NetWare emulator): - the ncpserv process reads the request using recvmsg - ncpserv forks and spawns nwconn - ncpserv calls a (blocking) recvmsg and waits for new requests - nwconn deadlocks in sendmsg on the same socket Commit b0d0d915 has simply replaced BKL locking with lock_sock/release_sock. Unlike now, BKL got unlocked while sleeping, so a blocking recvmsg did not block a concurrent sendmsg. Only keep the socket locked while actually working with the socket data and release it prior to calling skb_recv_datagram(). Signed-off-by:
Jiri Bohac <jbohac@suse.cz> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Mathias Krause authored
[ Upstream commit a5f6fc28 ] pptp_getname() only partially initializes the stack variable sa, particularly only fills the pptp part of the sa_addr union. The code thereby discloses 16 bytes of kernel stack memory via getsockname(). Fix this by memset(0)'ing the union before. Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
-
Martin Hauke authored
[ Upstream commit bb2bdeb8 ] Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e) Signed-off-by:
Martin Hauke <mardnh@gmx.de> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit 8c2dd544 ] In case of any failure ieee802154fake_probe() just calls unregister_netdev(). But it does not look safe to unregister netdevice before it was registered. The patch implements straightforward resource deallocation in case of failure in ieee802154fake_probe(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Panu Matilainen authored
[ Upstream commit 49dd18ba ] Trying to add an unreachable route incorrectly returns -ESRCH if if custom FIB rules are present: [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4 RTNETLINK answers: Network is unreachable [root@localhost ~]# ip rule add to 55.66.77.88 table 200 [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4 RTNETLINK answers: No such process [root@localhost ~]# Commit 83886b6b ("[NET]: Change "not found" return value for rule lookup") changed fib_rules_lookup() to use -ESRCH as a "not found" code internally, but for user space it should be translated into -ENETUNREACH. Handle the translation centrally in ipv4-specific fib_lookup(), leaving the DECnet case alone. On a related note, commit b7a71b51 ("ipv4: removed redundant conditional") removed a similar translation from ip_route_input_slow() prematurely AIUI. Fixes: b7a71b51 ("ipv4: removed redundant conditional") Signed-off-by:
Panu Matilainen <pmatilai@redhat.com> Signed-off-by:
-
Vincent BENAYOUN authored
[ Upstream commit 84bc8868 ] There could be a signed overflow in the following code. The expression, (32-logmask) is comprised between 0 and 31 included. It may be equal to 31. In such a case the left shift will produce a signed integer overflow. According to the C99 Standard, this is an undefined behavior. A simple fix is to replace the signed int 1 with the unsigned int 1U. Signed-off-by:
Vincent BENAYOUN <vincent.benayoun@trust-in-soft.com> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 5a2b59d3 ] We are reading the memory location, so we have to have a memory constraint in there purely for the sake of showing the data flow to the compiler. Reported-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
- 21 Nov, 2014 1 commit
-
-
Takashi Iwai authored
commit 7939831e upstream. We've observed the missing pvpanic call at panic, and it turned out that this was blocked by the broken notifier of drm_fb_helper, where scheduling may be called during switching to the fb console. It's fairly difficult to fix the drm_fb problem and a quick fix isn't foreseen, a simpler solution for the missing pvpanic call would be just to call this earlier. In order to assure that, this patch sets a higher priority to pvpanic notifier_block. Once when the issue of drm_fb is resolved, we can remove this priority again. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
- 19 Nov, 2014 10 commits
-
-
Sergei Antonov authored
commit 97a62eae upstream. hfsplus_readdir() incorrectly returned DT_REG for symbolic links and special files. Return DT_REG, DT_LNK, DT_FIFO, DT_CHR, DT_BLK, DT_SOCK, or DT_UNKNOWN according to mode field in catalog record. Programs relying on information from readdir will now work correctly with HFS+. Signed-off-by:
Sergei Antonov <saproj@gmail.com> Cc: Anton Altaparmakov <aia21@cam.ac.uk> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Hin-Tak Leung <htl10@users.sourceforge.net> Signed-off-by:
-
Sougata Santra authored
commit d7bdb996 upstream. Concurrent access to alloc_blocks in hfsplus_inode_info() is protected by extents_lock mutex. This patch fixes two instances where alloc_blocks modification was not protected with this lock. This fixes possible allocation bitmap corruption in race conditions while extending and truncating files. [akpm@linux-foundation.org: take extents_lock before taking a copy of ->alloc_blocks] [akpm@linux-foundation.org: remove now-unused label `out'] Signed-off-by:
Sougata Santra <sougata@tuxera.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Cc: Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Vyacheslav Dubeyko authored
commit bd2c0035 upstream. Current implementation of HFS+ driver has small issue with remount option. Namely, for example, you are unable to remount from RO mode into RW mode by means of command "mount -o remount,rw /dev/loop0 /mnt/hfsplus". Trying to execute sequence of commands results in an error message: mount /dev/loop0 /mnt/hfsplus mount -o remount,ro /dev/loop0 /mnt/hfsplus mount -o remount,rw /dev/loop0 /mnt/hfsplus mount: you must specify the filesystem type mount -t hfsplus -o remount,rw /dev/loop0 /mnt/hfsplus mount: /mnt/hfsplus not mounted or bad option The reason of such issue is failure of mount syscall: mount("/dev/loop0", "/mnt/hfsplus", 0x2282a60, MS_MGC_VAL|MS_REMOUNT, NULL) = -1 EINVAL (Invalid argument) Namely, hfsplus_parse_options_remount() method receives empty "input" argument and return false in such case. As a result, hfsplus_remount() returns -EINVAL error code. This patch fixes the issue by means of return true for the case of empty "input" argument in hfsplus_parse_options_remount() method. Signed-off-by:
Vyacheslav Dubeyko <slava@dubeyko.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by:
-
Dan Carpenter authored
commit 59d42cd4 upstream. We fixed the call to request_mem_region() in commit 3354f73b ("drivers/vlynq/vlynq.c: fix resource size off by 1 error"). But we need to fix the call the release_mem_region() as well. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Florian Fainelli <florian@openwrt.org> Signed-off-by:
-
Martyn Welch authored
commit a2a720e1 upstream. The ca91cx42 and tsi148 VME bridges use the width of reads and writes on the PCI bus in part to control the width of the cycles on the VME bus. It is important that we can control the width of cycles on the VME bus as some VME hardware requires cycles of a specific width. The memcpy_toio() and memcpy_fromio() functions do not provide sufficient control, so instead loop using ioread functions. Reported-by:
Michael Kenney <mfkenney@gmail.com> Signed-off-by:
Martyn Welch <martyn.welch@ge.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Joe Schultz authored
commit 098ced8f upstream. This patch corrects a typo where "vme_base" was used instead of "*vme_base". The typo resulted in an incorrect value being returned to userspace (via vme_user). It also removes the following compile warning on some platforms: warning: cast from pointer to integer of different size [asierra: commit title/log rewording] Signed-off-by:
Joe Schultz <jschultz@xes-inc.com> Signed-off-by:
Aaron Sierra <asierra@xes-inc.com> Signed-off-by:
-
Joe Schultz authored
commit 226572b1 upstream. Previously, tsi148_master_set() assumed the address contained in its PCI bus resource represented the actual PCI bus address. This is a fine assumption on some platforms. However, on platforms that don't use a 1:1 (CPU:PCI) mapping this results in the tsi148 driver configuring an invalid master window translation. This patch updates the vme_tsi148 driver to first convert the address contained in the PCI bus resource into a PCI bus address before using it. [asierra: account for pcibios_resource_to_bus() prototype change] Signed-off-by:
-
Ezequiel Garcia authored
commit feb58142 upstream. This Multi-IO card has one serial 16550-like and one parallel port connector. Here's the lspci output, after this commit is applied: 03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550]) Subsystem: Device 4348:5053 Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Interrupt: pin A routed to IRQ 21 Region 0: I/O ports at cf00 [size=8] Region 1: I/O ports at ce00 [size=8] Kernel driver in use: parport_serial Kernel modules: 8250_pci, parport_serial This commit adds an entry with the device ID to the blacklist declared in 8250_pci to prevent the driver from taking ownership. Also, and as was done for the 2S/1P variant, add a quirk to skip autodetection and set the correct type to 16550A clone. Proper entries are added to parport_serial, to support the device parallel and serial ports. Cc: Gianluca Anzolin <gianluca@sottospazio.it> Cc: Alan Cox <alan@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Arnd Bergmann authored
commit 58409f9d upstream. commit dabd1468 "PCMCIA: sa1111: remove duplicated initializers" incorrectly moved some code into the pcmcia_jornada720_init, causing a few build errors, and for unknown reasons, the driver lacks an inclusion of <linux/io.h>, so we get the build errors, and more: sa1111_jornada720.c: In function 'pcmcia_jornada720_init': sa1111_jornada720.c:101:3: error: implicit declaration of function 'IOMEM' [-Werror=implicit-function-declaration] GRER |= 0x00000002; ^ sa1111_jornada720.c:104:3: warning: passing argument 1 of 'sa1111_set_io_dir' from incompatible pointer type [enabled by default] sa1111_set_io_dir(dev, pin, 0, 0); ^ This patch uses the SA1111_DEV() to convert the dev pointer to the correct type before passing it and adds the missing include. Signed-off-by:
-
Arnd Bergmann authored
commit f1674f21 upstream. The lubbock platform uses the sa1111 companion chip with a pxa250 CPU, which means it requires both the PCMCIA_SA1111 and the PCMCIA_PXA2XX code to be built into the kernel. Unfortunately, the Makefile and Kconfig don't agree on how this is accomplished, leading to a situation where you get this link error when building a lubbock kernel with PCMCIA_SA1111 enabled but PCMCIA_PXA2XX disabled: ERROR: "pxa2xx_configure_sockets" [drivers/pcmcia/sa1111_cs.ko] undefined! ERROR: "pxa2xx_drv_pcmcia_ops" [drivers/pcmcia/sa1111_cs.ko] undefined! ERROR: "pxa2xx_drv_pcmcia_add_one" [drivers/pcmcia/sa1111_cs.ko] undefined! This patch changes the Kconfig code to disallow that particular configuration. Signed-off-by:
-
