- 10 Jun, 2016 40 commits
-
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The PSL interrupt cannot be multiplexed in a guest, as it is not supported by the hypervisor. So an interrupt will be allocated for it for each context. It will still be the first interrupt found in the first interrupt range, but is treated almost like any other AFU interrupt when creating/deleting the context. Only the handler is different. Rework the code so that the range 0 is treated like the other ranges. Co-authored-by:
Christophe Lombard <clombard@linux.vnet.ibm.com> Signed-off-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Signed-off-by:
Manoj Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Ian Munsie <imunsie@au1.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 73d55c3b) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The context parameter when calling cxl_irq() should be strongly typed. Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 A few functions are mostly common between bare-metal and guest and just need minor tuning. To avoid crowding the backend API, introduce a few 'if' based on the CPU being in HV mode. Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Rename a few functions, changing the 'cxl_' prefix to either 'cxl_pci_' or 'cxl_native_', to make clear that the implementation is bare-metal specific. Those functions will have an equivalent implementation for a guest in a later patch. Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 The backend API (in cxl.h) lists some low-level functions whose implementation is different on bare-metal and in a guest. Each environment implements its own functions, and the common code uses them through function pointers, defined in cxl_backend_ops Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 CXL kernel API was defining the process problem state area during context initialization, making it possible to map the problem state area before attaching the context. This won't work on a powerVM guest. So force the logical behavior, like in userspace: attach first, then map the problem state area. Remove calls to cxl_assign_psn_space during init. The function is already called on the attach paths. Co-authored-by:
-
Frederic Barrat authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Move a few functions around to better separate code specific to bare-metal environment from code which will be commonly used between guest and bare-metal. Code specific to bare-metal is meant to be in native.c or pci.c only. It's basically anything which touches the card p1 registers, some p2 registers not needed from a guest and the PCI interface. Co-authored-by:
-
Christophe Lombard authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Move around some functions which will be accessed from the bare-metal and guest environments. Code in native.c and pci.c is meant to be bare-metal specific. Other files contain code which may be shared with guests. Co-authored-by:
-
Geliang Tang authored
BugLink: http://bugs.launchpad.net/bugs/1588468 Use kobj_to_dev() instead of open-coding it. Signed-off-by:
Geliang Tang <geliangtang@163.com> Reviewed-by:
Andrew Donnellan <andrew.donnellan@au1.ibm.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 85016ff3) Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1588449 Driver private request types should not get the artifical cap for the FS requests. This is important to use the full device capabilities for internal command or NVMe pass through commands. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reported-by:
Jeff Lien <Jeff.Lien@hgst.com> Tested-by:
Keith Busch <keith.busch@intel.com> Updated by me to use an explicit check for the one command type that does support extended checking, instead of relying on the ordering of the enum command values - as suggested by Keith. Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit f2101842) Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1588449 The block layer uses an unsigned short for max_segments. The way we calculate the value for NVMe tends to generate very large 32-bit values, which after integer truncation may lead to a zero value instead of the desired outcome. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1588449 Factor out a helper to set all the device specific queue limits and apply them to the admin queue in addition to the I/O queues. Without this the command size on the admin queue is arbitrarily low, and the missing other limitations are just minefields waiting for victims. Signed-off-by:
-
Ganapatrao Kulkarni authored
BugLink: http://bugs.launchpad.net/bugs/1589704 The erratum fixes the hang of ITS SYNC command by avoiding inter node io and collections/cpu mapping on thunderx dual-socket platform. This fix is only applicable for Cavium's ThunderX dual-socket platform. Reviewed-by:
Robert Richter <rrichter@cavium.com> Signed-off-by:
Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com> Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> (back-ported from commit fbf8f40e) Signed-off-by:
dann frazier <dann.frazier@canonical.com> [ dannf: Adjusted for offset changes; dropped Documentation/ updates for file that didn't exist in v4.4 ] Acked-by:
-
dann frazier authored
Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1588945Signed-off-by:
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit c9c6837d upstream. gcc-6 started warning by default about variables that are not used anywhere and that are marked 'const', generating many false positives in an allmodconfig build, e.g.: arch/arm/mach-davinci/board-da830-evm.c:282:20: warning: 'da830_evm_emif25_pins' defined but not used [-Wunused-const-variable=] arch/arm/plat-omap/dmtimer.c:958:34: warning: 'omap_timer_match' defined but not used [-Wunused-const-variable=] drivers/bluetooth/hci_bcm.c:625:39: warning: 'acpi_bcm_default_gpios' defined but not used [-Wunused-const-variable=] drivers/char/hw_random/omap-rng.c:92:18: warning: 'reg_map_omap4' defined but not used [-Wunused-const-variable=] drivers/devfreq/exynos/exynos5_bus.c:381:32: warning: 'exynos5_busfreq_int_pm' defined but not used [-Wunused-const-variable=] drivers/dma/mv_xor.c:1139:34: warning: 'mv_xor_dt_ids' defined but not used [-Wunused-const-variable=] This is similar to the existing -Wunused-but-set-variable warning that was added in an earlier release and that we disable by default now and only enable when W=1 is set, so it makes sense to do the same here. Once we have eliminated the majority of the warnings for both, we can put them back into the default list. We probably want this in backport kernels as well, to allow building them with gcc-6 without introducing extra warnings. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Olof Johansson <olof@lixom.net> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Michal Marek <mmarek@suse.com> Signed-off-by:
-
Johannes Thumshirn authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 305c2e71 upstream. Now that we've done a more comprehensive fix with the intermediate target state we can remove the previous hack introduced with commit 90a88d6e ("scsi: fix soft lockup in scsi_remove_target() on module removal"). Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Johannes Thumshirn authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit f05795d3 upstream. Add intermediate STARGET_REMOVE state to scsi_target_state to avoid running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE state is only valid in the path from scsi_remove_target() to scsi_target_destroy() indicating this target is going to be removed. This re-fixes the problem introduced in commits bc3f02a7 ("[SCSI] scsi_remove_target: fix softlockup regression on hot remove") and 40998193 ("scsi: restart list search after unlock in scsi_remove_target") in a more comprehensive way. [mkp: Included James' fix for scsi_target_destroy()] Signed-off-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Tested-by:
James Bottomley <jejb@linux.vnet.ibm.com> Signed-off-by:
-
Mikulas Patocka authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 037369b8 upstream. The HPFS filesystem used generic_show_options to produce string that is displayed in /proc/mounts. However, there is a problem that the options may disappear after remount. If we mount the filesystem with option1 and then remount it with option2, /proc/mounts should show both option1 and option2, however it only shows option2 because the whole option string is replaced with replace_mount_options in hpfs_remount_fs. To fix this bug, implement the hpfs_show_options function that prints options that are currently selected. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Mikulas Patocka authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 44d51706 upstream. Commit ce657611 ("hpfs: kstrdup() out of memory handling") checks if the kstrdup function returns NULL due to out-of-memory condition. However, if we are remounting a filesystem with no change to filesystem-specific options, the parameter data is NULL. In this case, kstrdup returns NULL (because it was passed NULL parameter), although no out of memory condition exists. The mount syscall then fails with ENOMEM. This patch fixes the bug. We fail with ENOMEM only if data is non-NULL. The patch also changes the call to replace_mount_options - if we didn't pass any filesystem-specific options, we don't call replace_mount_options (thus we don't erase existing reported options). Fixes: ce657611 ("hpfs: kstrdup() out of memory handling") Signed-off-by:
-
Richard Weinberger authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 1900149c upstream. Ezequiel reported that he's facing UBI going into read-only mode after power cut. It turned out that this behavior happens only when updating a static volume is interrupted and Fastmap is used. A possible trace can look like: ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4 Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012 0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841 ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6 ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0 Call Trace: [<ffffffff8140d841>] dump_stack+0x63/0x82 [<ffffffffa003abf6>] ubi_eba_read_leb+0x486/0x4a0 [ubi] [<ffffffffa00453b3>] ubi_check_volume+0x83/0xf0 [ubi] [<ffffffffa0039d97>] ubi_open_volume+0x177/0x350 [ubi] [<ffffffffa00375d8>] vol_cdev_open+0x58/0xb0 [ubi] [<ffffffff8124b08e>] chrdev_open+0xae/0x1d0 [<ffffffff81243bcf>] do_dentry_open+0x1ff/0x300 [<ffffffff8124afe0>] ? cdev_put+0x30/0x30 [<ffffffff81244d36>] vfs_open+0x56/0x60 [<ffffffff812545f4>] path_openat+0x4f4/0x1190 [<ffffffff81256621>] do_filp_open+0x91/0x100 [<ffffffff81263547>] ? __alloc_fd+0xc7/0x190 [<ffffffff812450df>] do_sys_open+0x13f/0x210 [<ffffffff812451ce>] SyS_open+0x1e/0x20 [<ffffffff81a99e32>] entry_SYSCALL_64_fastpath+0x1a/0xa4 UBI checks static volumes for data consistency and reads the whole volume upon first open. If the volume is found erroneous users of UBI cannot read from it, but another volume update is possible to fix it. The check is performed by running ubi_eba_read_leb() on every allocated LEB of the volume. For static volumes ubi_eba_read_leb() computes the checksum of all data stored in a LEB. To verify the computed checksum it has to read the LEB's volume header which stores the original checksum. If the volume header is not found UBI treats this as fatal internal error and switches to RO mode. If the UBI device was attached via a full scan the assumption is correct, the volume header has to be present as it had to be there while scanning to get known as mapped. If the attach operation happened via Fastmap the assumption is no longer correct. When attaching via Fastmap UBI learns the mapping table from Fastmap's snapshot of the system state and not via a full scan. It can happen that a LEB got unmapped after a Fastmap was written to the flash. Then UBI can learn the LEB still as mapped and accessing it returns only 0xFF bytes. As UBI is not a FTL it is allowed to have mappings to empty PEBs, it assumes that the layer above takes care of LEB accounting and referencing. UBIFS does so using the LEB property tree (LPT). For static volumes UBI blindly assumes that all LEBs are present and therefore special actions have to be taken. The described situation can happen when updating a static volume is interrupted, either by a user or a power cut. The volume update code first unmaps all LEBs of a volume and then writes LEB by LEB. If the sequence of operations is interrupted UBI detects this either by the absence of LEBs, no volume header present at scan time, or corrupted payload, detected via checksum. In the Fastmap case the former method won't trigger as no scan happened and UBI automatically thinks all LEBs are present. Only by reading data from a LEB it detects that the volume header is missing and incorrectly treats this as fatal error. To deal with the situation ubi_eba_read_leb() from now on checks whether we attached via Fastmap and handles the absence of a volume header like a data corruption error. This way interrupted static volume updates will correctly get detected also when Fastmap is used. Reported-by:
Ezequiel Garcia <ezequiel@vanguardiasur.com.ar> Tested-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
James Hogan authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit ca9eb49a upstream. The generic copy_siginfo() is currently defined in asm-generic/siginfo.h, after including uapi/asm-generic/siginfo.h which defines the generic struct siginfo. However this makes it awkward for an architecture to use it if it has to define its own struct siginfo (e.g. MIPS and potentially IA64), since it means that asm-generic/siginfo.h can only be included after defining the arch-specific siginfo, which may be problematic if the arch-specific definition needs definitions from uapi/asm-generic/siginfo.h. It is possible to work around this by first including uapi/asm-generic/siginfo.h to get the constants before defining the arch-specific siginfo, and include asm-generic/siginfo.h after. However uapi headers can't be included by other uapi headers, so that first include has to be in an ifdef __kernel__, with the non __kernel__ case including the non-UAPI header instead. Instead of that mess, move the generic copy_siginfo() definition into linux/signal.h, which allows an arch-specific uapi/asm/siginfo.h to include asm-generic/siginfo.h and define the arch-specific siginfo, and for the generic copy_siginfo() to see that arch-specific definition. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Petr Malat <oss@malat.biz> Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Christopher Ferris <cferris@google.com> Cc: linux-arch@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: linux-ia64@vger.kernel.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/12478/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Andreas Noever authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 2ffa9a5d upstream. If tb_drom_read() fails, sw->drom is freed but not set to NULL. sw->drom is then freed again in the error path of tb_switch_alloc(). The bug can be triggered by unplugging a thunderbolt device shortly after it is detected by the thunderbolt driver. Clear sw->drom if tb_drom_read() fails. [bhelgaas: add Fixes:, stable versions of interest] Fixes: 343fcb8c ("thunderbolt: Fix nontrivial endpoint devices.") Signed-off-by:
Andreas Noever <andreas.noever@gmail.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Bart Van Assche authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 54f5c9c5 upstream. Avoid that the following BUG() is triggered against a debug kernel: kernel BUG at include/linux/scatterlist.h:92! RIP: 0010:[<ffffffffa0467199>] [<ffffffffa0467199>] srp_map_idb+0x199/0x1a0 [ib_srp] Call Trace: [<ffffffffa04685fa>] srp_map_data+0x84a/0x890 [ib_srp] [<ffffffffa0469674>] srp_queuecommand+0x1e4/0x610 [ib_srp] [<ffffffff813f5a5e>] scsi_dispatch_cmd+0x9e/0x180 [<ffffffff813f8b07>] scsi_request_fn+0x477/0x610 [<ffffffff81298ffe>] __blk_run_queue+0x2e/0x40 [<ffffffff81299070>] blk_delay_work+0x20/0x30 [<ffffffff81071f07>] process_one_work+0x197/0x480 [<ffffffff81072239>] worker_thread+0x49/0x490 [<ffffffff810787ea>] kthread+0xea/0x100 [<ffffffff8159b632>] ret_from_fork+0x22/0x40 Fixes: f7f7aab1 ("IB/srp: Convert to new registration API") Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: Sagi Grimberg <sagi@grimberg.me> Cc: Christoph Hellwig <hch@lst.de> Reviewed-by:
Max Gurtovoy <maxg@mellanox.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 86c72d1c upstream. Add the pin configuration value of this machine into the pin_quirk table to make DELL1_MIC_NO_PRESENCE apply to this machine. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 7d727869 upstream. Add support for ALC295/ALC3254. They are simply compatible with ALC225 chip. Signed-off-by:
Kailang Yang <kailang@realtek.com> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 423cd785 upstream. The headphone has noise when playing sound or switching microphone sources. It uses the same codec on XPS 13 9350, but with different subsystem ID. Applying the fixup can solve the issue. Also, changing the model name to better differentiate models. v2: Reorder by device ID. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Kailang Yang authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit dcd4f0db upstream. Support new codecs for ALC234/ALC274/ALC294. This three codecs was the same IC. But bonding is not the same. Signed-off-by:
-
Andreas Werner authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit f75564d3 upstream. The bar number is found in reg2 within the gdd. Therefore we need to change the assigment from reg1 to reg2 which is the correct location. Signed-off-by:
Andreas Werner <andreas.werner@men.de> Fixes: '3764e82e' drivers: Introduce MEN Chameleon Bus Signed-off-by:
-
Martin Sperl authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit ec36a5c6 upstream. Add missing locking to: * bcm2835_pll_divider_on * bcm2835_pll_divider_off to protect the read modify write cycle for the register access protecting both cm_reg and a2w_reg registers. Fixes: 41691b88 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by:
Martin Sperl <kernel@martin.sperl.org> Signed-off-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 54cf809b upstream. Similar to commits: 51d7d520 ("powerpc: Add smp_mb() to arch_spin_is_locked()") d86b8da0 ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers") qspinlock suffers from the fact that the _Q_LOCKED_VAL store is unordered inside the ACQUIRE of the lock. And while this is not a problem for the regular mutual exclusive critical section usage of spinlocks, it breaks creative locking like: spin_lock(A) spin_lock(B) spin_unlock_wait(B) if (!spin_is_locked(A)) do_something() do_something() In that both CPUs can end up running do_something at the same time, because our _Q_LOCKED_VAL store can drop past the spin_unlock_wait() spin_is_locked() loads (even on x86!!). To avoid making the normal case slower, add smp_mb()s to the less used spin_unlock_wait() / spin_is_locked() side of things to avoid this problem. Reported-and-tested-by:
Davidlohr Bueso <dave@stgolabs.net> Reported-by:
Giovanni Gherdovich <ggherdovich@suse.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
-
Chanwoo Choi authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit b8995f52 upstream. This patch fixes the broken serial log when changing the clock source of uart device. Before disabling the original clock source, this patch enables the new clock source to protect the clock off state for a split second. Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit c42850f1 upstream. There is a special register that shows interrupt status by source. In particular case the source can be a combination of DMA Tx, DMA Rx, and UART. Read the register and call the handlers only for sources that request an interrupt. Fixes: 6ede6dcd ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Reviewed-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 107e15fc upstream. Unlike Intel Medfield and Tangier platforms DNV uses PCI BAR0 for IO compatible resources and BAR1 for MMIO. We need latter in a way to support DMA. Introduce an additional field in the internal structure and pass PCI BAR based on device ID. Reported-by:
"Lai, Poey Seng" <poey.seng.lai@intel.com> Fixes: 6ede6dcd ("serial: 8250_mid: add support for DMA engine handling from UART MMIO") Reviewed-by:
-
David Müller authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 6f210c18 upstream. Since commit 21947ba6 ("serial: 8250_pci: replace switch-case by formula"), the 8250 driver crashes in the byt_set_termios() function with a divide error. This is caused by the fact that a baud rate of 0 (B0) is not handled properly. Fix it by falling back to B9600 in this case. Signed-off-by:
David Müller <d.mueller@elsoft.ch> Fixes: 21947ba6 ("serial: 8250_pci: replace switch-case by formula") Suggested-by:
-
Brian Bloniarz authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 0f40fbbc upstream. OpenSSH expects the (non-blocking) read() of pty master to return EAGAIN only if it has received all of the slave-side output after it has received SIGCHLD. This used to work on pre-3.12 kernels. This fix effectively forces non-blocking read() and poll() to block for parallel i/o to complete for all ttys. It also unwinds these changes: 1) f8747d4a tty: Fix pty master read() after slave closes 2) 52bce7f8 pty, n_tty: Simplify input processing on final close 3) 1a48632f pty: Fix input race when closing Inspired by analysis and patch from Marc Aurele La France <tsi@tuyoix.net> Reported-by:
Volth <openssh@volth.com> Reported-by:
Marc Aurele La France <tsi@tuyoix.net> BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=52 BugLink: https://bugzilla.mindrot.org/show_bug.cgi?id=2492Signed-off-by:
Brian Bloniarz <brian.bloniarz@gmail.com> Reviewed-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Alexandre Belloni authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 5be605ac upstream. Commit 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") actually allowed to enable hardware handshaking. Before, the CRTSCTS flags was silently ignored. As the DMA controller can't drive RTS (as explain in the commit message). Ensure that hardware flow control stays disabled when DMA is used and FIFOs are not available. Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 1cf6e8fc ("tty/serial: at91: fix RTS line management when hardware handshake is enabled") Signed-off-by:
-
Jiri Slaby authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit d175feca upstream. Dmitry reported, that the current cleanup code in n_gsm can trigger a warning: WARNING: CPU: 2 PID: 24238 at drivers/tty/n_gsm.c:2048 gsm_cleanup_mux+0x166/0x6b0() ... Call Trace: ... [<ffffffff81247ab9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:490 [<ffffffff828d0456>] gsm_cleanup_mux+0x166/0x6b0 drivers/tty/n_gsm.c:2048 [<ffffffff828d4d87>] gsmld_open+0x5b7/0x7a0 drivers/tty/n_gsm.c:2386 [<ffffffff828b9078>] tty_ldisc_open.isra.2+0x78/0xd0 drivers/tty/tty_ldisc.c:447 [<ffffffff828b973a>] tty_set_ldisc+0x1ca/0xa70 drivers/tty/tty_ldisc.c:567 [< inline >] tiocsetd drivers/tty/tty_io.c:2650 [<ffffffff828a14ea>] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2883 ... But this is a legal path when open fails to find a space in the gsm_mux array and tries to clean up. So make it a standard test instead of a warning. Reported-by:
"Dmitry Vyukov" <dvyukov@google.com> Cc: Alan Cox <alan@linux.intel.com> Link: http://lkml.kernel.org/r/CACT4Y+bHQbAB68VFi7Romcs-Z9ZW3kQRvcq+BvHH1oa5NcAdLA@mail.gmail.com Fixes: 5a640967 ("tty/n_gsm.c: fix a memory leak in gsmld_open()") Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Jiri Slaby authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 6798df4c upstream. When csw->con_startup() fails in do_register_con_driver, we return no error (i.e. 0). This was changed back in 2006 by commit 3e795de7. Before that we used to return -ENODEV. So fix the return value to be -ENODEV in that case again. Fixes: 3e795de7 ("VT binding: Add binding/unbinding support for the VT console") Signed-off-by:
"Dan Carpenter" <dan.carpenter@oracle.com> Signed-off-by:
-
Stefano Stabellini authored
BugLink: http://bugs.launchpad.net/bugs/1588945 commit 702f9260 upstream. b4ff8389 is incomplete: relies on nr_legacy_irqs() to get the number of legacy interrupts when actually nr_legacy_irqs() returns 0 after probe_8259A(). Use NR_IRQS_LEGACY instead. Signed-off-by:
Stefano Stabellini <sstabellini@kernel.org> Signed-off-by:
-
