--- /dev/null
+From e1f8859ee265fc89bd21b4dca79e8e983a044892 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 26 Jun 2014 13:43:02 +0200
+Subject: crypto: ux500 - make interrupt mode plausible
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit e1f8859ee265fc89bd21b4dca79e8e983a044892 upstream.
+
+The interrupt handler in the ux500 crypto driver has an obviously
+incorrect way to access the data buffer, which for a while has
+caused this build warning:
+
+../ux500/cryp/cryp_core.c: In function 'cryp_interrupt_handler':
+../ux500/cryp/cryp_core.c:234:5: warning: passing argument 1 of '__fswab32' makes integer from pointer without a cast [enabled by default]
+ writel_relaxed(ctx->indata,
+ ^
+In file included from ../include/linux/swab.h:4:0,
+ from ../include/uapi/linux/byteorder/big_endian.h:12,
+ from ../include/linux/byteorder/big_endian.h:4,
+ from ../arch/arm/include/uapi/asm/byteorder.h:19,
+ from ../include/asm-generic/bitops/le.h:5,
+ from ../arch/arm/include/asm/bitops.h:340,
+ from ../include/linux/bitops.h:33,
+ from ../include/linux/kernel.h:10,
+ from ../include/linux/clk.h:16,
+ from ../drivers/crypto/ux500/cryp/cryp_core.c:12:
+../include/uapi/linux/swab.h:57:119: note: expected '__u32' but argument is of type 'const u8 *'
+ static inline __attribute_const__ __u32 __fswab32(__u32 val)
+
+There are at least two, possibly three problems here:
+a) when writing into the FIFO, we copy the pointer rather than the
+ actual data we want to give to the hardware
+b) the data pointer is an array of 8-bit values, while the FIFO
+ is 32-bit wide, so both the read and write access fail to do
+ a proper type conversion
+c) This seems incorrect for big-endian kernels, on which we need to
+ byte-swap any register access, but not normally FIFO accesses,
+ at least the DMA case doesn't do it either.
+
+This converts the bogus loop to use the same readsl/writesl pair
+that we use for the two other modes (DMA and polling). This is
+more efficient and consistent, and probably correct for endianess.
+
+The bug has existed since the driver was first merged, and was
+probably never detected because nobody tried to use interrupt mode.
+It might make sense to backport this fix to stable kernels, depending
+on how the crypto maintainers feel about that.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Cc: linux-crypto@vger.kernel.org
+Cc: Fabio Baltieri <fabio.baltieri@linaro.org>
+Cc: Linus Walleij <linus.walleij@linaro.org>
+Cc: Herbert Xu <herbert@gondor.apana.org.au>
+Cc: "David S. Miller" <davem@davemloft.net>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/ux500/cryp/cryp_core.c | 25 ++++++++++++-------------
+ 1 file changed, 12 insertions(+), 13 deletions(-)
+
+--- a/drivers/crypto/ux500/cryp/cryp_core.c
++++ b/drivers/crypto/ux500/cryp/cryp_core.c
+@@ -190,7 +190,7 @@ static void add_session_id(struct cryp_c
+ static irqreturn_t cryp_interrupt_handler(int irq, void *param)
+ {
+ struct cryp_ctx *ctx;
+- int i;
++ int count;
+ struct cryp_device_data *device_data;
+
+ if (param == NULL) {
+@@ -215,12 +215,11 @@ static irqreturn_t cryp_interrupt_handle
+ if (cryp_pending_irq_src(device_data,
+ CRYP_IRQ_SRC_OUTPUT_FIFO)) {
+ if (ctx->outlen / ctx->blocksize > 0) {
+- for (i = 0; i < ctx->blocksize / 4; i++) {
+- *(ctx->outdata) = readl_relaxed(
+- &device_data->base->dout);
+- ctx->outdata += 4;
+- ctx->outlen -= 4;
+- }
++ count = ctx->blocksize / 4;
++
++ readsl(&device_data->base->dout, ctx->outdata, count);
++ ctx->outdata += count;
++ ctx->outlen -= count;
+
+ if (ctx->outlen == 0) {
+ cryp_disable_irq_src(device_data,
+@@ -230,12 +229,12 @@ static irqreturn_t cryp_interrupt_handle
+ } else if (cryp_pending_irq_src(device_data,
+ CRYP_IRQ_SRC_INPUT_FIFO)) {
+ if (ctx->datalen / ctx->blocksize > 0) {
+- for (i = 0 ; i < ctx->blocksize / 4; i++) {
+- writel_relaxed(ctx->indata,
+- &device_data->base->din);
+- ctx->indata += 4;
+- ctx->datalen -= 4;
+- }
++ count = ctx->blocksize / 4;
++
++ writesl(&device_data->base->din, ctx->indata, count);
++
++ ctx->indata += count;
++ ctx->datalen -= count;
+
+ if (ctx->datalen == 0)
+ cryp_disable_irq_src(device_data,
--- /dev/null
+From 28772ac8711e4d7268c06e765887dd8cb6924f98 Mon Sep 17 00:00:00 2001
+From: Wolfram Sang <wsa@the-dreams.de>
+Date: Mon, 21 Jul 2014 11:42:03 +0200
+Subject: drivers/i2c/busses: use correct type for dma_map/unmap
+
+From: Wolfram Sang <wsa@the-dreams.de>
+
+commit 28772ac8711e4d7268c06e765887dd8cb6924f98 upstream.
+
+dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'.
+
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/busses/i2c-at91.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/i2c/busses/i2c-at91.c
++++ b/drivers/i2c/busses/i2c-at91.c
+@@ -211,7 +211,7 @@ static void at91_twi_write_data_dma_call
+ struct at91_twi_dev *dev = (struct at91_twi_dev *)data;
+
+ dma_unmap_single(dev->dev, sg_dma_address(&dev->dma.sg),
+- dev->buf_len, DMA_MEM_TO_DEV);
++ dev->buf_len, DMA_TO_DEVICE);
+
+ at91_twi_write(dev, AT91_TWI_CR, AT91_TWI_STOP);
+ }
+@@ -290,7 +290,7 @@ static void at91_twi_read_data_dma_callb
+ struct at91_twi_dev *dev = (struct at91_twi_dev *)data;
+
+ dma_unmap_single(dev->dev, sg_dma_address(&dev->dma.sg),
+- dev->buf_len, DMA_DEV_TO_MEM);
++ dev->buf_len, DMA_FROM_DEVICE);
+
+ /* The last two bytes have to be read without using dma */
+ dev->buf += dev->buf_len - 2;
--- /dev/null
+From 86f0afd463215fc3e58020493482faa4ac3a4d69 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o <tytso@mit.edu>
+Date: Wed, 30 Jul 2014 22:17:17 -0400
+Subject: ext4: fix ext4_discard_allocated_blocks() if we can't allocate the pa struct
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+commit 86f0afd463215fc3e58020493482faa4ac3a4d69 upstream.
+
+If there is a failure while allocating the preallocation structure, a
+number of blocks can end up getting marked in the in-memory buddy
+bitmap, and then not getting released. This can result in the
+following corruption getting reported by the kernel:
+
+EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126,
+12793 clusters in bitmap, 12729 in gd
+
+In that case, we need to release the blocks using mb_free_blocks().
+
+Tested: fs smoke test; also demonstrated that with injected errors,
+ the file system is no longer getting corrupted
+
+Google-Bug-Id: 16657874
+
+Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ext4/mballoc.c | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/fs/ext4/mballoc.c
++++ b/fs/ext4/mballoc.c
+@@ -3177,8 +3177,27 @@ static void ext4_mb_collect_stats(struct
+ static void ext4_discard_allocated_blocks(struct ext4_allocation_context *ac)
+ {
+ struct ext4_prealloc_space *pa = ac->ac_pa;
++ struct ext4_buddy e4b;
++ int err;
+
+- if (pa && pa->pa_type == MB_INODE_PA)
++ if (pa == NULL) {
++ err = ext4_mb_load_buddy(ac->ac_sb, ac->ac_f_ex.fe_group, &e4b);
++ if (err) {
++ /*
++ * This should never happen since we pin the
++ * pages in the ext4_allocation_context so
++ * ext4_mb_load_buddy() should never fail.
++ */
++ WARN(1, "mb_load_buddy failed (%d)", err);
++ return;
++ }
++ ext4_lock_group(ac->ac_sb, ac->ac_f_ex.fe_group);
++ mb_free_blocks(ac->ac_inode, &e4b, ac->ac_f_ex.fe_start,
++ ac->ac_f_ex.fe_len);
++ ext4_unlock_group(ac->ac_sb, ac->ac_f_ex.fe_group);
++ return;
++ }
++ if (pa->pa_type == MB_INODE_PA)
+ pa->pa_free += ac->ac_b_ex.fe_len;
+ }
+
--- /dev/null
+From 0f6c0a740b7d3e1f3697395922d674000f83d060 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Wed, 30 Jul 2014 18:07:24 +0200
+Subject: KVM: x86: always exit on EOIs for interrupts listed in the IOAPIC redir table
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 0f6c0a740b7d3e1f3697395922d674000f83d060 upstream.
+
+Currently, the EOI exit bitmap (used for APICv) does not include
+interrupts that are masked. However, this can cause a bug that manifests
+as an interrupt storm inside the guest. Alex Williamson reported the
+bug and is the one who really debugged this; I only wrote the patch. :)
+
+The scenario involves a multi-function PCI device with OHCI and EHCI
+USB functions and an audio function, all assigned to the guest, where
+both USB functions use legacy INTx interrupts.
+
+As soon as the guest boots, interrupts for these devices turn into an
+interrupt storm in the guest; the host does not see the interrupt storm.
+Basically the EOI path does not work, and the guest continues to see the
+interrupt over and over, even after it attempts to mask it at the APIC.
+The bug is only visible with older kernels (RHEL6.5, based on 2.6.32
+with not many changes in the area of APIC/IOAPIC handling).
+
+Alex then tried forcing bit 59 (corresponding to the USB functions' IRQ)
+on in the eoi_exit_bitmap and TMR, and things then work. What happens
+is that VFIO asserts IRQ11, then KVM recomputes the EOI exit bitmap.
+It does not have set bit 59 because the RTE was masked, so the IOAPIC
+never sees the EOI and the interrupt continues to fire in the guest.
+
+My guess was that the guest is masking the interrupt in the redirection
+table in the interrupt routine, i.e. while the interrupt is set in a
+LAPIC's ISR, The simplest fix is to ignore the masking state, we would
+rather have an unnecessary exit rather than a missed IRQ ACK and anyway
+IOAPIC interrupts are not as performance-sensitive as for example MSIs.
+Alex tested this patch and it fixed his bug.
+
+[Thanks to Alex for his precise description of the problem
+ and initial debugging effort. A lot of the text above is
+ based on emails exchanged with him.]
+
+Reported-by: Alex Williamson <alex.williamson@redhat.com>
+Tested-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ virt/kvm/ioapic.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/virt/kvm/ioapic.c
++++ b/virt/kvm/ioapic.c
+@@ -203,10 +203,9 @@ void kvm_ioapic_scan_entry(struct kvm_vc
+ spin_lock(&ioapic->lock);
+ for (index = 0; index < IOAPIC_NUM_PINS; index++) {
+ e = &ioapic->redirtbl[index];
+- if (!e->fields.mask &&
+- (e->fields.trig_mode == IOAPIC_LEVEL_TRIG ||
+- kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC,
+- index) || index == RTC_GSI)) {
++ if (e->fields.trig_mode == IOAPIC_LEVEL_TRIG ||
++ kvm_irq_has_notifier(ioapic->kvm, KVM_IRQCHIP_IOAPIC, index) ||
++ index == RTC_GSI) {
+ if (kvm_apic_match_dest(vcpu, NULL, 0,
+ e->fields.dest_id, e->fields.dest_mode)) {
+ __set_bit(e->fields.vector,
--- /dev/null
+From 9e8919ae793f4edfaa29694a70f71a515ae9942a Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@cs.technion.ac.il>
+Date: Sun, 15 Jun 2014 16:12:59 +0300
+Subject: KVM: x86: Inter-privilege level ret emulation is not implemeneted
+
+From: Nadav Amit <namit@cs.technion.ac.il>
+
+commit 9e8919ae793f4edfaa29694a70f71a515ae9942a upstream.
+
+Return unhandlable error on inter-privilege level ret instruction. This is
+since the current emulation does not check the privilege level correctly when
+loading the CS, and does not pop RSP/SS as needed.
+
+Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/emulate.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/x86/kvm/emulate.c
++++ b/arch/x86/kvm/emulate.c
+@@ -2209,6 +2209,7 @@ static int em_ret_far(struct x86_emulate
+ {
+ int rc;
+ unsigned long cs;
++ int cpl = ctxt->ops->cpl(ctxt);
+
+ rc = emulate_pop(ctxt, &ctxt->_eip, ctxt->op_bytes);
+ if (rc != X86EMUL_CONTINUE)
+@@ -2218,6 +2219,9 @@ static int em_ret_far(struct x86_emulate
+ rc = emulate_pop(ctxt, &cs, ctxt->op_bytes);
+ if (rc != X86EMUL_CONTINUE)
+ return rc;
++ /* Outer-privilege level return is not implemented */
++ if (ctxt->mode >= X86EMUL_MODE_PROT16 && (cs & 3) > cpl)
++ return X86EMUL_UNHANDLEABLE;
+ rc = load_segment_descriptor(ctxt, (u16)cs, VCPU_SREG_CS);
+ return rc;
+ }
--- /dev/null
+From ae84db9661cafc63d179e1d985a2c5b841ff0ac4 Mon Sep 17 00:00:00 2001
+From: Peter Hurley <peter@hurleysoftware.com>
+Date: Wed, 9 Jul 2014 09:21:14 -0400
+Subject: serial: core: Preserve termios c_cflag for console resume
+
+From: Peter Hurley <peter@hurleysoftware.com>
+
+commit ae84db9661cafc63d179e1d985a2c5b841ff0ac4 upstream.
+
+When a tty is opened for the serial console, the termios c_cflag
+settings are inherited from the console line settings.
+However, if the tty is subsequently closed, the termios settings
+are lost. This results in a garbled console if the console is later
+suspended and resumed.
+
+Preserve the termios c_cflag for the serial console when the tty
+is shutdown; this reflects the most recent line settings.
+
+Fixes: Bugzilla #69751, 'serial console does not wake from S3'
+Reported-by: Valerio Vanni <valerio.vanni@inwind.it>
+Acked-by: Alan Cox <alan@linux.intel.com>
+Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/serial_core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -241,6 +241,9 @@ static void uart_shutdown(struct tty_str
+ /*
+ * Turn off DTR and RTS early.
+ */
++ if (uart_console(uport) && tty)
++ uport->cons->cflag = tty->termios.c_cflag;
++
+ if (!tty || (tty->termios.c_cflag & HUPCL))
+ uart_clear_mctrl(uport, TIOCM_DTR | TIOCM_RTS);
+
hwmon-lm85-fix-various-errors-on-attribute-writes.patch
hwmon-ads1015-fix-out-of-bounds-array-access.patch
hwmon-dme1737-prevent-overflow-problem-when-writing-large-limits.patch
+drivers-i2c-busses-use-correct-type-for-dma_map-unmap.patch
+ext4-fix-ext4_discard_allocated_blocks-if-we-can-t-allocate-the-pa-struct.patch
+serial-core-preserve-termios-c_cflag-for-console-resume.patch
+crypto-ux500-make-interrupt-mode-plausible.patch
+kvm-x86-inter-privilege-level-ret-emulation-is-not-implemeneted.patch
+kvm-x86-always-exit-on-eois-for-interrupts-listed-in-the-ioapic-redir-table.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
