2015-11-06 19:59:27

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 00/37] 3.14.57-stable review

This is the start of the stable review cycle for the 3.14.57 release.
There are 37 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.

Responses should be made by Sun Nov 8 19:23:35 UTC 2015.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.14.57-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-------------
Pseudo-Shortlog of commits:

Greg Kroah-Hartman <[email protected]>
Linux 3.14.57-rc1

Greg Kroah-Hartman <[email protected]>
xen: fix backport of previous kexec patch

Soeren Grunewald <[email protected]>
serial: 8250_pci: Add support for 12 port Exar boards

Soeren Grunewald <[email protected]>
serial: 8250_pci: Add support for 16 port Exar boards

Roman Gushchin <[email protected]>
md/raid5: fix locking in handle_stripe_clean_event()

Doron Tsur <[email protected]>
IB/cm: Fix rb-tree duplicate free and use-after-free

Dāvis Mosāns <[email protected]>
mvsas: Fix NULL pointer dereference in mvs_slot_task_free

NeilBrown <[email protected]>
Revert "md: allow a partially recovered device to be hot-added to an array."

Jes Sorensen <[email protected]>
md/raid10: submit_bio_wait() returns 0 on success

Jes Sorensen <[email protected]>
md/raid1: submit_bio_wait() returns 0 on success

Herbert Xu <[email protected]>
crypto: api - Only abort operations on fatal signal

Peter Zijlstra <[email protected]>
module: Fix locking in symbol_put_addr()

Cathy Avery <[email protected]>
xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

Laura Abbott <[email protected]>
xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

Mathias Nyman <[email protected]>
xhci: handle no ping response error properly

Mike Snitzer <[email protected]>
dm btree: fix leak of bufio-backed block in btree_split_beneath error path

Joe Thornber <[email protected]>
dm btree remove: fix a bug when rebalancing nodes after removal

Will Deacon <[email protected]>
Revert "ARM64: unwind: Fix PC calculation"

Ilya Dryomov <[email protected]>
rbd: prevent kernel stack blow up on rbd map

Ilya Dryomov <[email protected]>
rbd: don't leak parent_spec in rbd_dev_probe_parent()

Ronny Hegewald <[email protected]>
rbd: require stable pages if message data CRCs are enabled

Alexandre Belloni <[email protected]>
iio: mxs-lradc: Fix temperature offset

Alex Deucher <[email protected]>
drm/radeon: don't try to recreate sysfs entries on resume

Ville Syrjälä <[email protected]>
drm/i915: Restore lost DPLL register write on gen2-4

Ilia Mirkin <[email protected]>
drm/nouveau/gem: return only valid domain when there's only one

SeongJae Park <[email protected]>
spi: fix pointer-integer size mismatch warning

Lad, Prabhakar <[email protected]>
power: bq24190_charger: suppress build warning

David S. Miller <[email protected]>
sfc: Fix memcpy() with const destination compiler warning.

Jan Kara <[email protected]>
mm: make sendfile(2) killable

Paolo Bonzini <[email protected]>
x86/setup: Extend low identity map to cover whole kernel range

Charles Keepax <[email protected]>
ASoC: wm8904: Correct number of EQ registers

Vasant Hegde <[email protected]>
powerpc/rtas: Validate rtas.entry before calling enter_rtas()

Joerg Roedel <[email protected]>
iommu/amd: Don't clear DTE flags when modifying it

Luca Coelho <[email protected]>
iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series

Johannes Berg <[email protected]>
iwlwifi: mvm: fix D3 firmware PN programming

Johannes Berg <[email protected]>
iwlwifi: fix firmware filename for 3160

Johannes Berg <[email protected]>
iwlwifi: dvm: fix D3 firmware PN programming

Felix Fietkau <[email protected]>
ath9k: declare required extra tx headroom


-------------

Diffstat:

Makefile | 4 +-
arch/arm64/kernel/stacktrace.c | 6 +--
arch/powerpc/kernel/rtas.c | 3 ++
arch/x86/kernel/setup.c | 8 ++++
arch/x86/xen/enlighten.c | 6 +--
crypto/ablkcipher.c | 2 +-
crypto/algapi.c | 2 +-
crypto/api.c | 6 +--
crypto/crypto_user.c | 2 +-
drivers/block/rbd.c | 67 ++++++++++++++++------------
drivers/block/xen-blkfront.c | 3 +-
drivers/gpu/drm/i915/intel_display.c | 2 +
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++-
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 35 +++++++++------
drivers/infiniband/core/cm.c | 10 ++++-
drivers/iommu/amd_iommu.c | 4 +-
drivers/iommu/amd_iommu_types.h | 1 +
drivers/md/md.c | 3 +-
drivers/md/persistent-data/dm-btree-remove.c | 17 ++++---
drivers/md/persistent-data/dm-btree.c | 2 +-
drivers/md/raid1.c | 2 +-
drivers/md/raid10.c | 2 +-
drivers/md/raid5.c | 6 ++-
drivers/net/ethernet/sfc/selftest.c | 2 +-
drivers/net/wireless/ath/ath9k/init.c | 1 +
drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
drivers/net/wireless/iwlwifi/iwl-7000.c | 2 +-
drivers/net/wireless/iwlwifi/mvm/d3.c | 12 ++---
drivers/net/wireless/iwlwifi/pcie/drv.c | 5 +++
drivers/power/bq24190_charger.c | 2 +-
drivers/scsi/mvsas/mv_sas.c | 2 +
drivers/spi/spi-gpio.c | 2 +-
drivers/staging/iio/adc/mxs-lradc.c | 9 ++--
drivers/tty/serial/8250/8250_pci.c | 46 ++++++++++++++++++-
drivers/usb/host/xhci-pci.c | 1 +
drivers/usb/host/xhci-ring.c | 20 ++++++---
include/sound/wm8904.h | 2 +-
kernel/module.c | 8 +++-
mm/filemap.c | 9 ++--
40 files changed, 218 insertions(+), 106 deletions(-)


2015-11-06 19:35:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 01/37] ath9k: declare required extra tx headroom

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Felix Fietkau <[email protected]>

commit 029cd0370241641eb70235d205aa0b90c84dce44 upstream.

ath9k inserts padding between the 802.11 header and the data area (to
align it). Since it didn't declare this extra required headroom, this
led to some nasty issues like randomly dropped packets in some setups.

Signed-off-by: Felix Fietkau <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/ath/ath9k/init.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -956,6 +956,7 @@ static void ath9k_set_hw_capab(struct at
hw->max_rate_tries = 10;
hw->sta_data_size = sizeof(struct ath_node);
hw->vif_data_size = sizeof(struct ath_vif);
+ hw->extra_tx_headroom = 4;

hw->wiphy->available_antennas_rx = BIT(ah->caps.max_rxchains) - 1;
hw->wiphy->available_antennas_tx = BIT(ah->caps.max_txchains) - 1;

2015-11-06 19:34:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 02/37] iwlwifi: dvm: fix D3 firmware PN programming

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit 5bd166872d8f99f156fac191299d24f828bb2348 upstream.

The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/dvm/lib.c
+++ b/drivers/net/wireless/iwlwifi/dvm/lib.c
@@ -1022,7 +1022,7 @@ static void iwlagn_wowlan_program_keys(s
u8 *pn = seq.ccmp.pn;

ieee80211_get_key_rx_seq(key, i, &seq);
- aes_sc->pn = cpu_to_le64(
+ aes_sc[i].pn = cpu_to_le64(
(u64)pn[5] |
((u64)pn[4] << 8) |
((u64)pn[3] << 16) |

2015-11-06 19:33:59

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 03/37] iwlwifi: fix firmware filename for 3160

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit b5a48134f8af08f5243328f8a0b05fc5ae7cf343 upstream.

The MODULE_FIRMWARE() for 3160 should be using the 7260 version as
it's done in the device configuration struct instead of referencing
IWL3160_UCODE_API_OK which doesn't even exist.

Reported-by: Hauke Mehrtens <[email protected]>
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/iwl-7000.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/wireless/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/iwlwifi/iwl-7000.c
@@ -222,5 +222,5 @@ const struct iwl_cfg iwl7265_n_cfg = {
};

MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
-MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL3160_UCODE_API_OK));
+MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
MODULE_FIRMWARE(IWL7265_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));

2015-11-06 19:33:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 04/37] iwlwifi: mvm: fix D3 firmware PN programming

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Johannes Berg <[email protected]>

commit 2cf5eb3ab7bb7f2e3a70edcef236cd62c87db030 upstream.

The code to send the RX PN data (for each TID) to the firmware
has a devastating bug: it overwrites the data for TID 0 with
all the TID data, leaving the remaining TIDs zeroed. This will
allow replays to actually be accepted by the firmware, which
could allow waking up the system.

Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/mvm/d3.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)

--- a/drivers/net/wireless/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/iwlwifi/mvm/d3.c
@@ -297,12 +297,12 @@ static void iwl_mvm_wowlan_program_keys(
u8 *pn = seq.ccmp.pn;

ieee80211_get_key_rx_seq(key, i, &seq);
- aes_sc->pn = cpu_to_le64((u64)pn[5] |
- ((u64)pn[4] << 8) |
- ((u64)pn[3] << 16) |
- ((u64)pn[2] << 24) |
- ((u64)pn[1] << 32) |
- ((u64)pn[0] << 40));
+ aes_sc[i].pn = cpu_to_le64((u64)pn[5] |
+ ((u64)pn[4] << 8) |
+ ((u64)pn[3] << 16) |
+ ((u64)pn[2] << 24) |
+ ((u64)pn[1] << 32) |
+ ((u64)pn[0] << 40));
}
data->use_rsc_tsc = true;
break;

2015-11-06 19:33:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 05/37] iwlwifi: pci: add a few more PCI subvendor IDs for the 7265 series

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Luca Coelho <[email protected]>

commit f08f625876476b6c4a87834dc86e3b927f4697d2 upstream.

Add 3 new subdevice IDs for the 0x095A device ID and 2 for the 0x095B
device ID.

Reported-by: Jeremy <[email protected]>
Signed-off-by: Luca Coelho <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/net/wireless/iwlwifi/pcie/drv.c | 5 +++++
1 file changed, 5 insertions(+)

--- a/drivers/net/wireless/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/iwlwifi/pcie/drv.c
@@ -396,6 +396,11 @@ static DEFINE_PCI_DEVICE_TABLE(iwl_hw_ca
{IWL_PCI_DEVICE(0x095A, 0x5590, iwl7265_2ac_cfg)},
{IWL_PCI_DEVICE(0x095B, 0x5290, iwl7265_2ac_cfg)},
{IWL_PCI_DEVICE(0x095A, 0x5490, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095A, 0x5F10, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095B, 0x5212, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095B, 0x520A, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095A, 0x9000, iwl7265_2ac_cfg)},
+ {IWL_PCI_DEVICE(0x095A, 0x9400, iwl7265_2ac_cfg)},
#endif /* CONFIG_IWLMVM */

{0}

2015-11-06 19:59:30

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 06/37] iommu/amd: Dont clear DTE flags when modifying it

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joerg Roedel <[email protected]>

commit cbf3ccd09d683abf1cacd36e3640872ee912d99b upstream.

During device assignment/deassignment the flags in the DTE
get lost, which might cause spurious faults, for example
when the device tries to access the system management range.
Fix this by not clearing the flags with the rest of the DTE.

Reported-by: G. Richard Bellamy <[email protected]>
Tested-by: G. Richard Bellamy <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/iommu/amd_iommu.c | 4 ++--
drivers/iommu/amd_iommu_types.h | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2152,8 +2152,8 @@ static void set_dte_entry(u16 devid, str
static void clear_dte_entry(u16 devid)
{
/* remove entry from the device table seen by the hardware */
- amd_iommu_dev_table[devid].data[0] = IOMMU_PTE_P | IOMMU_PTE_TV;
- amd_iommu_dev_table[devid].data[1] = 0;
+ amd_iommu_dev_table[devid].data[0] = IOMMU_PTE_P | IOMMU_PTE_TV;
+ amd_iommu_dev_table[devid].data[1] &= DTE_FLAG_MASK;

amd_iommu_apply_erratum_63(devid);
}
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -283,6 +283,7 @@
#define IOMMU_PTE_IR (1ULL << 61)
#define IOMMU_PTE_IW (1ULL << 62)

+#define DTE_FLAG_MASK (0x3ffULL << 32)
#define DTE_FLAG_IOTLB (0x01UL << 32)
#define DTE_FLAG_GV (0x01ULL << 55)
#define DTE_GLX_SHIFT (56)

2015-11-06 19:52:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 07/37] powerpc/rtas: Validate rtas.entry before calling enter_rtas()

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Vasant Hegde <[email protected]>

commit 8832317f662c06f5c06e638f57bfe89a71c9b266 upstream.

Currently we do not validate rtas.entry before calling enter_rtas(). This
leads to a kernel oops when user space calls rtas system call on a powernv
platform (see below). This patch adds code to validate rtas.entry before
making enter_rtas() call.

Oops: Exception in kernel mode, sig: 4 [#1]
SMP NR_CPUS=1024 NUMA PowerNV
task: c000000004294b80 ti: c0000007e1a78000 task.ti: c0000007e1a78000
NIP: 0000000000000000 LR: 0000000000009c14 CTR: c000000000423140
REGS: c0000007e1a7b920 TRAP: 0e40 Not tainted (3.18.17-340.el7_1.pkvm3_1_0.2400.1.ppc64le)
MSR: 1000000000081000 <HV,ME> CR: 00000000 XER: 00000000
CFAR: c000000000009c0c SOFTE: 0
NIP [0000000000000000] (null)
LR [0000000000009c14] 0x9c14
Call Trace:
[c0000007e1a7bba0] [c00000000041a7f4] avc_has_perm_noaudit+0x54/0x110 (unreliable)
[c0000007e1a7bd80] [c00000000002ddc0] ppc_rtas+0x150/0x2d0
[c0000007e1a7be30] [c000000000009358] syscall_exit+0x0/0x98

Fixes: 55190f88789a ("powerpc: Add skeleton PowerNV platform")
Reported-by: NAGESWARA R. SASTRY <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
[mpe: Reword change log, trim oops, and add stable + fixes]
Signed-off-by: Michael Ellerman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/powerpc/kernel/rtas.c | 3 +++
1 file changed, 3 insertions(+)

--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -1041,6 +1041,9 @@ asmlinkage int ppc_rtas(struct rtas_args
if (!capable(CAP_SYS_ADMIN))
return -EPERM;

+ if (!rtas.entry)
+ return -EINVAL;
+
if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
return -EFAULT;


2015-11-06 19:42:00

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 08/37] ASoC: wm8904: Correct number of EQ registers

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Charles Keepax <[email protected]>

commit 97aff2c03a1e4d343266adadb52313613efb027f upstream.

There are 24 EQ registers not 25, I suspect this bug came about because
the registers start at EQ1 not zero. The bug is relatively harmless as
the extra register written is an unused one.

Signed-off-by: Charles Keepax <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
include/sound/wm8904.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/sound/wm8904.h
+++ b/include/sound/wm8904.h
@@ -119,7 +119,7 @@
#define WM8904_MIC_REGS 2
#define WM8904_GPIO_REGS 4
#define WM8904_DRC_REGS 4
-#define WM8904_EQ_REGS 25
+#define WM8904_EQ_REGS 24

/**
* DRC configurations are specified with a label and a set of register

2015-11-06 19:56:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 09/37] x86/setup: Extend low identity map to cover whole kernel range

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Paolo Bonzini <[email protected]>

commit f5f3497cad8c8416a74b9aaceb127908755d020a upstream.

On 32-bit systems, the initial_page_table is reused by
efi_call_phys_prolog as an identity map to call
SetVirtualAddressMap. efi_call_phys_prolog takes care of
converting the current CPU's GDT to a physical address too.

For PAE kernels the identity mapping is achieved by aliasing the
first PDPE for the kernel memory mapping into the first PDPE
of initial_page_table. This makes the EFI stub's trick "just work".

However, for non-PAE kernels there is no guarantee that the identity
mapping in the initial_page_table extends as far as the GDT; in this
case, accesses to the GDT will cause a page fault (which quickly becomes
a triple fault). Fix this by copying the kernel mappings from
swapper_pg_dir to initial_page_table twice, both at PAGE_OFFSET and at
identity mapping.

For some reason, this is only reproducible with QEMU's dynamic translation
mode, and not for example with KVM. However, even under KVM one can clearly
see that the page table is bogus:

$ qemu-system-i386 -pflash OVMF.fd -M q35 vmlinuz0 -s -S -daemonize
$ gdb
(gdb) target remote localhost:1234
(gdb) hb *0x02858f6f
Hardware assisted breakpoint 1 at 0x2858f6f
(gdb) c
Continuing.

Breakpoint 1, 0x02858f6f in ?? ()
(gdb) monitor info registers
...
GDT= 0724e000 000000ff
IDT= fffbb000 000007ff
CR0=0005003b CR2=ff896000 CR3=032b7000 CR4=00000690
...

The page directory is sane:

(gdb) x/4wx 0x32b7000
0x32b7000: 0x03398063 0x03399063 0x0339a063 0x0339b063
(gdb) x/4wx 0x3398000
0x3398000: 0x00000163 0x00001163 0x00002163 0x00003163
(gdb) x/4wx 0x3399000
0x3399000: 0x00400003 0x00401003 0x00402003 0x00403003

but our particular page directory entry is empty:

(gdb) x/1wx 0x32b7000 + (0x724e000 >> 22) * 4
0x32b7070: 0x00000000

[ It appears that you can skate past this issue if you don't receive
any interrupts while the bogus GDT pointer is loaded, or if you avoid
reloading the segment registers in general.

Andy Lutomirski provides some additional insight:

"AFAICT it's entirely permissible for the GDTR and/or LDT
descriptor to point to unmapped memory. Any attempt to use them
(segment loads, interrupts, IRET, etc) will try to access that memory
as if the access came from CPL 0 and, if the access fails, will
generate a valid page fault with CR2 pointing into the GDT or
LDT."

Up until commit 23a0d4e8fa6d ("efi: Disable interrupts around EFI
calls, not in the epilog/prolog calls") interrupts were disabled
around the prolog and epilog calls, and the functional GDT was
re-installed before interrupts were re-enabled.

Which explains why no one has hit this issue until now. ]

Signed-off-by: Paolo Bonzini <[email protected]>
Reported-by: Laszlo Ersek <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andy Lutomirski <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
[ Updated changelog. ]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/kernel/setup.c | 8 ++++++++
1 file changed, 8 insertions(+)

--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -1178,6 +1178,14 @@ void __init setup_arch(char **cmdline_p)
clone_pgd_range(initial_page_table + KERNEL_PGD_BOUNDARY,
swapper_pg_dir + KERNEL_PGD_BOUNDARY,
KERNEL_PGD_PTRS);
+
+ /*
+ * sync back low identity map too. It is used for example
+ * in the 32-bit EFI stub.
+ */
+ clone_pgd_range(initial_page_table,
+ swapper_pg_dir + KERNEL_PGD_BOUNDARY,
+ KERNEL_PGD_PTRS);
#endif

tboot_probe();

2015-11-06 19:53:18

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 10/37] mm: make sendfile(2) killable

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jan Kara <[email protected]>

commit 296291cdd1629c308114504b850dc343eabc2782 upstream.

Currently a simple program below issues a sendfile(2) system call which
takes about 62 days to complete in my test KVM instance.

int fd;
off_t off = 0;

fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
ftruncate(fd, 2);
lseek(fd, 0, SEEK_END);
sendfile(fd, fd, &off, 0xfffffff);

Now you should not ask kernel to do a stupid stuff like copying 256MB in
2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
should have a way to stop you.

We actually do have a check for fatal_signal_pending() in
generic_perform_write() which triggers in this path however because we
always succeed in writing something before the check is done, we return
value > 0 from generic_perform_write() and thus the information about
signal gets lost.

Fix the problem by doing the signal check before writing anything. That
way generic_perform_write() returns -EINTR, the error gets propagated up
and the sendfile loop terminates early.

Signed-off-by: Jan Kara <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
mm/filemap.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)

--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -2509,6 +2509,11 @@ again:
break;
}

+ if (fatal_signal_pending(current)) {
+ status = -EINTR;
+ break;
+ }
+
status = a_ops->write_begin(file, mapping, pos, bytes, flags,
&page, &fsdata);
if (unlikely(status < 0))
@@ -2546,10 +2551,6 @@ again:
written += copied;

balance_dirty_pages_ratelimited(mapping);
- if (fatal_signal_pending(current)) {
- status = -EINTR;
- break;
- }
} while (iov_iter_count(i));

return written ? written : status;

2015-11-06 19:52:55

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 14/37] drm/nouveau/gem: return only valid domain when theres only one

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilia Mirkin <[email protected]>

commit 2a6c521bb41ce862e43db46f52e7681d33e8d771 upstream.

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92504
Signed-off-by: Ilia Mirkin <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -196,11 +196,12 @@ nouveau_gem_info(struct drm_file *file_p
struct nouveau_bo *nvbo = nouveau_gem_object(gem);
struct nouveau_vma *vma;

- if (nvbo->bo.mem.mem_type == TTM_PL_TT)
+ if (is_power_of_2(nvbo->valid_domains))
+ rep->domain = nvbo->valid_domains;
+ else if (nvbo->bo.mem.mem_type == TTM_PL_TT)
rep->domain = NOUVEAU_GEM_DOMAIN_GART;
else
rep->domain = NOUVEAU_GEM_DOMAIN_VRAM;
-
rep->offset = nvbo->bo.offset;
if (cli->base.vm) {
vma = nouveau_bo_vma_find(nvbo, cli->base.vm);

2015-11-06 19:52:34

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 16/37] drm/radeon: dont try to recreate sysfs entries on resume

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Alex Deucher <[email protected]>

commit 49abb26651167c892393cd9f2ad23df429645ed9 upstream.

Fixes a harmless error message caused by:
51a4726b04e880fdd9b4e0e58b13f70b0a68a7f5

Signed-off-by: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 35 +++++++++++++++++++++--------------
2 files changed, 22 insertions(+), 14 deletions(-)

--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1551,6 +1551,7 @@ struct radeon_pm {
struct device *int_hwmon_dev;
/* dpm */
bool dpm_enabled;
+ bool sysfs_initialized;
struct radeon_dpm dpm;
};

--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -1350,19 +1350,23 @@ int radeon_pm_late_init(struct radeon_de

if (rdev->pm.pm_method == PM_METHOD_DPM) {
if (rdev->pm.dpm_enabled) {
- ret = device_create_file(rdev->dev, &dev_attr_power_dpm_state);
- if (ret)
- DRM_ERROR("failed to create device file for dpm state\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_dpm_force_performance_level);
- if (ret)
- DRM_ERROR("failed to create device file for dpm state\n");
- /* XXX: these are noops for dpm but are here for backwards compat */
- ret = device_create_file(rdev->dev, &dev_attr_power_profile);
- if (ret)
- DRM_ERROR("failed to create device file for power profile\n");
- ret = device_create_file(rdev->dev, &dev_attr_power_method);
- if (ret)
- DRM_ERROR("failed to create device file for power method\n");
+ if (!rdev->pm.sysfs_initialized) {
+ ret = device_create_file(rdev->dev, &dev_attr_power_dpm_state);
+ if (ret)
+ DRM_ERROR("failed to create device file for dpm state\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_dpm_force_performance_level);
+ if (ret)
+ DRM_ERROR("failed to create device file for dpm state\n");
+ /* XXX: these are noops for dpm but are here for backwards compat */
+ ret = device_create_file(rdev->dev, &dev_attr_power_profile);
+ if (ret)
+ DRM_ERROR("failed to create device file for power profile\n");
+ ret = device_create_file(rdev->dev, &dev_attr_power_method);
+ if (ret)
+ DRM_ERROR("failed to create device file for power method\n");
+ if (!ret)
+ rdev->pm.sysfs_initialized = true;
+ }

mutex_lock(&rdev->pm.mutex);
ret = radeon_dpm_late_enable(rdev);
@@ -1378,7 +1382,8 @@ int radeon_pm_late_init(struct radeon_de
}
}
} else {
- if (rdev->pm.num_power_states > 1) {
+ if ((rdev->pm.num_power_states > 1) &&
+ (!rdev->pm.sysfs_initialized)) {
/* where's the best place to put these? */
ret = device_create_file(rdev->dev, &dev_attr_power_profile);
if (ret)
@@ -1386,6 +1391,8 @@ int radeon_pm_late_init(struct radeon_de
ret = device_create_file(rdev->dev, &dev_attr_power_method);
if (ret)
DRM_ERROR("failed to create device file for power method\n");
+ if (!ret)
+ rdev->pm.sysfs_initialized = true;
}
}
return ret;

2015-11-06 19:42:05

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 18/37] rbd: require stable pages if message data CRCs are enabled

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ronny Hegewald <[email protected]>

commit bae818ee1577c27356093901a0ea48f672eda514 upstream.

rbd requires stable pages, as it performs a crc of the page data before
they are send to the OSDs.

But since kernel 3.9 (patch 1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0
"mm: only enforce stable page writes if the backing device requires
it") it is not assumed anymore that block devices require stable pages.

This patch sets the necessary flag to get stable pages back for rbd.

In a ceph installation that provides multiple ext4 formatted rbd
devices "bad crc" messages appeared regularly (ca 1 message every 1-2
minutes on every OSD that provided the data for the rbd) in the
OSD-logs before this patch. After this patch this messages are pretty
much gone (only ca 1-2 / month / OSD).

Signed-off-by: Ronny Hegewald <[email protected]>
[[email protected]: require stable pages only in crc case, changelog]
[[email protected]: backport to 3.9-3.17: context]
Signed-off-by: Ilya Dryomov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/block/rbd.c | 3 +++
1 file changed, 3 insertions(+)

--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -3443,6 +3443,9 @@ static int rbd_init_disk(struct rbd_devi
blk_queue_io_opt(q, segment_size);

blk_queue_merge_bvec(q, rbd_merge_bvec);
+ if (!ceph_test_opt(rbd_dev->rbd_client->client, NOCRC))
+ q->backing_dev_info.capabilities |= BDI_CAP_STABLE_WRITES;
+
disk->queue = q;

q->queuedata = rbd_dev;

2015-11-06 19:42:02

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 19/37] rbd: dont leak parent_spec in rbd_dev_probe_parent()

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilya Dryomov <[email protected]>

commit 1f2c6651f69c14d0d3a9cfbda44ea101b02160ba upstream.

Currently we leak parent_spec and trigger a "parent reference
underflow" warning if rbd_dev_create() in rbd_dev_probe_parent() fails.
The problem is we take the !parent out_err branch and that only drops
refcounts; parent_spec that would've been freed had we called
rbd_dev_unparent() remains and triggers rbd_warn() in
rbd_dev_parent_put() - at that point we have parent_spec != NULL and
parent_ref == 0, so counter ends up being -1 after the decrement.

Redo rbd_dev_probe_parent() to fix this.

Signed-off-by: Ilya Dryomov <[email protected]>
[[email protected]: backport to < 4.2: rbd_dev->opts]
Reviewed-by: Alex Elder <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/block/rbd.c | 35 +++++++++++++++--------------------
1 file changed, 15 insertions(+), 20 deletions(-)

--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -4825,41 +4825,36 @@ out_err:
static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
{
struct rbd_device *parent = NULL;
- struct rbd_spec *parent_spec;
- struct rbd_client *rbdc;
int ret;

if (!rbd_dev->parent_spec)
return 0;
- /*
- * We need to pass a reference to the client and the parent
- * spec when creating the parent rbd_dev. Images related by
- * parent/child relationships always share both.
- */
- parent_spec = rbd_spec_get(rbd_dev->parent_spec);
- rbdc = __rbd_get_client(rbd_dev->rbd_client);

- ret = -ENOMEM;
- parent = rbd_dev_create(rbdc, parent_spec);
- if (!parent)
+ parent = rbd_dev_create(rbd_dev->rbd_client, rbd_dev->parent_spec);
+ if (!parent) {
+ ret = -ENOMEM;
goto out_err;
+ }
+
+ /*
+ * Images related by parent/child relationships always share
+ * rbd_client and spec/parent_spec, so bump their refcounts.
+ */
+ __rbd_get_client(rbd_dev->rbd_client);
+ rbd_spec_get(rbd_dev->parent_spec);

ret = rbd_dev_image_probe(parent, false);
if (ret < 0)
goto out_err;
+
rbd_dev->parent = parent;
atomic_set(&rbd_dev->parent_ref, 1);
-
return 0;
+
out_err:
- if (parent) {
- rbd_dev_unparent(rbd_dev);
+ rbd_dev_unparent(rbd_dev);
+ if (parent)
rbd_dev_destroy(parent);
- } else {
- rbd_put_client(rbdc);
- rbd_spec_put(parent_spec);
- }
-
return ret;
}


2015-11-06 19:42:08

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 20/37] rbd: prevent kernel stack blow up on rbd map

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Ilya Dryomov <[email protected]>

commit 6d69bb536bac0d403d83db1ca841444981b280cd upstream.

Mapping an image with a long parent chain (e.g. image foo, whose parent
is bar, whose parent is baz, etc) currently leads to a kernel stack
overflow, due to the following recursion in the reply path:

rbd_osd_req_callback()
rbd_obj_request_complete()
rbd_img_obj_callback()
rbd_img_parent_read_callback()
rbd_obj_request_complete()
...

Limit the parent chain to 16 images, which is ~5K worth of stack. When
the above recursion is eliminated, this limit can be lifted.

Fixes: http://tracker.ceph.com/issues/12538

Signed-off-by: Ilya Dryomov <[email protected]>
Reviewed-by: Josh Durgin <[email protected]>
[[email protected]: backport to 3.14: rbd_dev->opts, context]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/block/rbd.c | 29 +++++++++++++++++++++--------
1 file changed, 21 insertions(+), 8 deletions(-)

--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -94,6 +94,8 @@ static int atomic_dec_return_safe(atomic
#define RBD_MINORS_PER_MAJOR 256
#define RBD_SINGLE_MAJOR_PART_SHIFT 4

+#define RBD_MAX_PARENT_CHAIN_LEN 16
+
#define RBD_SNAP_DEV_NAME_PREFIX "snap_"
#define RBD_MAX_SNAP_NAME_LEN \
(NAME_MAX - (sizeof (RBD_SNAP_DEV_NAME_PREFIX) - 1))
@@ -411,7 +413,7 @@ static ssize_t rbd_add_single_major(stru
size_t count);
static ssize_t rbd_remove_single_major(struct bus_type *bus, const char *buf,
size_t count);
-static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping);
+static int rbd_dev_image_probe(struct rbd_device *rbd_dev, int depth);
static void rbd_spec_put(struct rbd_spec *spec);

static int rbd_dev_id_to_minor(int dev_id)
@@ -4822,7 +4824,12 @@ out_err:
return ret;
}

-static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
+/*
+ * @depth is rbd_dev_image_probe() -> rbd_dev_probe_parent() ->
+ * rbd_dev_image_probe() recursion depth, which means it's also the
+ * length of the already discovered part of the parent chain.
+ */
+static int rbd_dev_probe_parent(struct rbd_device *rbd_dev, int depth)
{
struct rbd_device *parent = NULL;
int ret;
@@ -4830,6 +4837,12 @@ static int rbd_dev_probe_parent(struct r
if (!rbd_dev->parent_spec)
return 0;

+ if (++depth > RBD_MAX_PARENT_CHAIN_LEN) {
+ pr_info("parent chain is too long (%d)\n", depth);
+ ret = -EINVAL;
+ goto out_err;
+ }
+
parent = rbd_dev_create(rbd_dev->rbd_client, rbd_dev->parent_spec);
if (!parent) {
ret = -ENOMEM;
@@ -4843,7 +4856,7 @@ static int rbd_dev_probe_parent(struct r
__rbd_get_client(rbd_dev->rbd_client);
rbd_spec_get(rbd_dev->parent_spec);

- ret = rbd_dev_image_probe(parent, false);
+ ret = rbd_dev_image_probe(parent, depth);
if (ret < 0)
goto out_err;

@@ -4970,7 +4983,7 @@ static void rbd_dev_image_release(struct
* parent), initiate a watch on its header object before using that
* object to get detailed information about the rbd image.
*/
-static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
+static int rbd_dev_image_probe(struct rbd_device *rbd_dev, int depth)
{
int ret;

@@ -4990,7 +5003,7 @@ static int rbd_dev_image_probe(struct rb
if (ret)
goto err_out_format;

- if (mapping) {
+ if (!depth) {
ret = rbd_dev_header_watch_sync(rbd_dev);
if (ret)
goto out_header_name;
@@ -5007,7 +5020,7 @@ static int rbd_dev_image_probe(struct rb
if (ret)
goto err_out_probe;

- ret = rbd_dev_probe_parent(rbd_dev);
+ ret = rbd_dev_probe_parent(rbd_dev, depth);
if (ret)
goto err_out_probe;

@@ -5018,7 +5031,7 @@ static int rbd_dev_image_probe(struct rb
err_out_probe:
rbd_dev_unprobe(rbd_dev);
err_out_watch:
- if (mapping)
+ if (!depth)
rbd_dev_header_unwatch_sync(rbd_dev);
out_header_name:
kfree(rbd_dev->header_name);
@@ -5085,7 +5098,7 @@ static ssize_t do_rbd_add(struct bus_typ
rbdc = NULL; /* rbd_dev now owns this */
spec = NULL; /* rbd_dev now owns this */

- rc = rbd_dev_image_probe(rbd_dev, true);
+ rc = rbd_dev_image_probe(rbd_dev, 0);
if (rc < 0)
goto err_out_rbd_dev;


2015-11-06 19:59:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 21/37] Revert "ARM64: unwind: Fix PC calculation"

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Will Deacon <[email protected]>

commit 9702970c7bd3e2d6fecb642a190269131d4ac16c upstream.

This reverts commit e306dfd06fcb44d21c80acb8e5a88d55f3d1cf63.

With this patch applied, we were the only architecture making this sort
of adjustment to the PC calculation in the unwinder. This causes
problems for ftrace, where the PC values are matched against the
contents of the stack frames in the callchain and fail to match any
records after the address adjustment.

Whilst there has been some effort to change ftrace to workaround this,
those patches are not yet ready for mainline and, since we're the odd
architecture in this regard, let's just step in line with other
architectures (like arch/arm/) for now.

Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/arm64/kernel/stacktrace.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)

--- a/arch/arm64/kernel/stacktrace.c
+++ b/arch/arm64/kernel/stacktrace.c
@@ -48,11 +48,7 @@ int unwind_frame(struct stackframe *fram

frame->sp = fp + 0x10;
frame->fp = *(unsigned long *)(fp);
- /*
- * -4 here because we care about the PC at time of bl,
- * not where the return will go.
- */
- frame->pc = *(unsigned long *)(fp + 8) - 4;
+ frame->pc = *(unsigned long *)(fp + 8);

return 0;
}

2015-11-06 19:58:57

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 22/37] dm btree remove: fix a bug when rebalancing nodes after removal

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Joe Thornber <[email protected]>

commit 2871c69e025e8bc507651d5a9cf81a8a7da9d24b upstream.

Commit 4c7e309340ff ("dm btree remove: fix bug in redistribute3") wasn't
a complete fix for redistribute3().

The redistribute3 function takes 3 btree nodes and shares out the entries
evenly between them. If the three nodes in total contained
(MAX_ENTRIES * 3) - 1 entries between them then this was erroneously getting
rebalanced as (MAX_ENTRIES - 1) on the left and right, and (MAX_ENTRIES + 1) in
the center.

Fix this issue by being more careful about calculating the target number
of entries for the left and right nodes.

Unit tested in userspace using this program:
https://github.com/jthornber/redistribute3-test/blob/master/redistribute3_t.c

Signed-off-by: Joe Thornber <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/persistent-data/dm-btree-remove.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)

--- a/drivers/md/persistent-data/dm-btree-remove.c
+++ b/drivers/md/persistent-data/dm-btree-remove.c
@@ -301,11 +301,16 @@ static void redistribute3(struct dm_btre
{
int s;
uint32_t max_entries = le32_to_cpu(left->header.max_entries);
- unsigned target = (nr_left + nr_center + nr_right) / 3;
- BUG_ON(target > max_entries);
+ unsigned total = nr_left + nr_center + nr_right;
+ unsigned target_right = total / 3;
+ unsigned remainder = (target_right * 3) != total;
+ unsigned target_left = target_right + remainder;
+
+ BUG_ON(target_left > max_entries);
+ BUG_ON(target_right > max_entries);

if (nr_left < nr_right) {
- s = nr_left - target;
+ s = nr_left - target_left;

if (s < 0 && nr_center < -s) {
/* not enough in central node */
@@ -316,10 +321,10 @@ static void redistribute3(struct dm_btre
} else
shift(left, center, s);

- shift(center, right, target - nr_right);
+ shift(center, right, target_right - nr_right);

} else {
- s = target - nr_right;
+ s = target_right - nr_right;
if (s > 0 && nr_center < s) {
/* not enough in central node */
shift(center, right, nr_center);
@@ -329,7 +334,7 @@ static void redistribute3(struct dm_btre
} else
shift(center, right, s);

- shift(left, center, nr_left - target);
+ shift(left, center, nr_left - target_left);
}

*key_ptr(parent, c->index) = center->keys[0];

2015-11-06 19:58:33

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 23/37] dm btree: fix leak of bufio-backed block in btree_split_beneath error path

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mike Snitzer <[email protected]>

commit 4dcb8b57df3593dcb20481d9d6cf79d1dc1534be upstream.

btree_split_beneath()'s error path had an outstanding FIXME that speaks
directly to the potential for _not_ cleaning up a previously allocated
bufio-backed block.

Fix this by releasing the previously allocated bufio block using
unlock_block().

Reported-by: Mikulas Patocka <[email protected]>
Signed-off-by: Mike Snitzer <[email protected]>
Acked-by: Joe Thornber <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/persistent-data/dm-btree.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/persistent-data/dm-btree.c
+++ b/drivers/md/persistent-data/dm-btree.c
@@ -523,7 +523,7 @@ static int btree_split_beneath(struct sh

r = new_block(s->info, &right);
if (r < 0) {
- /* FIXME: put left */
+ unlock_block(s->info, left);
return r;
}


2015-11-06 19:57:50

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 24/37] xhci: handle no ping response error properly

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Mathias Nyman <[email protected]>

commit 3b4739b8951d650becbcd855d7d6f18ac98a9a85 upstream.

If a host fails to wake up a isochronous SuperSpeed device from U1/U2
in time for a isoch transfer it will generate a "No ping response error"
Host will then move to the next transfer descriptor.

Handle this case in the same way as missed service errors, tag the
current TD as skipped and handle it on the next transfer event.

Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-ring.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)

--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -2417,6 +2417,7 @@ static int handle_tx_event(struct xhci_h
u32 trb_comp_code;
int ret = 0;
int td_num = 0;
+ bool handling_skipped_tds = false;

slot_id = TRB_TO_SLOT_ID(le32_to_cpu(event->flags));
xdev = xhci->devs[slot_id];
@@ -2550,6 +2551,10 @@ static int handle_tx_event(struct xhci_h
ep->skip = true;
xhci_dbg(xhci, "Miss service interval error, set skip flag\n");
goto cleanup;
+ case COMP_PING_ERR:
+ ep->skip = true;
+ xhci_dbg(xhci, "No Ping response error, Skip one Isoc TD\n");
+ goto cleanup;
default:
if (xhci_is_vendor_info_code(xhci, trb_comp_code)) {
status = 0;
@@ -2681,13 +2686,18 @@ static int handle_tx_event(struct xhci_h
ep, &status);

cleanup:
+
+
+ handling_skipped_tds = ep->skip &&
+ trb_comp_code != COMP_MISSED_INT &&
+ trb_comp_code != COMP_PING_ERR;
+
/*
- * Do not update event ring dequeue pointer if ep->skip is set.
- * Will roll back to continue process missed tds.
+ * Do not update event ring dequeue pointer if we're in a loop
+ * processing missed tds.
*/
- if (trb_comp_code == COMP_MISSED_INT || !ep->skip) {
+ if (!handling_skipped_tds)
inc_deq(xhci, xhci->event_ring);
- }

if (ret) {
urb = td->urb;
@@ -2722,7 +2732,7 @@ cleanup:
* Process them as short transfer until reach the td pointed by
* the event.
*/
- } while (ep->skip && trb_comp_code != COMP_MISSED_INT);
+ } while (handling_skipped_tds);

return 0;
}

2015-11-06 19:56:58

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 25/37] xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Laura Abbott <[email protected]>

commit fd7cd061adcf5f7503515ba52b6a724642a839c8 upstream.

We received several reports of systems rebooting and powering on
after an attempted shutdown. Testing showed that setting
XHCI_SPURIOUS_WAKEUP quirk in addition to the XHCI_SPURIOUS_REBOOT
quirk allowed the system to shutdown as expected for LynxPoint-LP
xHCI controllers. Set the quirk back.

Note that the quirk was originally introduced for LynxPoint and
LynxPoint-LP just for this same reason. See:

commit 638298dc66ea ("xhci: Fix spurious wakeups after S5 on Haswell")

It was later limited to only concern HP machines as it caused
regression on some machines, see both bug and commit:

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66171
commit 6962d914f317 ("xhci: Limit the spurious wakeup fix only to HP machines")

Later it was discovered that the powering on after shutdown
was limited to LynxPoint-LP (Haswell-ULT) and that some non-LP HP
machine suffered from spontaneous resume from S3 (which should
not be related to the SPURIOUS_WAKEUP quirk at all). An attempt
to fix this then removed the SPURIOUS_WAKEUP flag usage completely.

commit b45abacde3d5 ("xhci: no switching back on non-ULT Haswell")

Current understanding is that LynxPoint-LP (Haswell ULT) machines
need the SPURIOUS_WAKEUP quirk, otherwise they will restart, and
plain Lynxpoint (Haswell) machines may _not_ have the quirk
set otherwise they again will restart.

Signed-off-by: Laura Abbott <[email protected]>
Cc: Takashi Iwai <[email protected]>
Cc: Oliver Neukum <[email protected]>
[Added more history to commit message -Mathias]
Signed-off-by: Mathias Nyman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/usb/host/xhci-pci.c | 1 +
1 file changed, 1 insertion(+)

--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -140,6 +140,7 @@ static void xhci_pci_quirks(struct devic
xhci->quirks |= XHCI_SPURIOUS_WAKEUP;

xhci->quirks |= XHCI_SPURIOUS_REBOOT;
+ xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
}
if (pdev->vendor == PCI_VENDOR_ID_ETRON &&
pdev->device == PCI_DEVICE_ID_ASROCK_P67) {

2015-11-06 19:42:11

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 26/37] xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Cathy Avery <[email protected]>

commit a54c8f0f2d7df525ff997e2afe71866a1a013064 upstream.

xen-blkfront will crash if the check to talk_to_blkback()
in blkback_changed()(XenbusStateInitWait) returns an error.
The driver data is freed and info is set to NULL. Later during
the close process via talk_to_blkback's call to xenbus_dev_fatal()
the null pointer is passed to and dereference in blkfront_closing.

Signed-off-by: Cathy Avery <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/block/xen-blkfront.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -1917,7 +1917,8 @@ static void blkback_changed(struct xenbu
break;
/* Missed the backend's Closing state -- fallthrough */
case XenbusStateClosing:
- blkfront_closing(info);
+ if (info)
+ blkfront_closing(info);
break;
}
}

2015-11-06 19:56:56

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 27/37] module: Fix locking in symbol_put_addr()

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Peter Zijlstra <[email protected]>

commit 275d7d44d802ef271a42dc87ac091a495ba72fc5 upstream.

Poma (on the way to another bug) reported an assertion triggering:

[<ffffffff81150529>] module_assert_mutex_or_preempt+0x49/0x90
[<ffffffff81150822>] __module_address+0x32/0x150
[<ffffffff81150956>] __module_text_address+0x16/0x70
[<ffffffff81150f19>] symbol_put_addr+0x29/0x40
[<ffffffffa04b77ad>] dvb_frontend_detach+0x7d/0x90 [dvb_core]

Laura Abbott <[email protected]> produced a patch which lead us to
inspect symbol_put_addr(). This function has a comment claiming it
doesn't need to disable preemption around the module lookup
because it holds a reference to the module it wants to find, which
therefore cannot go away.

This is wrong (and a false optimization too, preempt_disable() is really
rather cheap, and I doubt any of this is on uber critical paths,
otherwise it would've retained a pointer to the actual module anyway and
avoided the second lookup).

While its true that the module cannot go away while we hold a reference
on it, the data structure we do the lookup in very much _CAN_ change
while we do the lookup. Therefore fix the comment and add the
required preempt_disable().

Reported-by: poma <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Rusty Russell <[email protected]>
Fixes: a6e6abd575fc ("module: remove module_text_address()")
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
kernel/module.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)

--- a/kernel/module.c
+++ b/kernel/module.c
@@ -915,11 +915,15 @@ void symbol_put_addr(void *addr)
if (core_kernel_text(a))
return;

- /* module_text_address is safe here: we're supposed to have reference
- * to module from symbol_get, so it can't go away. */
+ /*
+ * Even though we hold a reference on the module; we still need to
+ * disable preemption in order to safely traverse the data structure.
+ */
+ preempt_disable();
modaddr = __module_text_address(a);
BUG_ON(!modaddr);
module_put(modaddr);
+ preempt_enable();
}
EXPORT_SYMBOL_GPL(symbol_put_addr);


2015-11-06 19:56:38

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 28/37] crypto: api - Only abort operations on fatal signal

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Herbert Xu <[email protected]>

commit 3fc89adb9fa4beff31374a4bf50b3d099d88ae83 upstream.

Currently a number of Crypto API operations may fail when a signal
occurs. This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.

In fact there is currently no need for those operations to be
interrupted by user signals at all. All we need is for them to
be killable.

This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.

Signed-off-by: Herbert Xu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
crypto/ablkcipher.c | 2 +-
crypto/algapi.c | 2 +-
crypto/api.c | 6 +++---
crypto/crypto_user.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)

--- a/crypto/ablkcipher.c
+++ b/crypto/ablkcipher.c
@@ -695,7 +695,7 @@ struct crypto_ablkcipher *crypto_alloc_a
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -325,7 +325,7 @@ static void crypto_wait_for_test(struct
crypto_alg_tested(larval->alg.cra_driver_name, 0);
}

- err = wait_for_completion_interruptible(&larval->completion);
+ err = wait_for_completion_killable(&larval->completion);
WARN_ON(err);

out:
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -172,7 +172,7 @@ static struct crypto_alg *crypto_larval_
struct crypto_larval *larval = (void *)alg;
long timeout;

- timeout = wait_for_completion_interruptible_timeout(
+ timeout = wait_for_completion_killable_timeout(
&larval->completion, 60 * HZ);

alg = larval->adult;
@@ -435,7 +435,7 @@ struct crypto_tfm *crypto_alloc_base(con
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
@@ -552,7 +552,7 @@ void *crypto_alloc_tfm(const char *alg_n
err:
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}
--- a/crypto/crypto_user.c
+++ b/crypto/crypto_user.c
@@ -361,7 +361,7 @@ static struct crypto_alg *crypto_user_ae
err = PTR_ERR(alg);
if (err != -EAGAIN)
break;
- if (signal_pending(current)) {
+ if (fatal_signal_pending(current)) {
err = -EINTR;
break;
}

2015-11-06 19:56:04

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 29/37] md/raid1: submit_bio_wait() returns 0 on success

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jes Sorensen <[email protected]>

commit 203d27b0226a05202438ddb39ef0ef1acb14a759 upstream.

This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
which changed the return value of submit_bio_wait() to return != 0 on
error, but didn't update the caller accordingly.

Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
Reported-by: Bill Kuzeja <[email protected]>
Signed-off-by: Jes Sorensen <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/raid1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -2251,7 +2251,7 @@ static int narrow_write_error(struct r1b
bio_trim(wbio, sector - r1_bio->sector, sectors);
wbio->bi_iter.bi_sector += rdev->data_offset;
wbio->bi_bdev = rdev->bdev;
- if (submit_bio_wait(WRITE, wbio) == 0)
+ if (submit_bio_wait(WRITE, wbio) < 0)
/* failure! */
ok = rdev_set_badblocks(rdev, sector,
sectors, 0)

2015-11-06 19:56:01

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 30/37] md/raid10: submit_bio_wait() returns 0 on success

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Jes Sorensen <[email protected]>

commit 681ab4696062f5aa939c9e04d058732306a97176 upstream.

This was introduced with 9e882242c6193ae6f416f2d8d8db0d9126bd996b
which changed the return value of submit_bio_wait() to return != 0 on
error, but didn't update the caller accordingly.

Fixes: 9e882242c6 ("block: Add submit_bio_wait(), remove from md")
Reported-by: Bill Kuzeja <[email protected]>
Signed-off-by: Jes Sorensen <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/raid10.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -2604,7 +2604,7 @@ static int narrow_write_error(struct r10
choose_data_offset(r10_bio, rdev) +
(sector - r10_bio->sector));
wbio->bi_bdev = rdev->bdev;
- if (submit_bio_wait(WRITE, wbio) == 0)
+ if (submit_bio_wait(WRITE, wbio) < 0)
/* Failure! */
ok = rdev_set_badblocks(rdev, sector,
sectors, 0)

2015-11-06 19:55:10

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 31/37] Revert "md: allow a partially recovered device to be hot-added to an array."

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: NeilBrown <[email protected]>

commit d01552a76d71f9879af448e9142389ee9be6e95b upstream.

This reverts commit 7eb418851f3278de67126ea0c427641ab4792c57.

This commit is poorly justified, I can find not discusison in email,
and it clearly causes a problem.

If a device which is being recovered fails and is subsequently
re-added to an array, there could easily have been changes to the
array *before* the point where the recovery was up to. So the
recovery must start again from the beginning.

If a spare is being recovered and fails, then when it is re-added we
really should do a bitmap-based recovery up to the recovery-offset,
and then a full recovery from there. Before this reversion, we only
did the "full recovery from there" which is not corect. After this
reversion with will do a full recovery from the start, which is safer
but not ideal.

It will be left to a future patch to arrange the two different styles
of recovery.

Reported-and-tested-by: Nate Dailey <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Fixes: 7eb418851f32 ("md: allow a partially recovered device to be hot-added to an array.")
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/md.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/md/md.c
+++ b/drivers/md/md.c
@@ -7775,8 +7775,7 @@ static int remove_and_add_spares(struct
!test_bit(Bitmap_sync, &rdev->flags)))
continue;

- if (rdev->saved_raid_disk < 0)
- rdev->recovery_offset = 0;
+ rdev->recovery_offset = 0;
if (mddev->pers->
hot_add_disk(mddev, rdev) == 0) {
if (sysfs_link_rdev(mddev, rdev))

2015-11-06 19:54:36

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 33/37] IB/cm: Fix rb-tree duplicate free and use-after-free

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Doron Tsur <[email protected]>

commit 0ca81a2840f77855bbad1b9f172c545c4dc9e6a4 upstream.

ib_send_cm_sidr_rep could sometimes erase the node from the sidr
(depending on errors in the process). Since ib_send_cm_sidr_rep is
called both from cm_sidr_req_handler and cm_destroy_id, cm_id_priv
could be either erased from the rb_tree twice or not erased at all.
Fixing that by making sure it's erased only once before freeing
cm_id_priv.

Fixes: a977049dacde ('[PATCH] IB: Add the kernel CM implementation')
Signed-off-by: Doron Tsur <[email protected]>
Signed-off-by: Matan Barak <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/infiniband/core/cm.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/infiniband/core/cm.c
+++ b/drivers/infiniband/core/cm.c
@@ -860,6 +860,11 @@ retest:
case IB_CM_SIDR_REQ_RCVD:
spin_unlock_irq(&cm_id_priv->lock);
cm_reject_sidr_req(cm_id_priv, IB_SIDR_REJECT);
+ spin_lock_irq(&cm.lock);
+ if (!RB_EMPTY_NODE(&cm_id_priv->sidr_id_node))
+ rb_erase(&cm_id_priv->sidr_id_node,
+ &cm.remote_sidr_table);
+ spin_unlock_irq(&cm.lock);
break;
case IB_CM_REQ_SENT:
ib_cancel_mad(cm_id_priv->av.port->mad_agent, cm_id_priv->msg);
@@ -3099,7 +3104,10 @@ int ib_send_cm_sidr_rep(struct ib_cm_id
spin_unlock_irqrestore(&cm_id_priv->lock, flags);

spin_lock_irqsave(&cm.lock, flags);
- rb_erase(&cm_id_priv->sidr_id_node, &cm.remote_sidr_table);
+ if (!RB_EMPTY_NODE(&cm_id_priv->sidr_id_node)) {
+ rb_erase(&cm_id_priv->sidr_id_node, &cm.remote_sidr_table);
+ RB_CLEAR_NODE(&cm_id_priv->sidr_id_node);
+ }
spin_unlock_irqrestore(&cm.lock, flags);
return 0;


2015-11-06 19:54:35

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 34/37] md/raid5: fix locking in handle_stripe_clean_event()

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Roman Gushchin <[email protected]>

commit b8a9d66d043ffac116100775a469f05f5158c16f upstream.

After commit 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
__find_stripe() is called under conf->hash_locks + hash.
But handle_stripe_clean_event() calls remove_hash() under
conf->device_lock.

Under some cirscumstances the hash chain can be circuited,
and we get an infinite loop with disabled interrupts and locked hash
lock in __find_stripe(). This leads to hard lockup on multiple CPUs
and following system crash.

I was able to reproduce this behavior on raid6 over 6 ssd disks.
The devices_handle_discard_safely option should be set to enable trim
support. The following script was used:

for i in `seq 1 32`; do
dd if=/dev/zero of=large$i bs=10M count=100 &
done

neilb: original was against a 3.x kernel. I forward-ported
to 4.3-rc. This verison is suitable for any kernel since
Commit: 59fc630b8b5f ("RAID5: batch adjacent full stripe write")
(v4.1+). I'll post a version for earlier kernels to stable.

Signed-off-by: Roman Gushchin <[email protected]>
Fixes: 566c09c53455 ("raid5: relieve lock contention in get_active_stripe()")
Signed-off-by: NeilBrown <[email protected]>
Cc: Shaohua Li <[email protected]>
Cc: <[email protected]> # 3.13 - 4.2
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/md/raid5.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -3029,6 +3029,8 @@ static void handle_stripe_clean_event(st
}
if (!discard_pending &&
test_bit(R5_Discard, &sh->dev[sh->pd_idx].flags)) {
+ int hash = sh->hash_lock_index;
+
clear_bit(R5_Discard, &sh->dev[sh->pd_idx].flags);
clear_bit(R5_UPTODATE, &sh->dev[sh->pd_idx].flags);
if (sh->qd_idx >= 0) {
@@ -3042,9 +3044,9 @@ static void handle_stripe_clean_event(st
* no updated data, so remove it from hash list and the stripe
* will be reinitialized
*/
- spin_lock_irq(&conf->device_lock);
+ spin_lock_irq(conf->hash_locks + hash);
remove_hash(sh);
- spin_unlock_irq(&conf->device_lock);
+ spin_unlock_irq(conf->hash_locks + hash);
if (test_bit(STRIPE_SYNC_REQUESTED, &sh->state))
set_bit(STRIPE_HANDLE, &sh->state);


2015-11-06 19:53:39

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 35/37] serial: 8250_pci: Add support for 16 port Exar boards

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Soeren Grunewald <[email protected]>

commit 96a5d18bc1338786fecac73599f1681f59a59a8e upstream.

The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
combined to act as a single 16 port chip. Therefor one chip is configured
as master the second as slave by connecting the mode pin to VCC (master)
or GND (slave).

Then the master chip is reporting a different device-id depending on
whether a slave is detected or not. The UARTs 8-15 are addressed from
0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
address all 16 ports as before.

See: https://www.exar.com/common/content/document.ashx?id=1587 page 11

Signed-off-by: Soeren Grunewald <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/8250/8250_pci.c | 25 +++++++++++++++++++++++--
1 file changed, 23 insertions(+), 2 deletions(-)

--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1772,6 +1772,8 @@ pci_wch_ch353_setup(struct serial_privat
#define PCI_DEVICE_ID_SUNIX_1999 0x1999


+#define PCI_DEVICE_ID_EXAR_XR17V8358 0x8358
+
/* Unknown vendors/cards - this should not be in linux/pci_ids.h */
#define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584
#define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588
@@ -2266,6 +2268,13 @@ static struct pci_serial_quirk pci_seria
.subdevice = PCI_ANY_ID,
.setup = pci_xr17v35x_setup,
},
+ {
+ .vendor = PCI_VENDOR_ID_EXAR,
+ .device = PCI_DEVICE_ID_EXAR_XR17V8358,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
/*
* Xircom cards
*/
@@ -2706,6 +2715,7 @@ enum pci_board_num_t {
pbn_exar_XR17V352,
pbn_exar_XR17V354,
pbn_exar_XR17V358,
+ pbn_exar_XR17V8358,
pbn_exar_ibm_saturn,
pbn_pasemi_1682M,
pbn_ni8430_2,
@@ -3375,6 +3385,14 @@ static struct pciserial_board pci_boards
.reg_shift = 0,
.first_offset = 0,
},
+ [pbn_exar_XR17V8358] = {
+ .flags = FL_BASE0,
+ .num_ports = 16,
+ .base_baud = 7812500,
+ .uart_offset = 0x400,
+ .reg_shift = 0,
+ .first_offset = 0,
+ },
[pbn_exar_ibm_saturn] = {
.flags = FL_BASE0,
.num_ports = 1,
@@ -4731,7 +4749,7 @@ static struct pci_device_id serial_pci_t
0,
0, pbn_exar_XR17C158 },
/*
- * Exar Corp. XR17V35[248] Dual/Quad/Octal PCIe UARTs
+ * Exar Corp. XR17V[48]35[248] Dual/Quad/Octal/Hexa PCIe UARTs
*/
{ PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V352,
PCI_ANY_ID, PCI_ANY_ID,
@@ -4745,7 +4763,10 @@ static struct pci_device_id serial_pci_t
PCI_ANY_ID, PCI_ANY_ID,
0,
0, pbn_exar_XR17V358 },
-
+ { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V8358,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V8358 },
/*
* Topic TP560 Data/Fax/Voice 56k modem (reported by Evan Clarke)
*/

2015-11-06 19:53:37

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 36/37] serial: 8250_pci: Add support for 12 port Exar boards

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

From: Soeren Grunewald <[email protected]>

commit be32c0cf0462c36f482b5ddcff1d8371be1e183c upstream.

The Exar XR17V358 can also be combined with a XR17V354 chip to act as a
single 12 port chip. This works the same way as the combining two XR17V358
chips. But the reported device id then is 0x4358.

Signed-off-by: Soeren Grunewald <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
drivers/tty/serial/8250/8250_pci.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)

--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1772,6 +1772,7 @@ pci_wch_ch353_setup(struct serial_privat
#define PCI_DEVICE_ID_SUNIX_1999 0x1999


+#define PCI_DEVICE_ID_EXAR_XR17V4358 0x4358
#define PCI_DEVICE_ID_EXAR_XR17V8358 0x8358

/* Unknown vendors/cards - this should not be in linux/pci_ids.h */
@@ -2270,6 +2271,13 @@ static struct pci_serial_quirk pci_seria
},
{
.vendor = PCI_VENDOR_ID_EXAR,
+ .device = PCI_DEVICE_ID_EXAR_XR17V4358,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_xr17v35x_setup,
+ },
+ {
+ .vendor = PCI_VENDOR_ID_EXAR,
.device = PCI_DEVICE_ID_EXAR_XR17V8358,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
@@ -2715,6 +2723,7 @@ enum pci_board_num_t {
pbn_exar_XR17V352,
pbn_exar_XR17V354,
pbn_exar_XR17V358,
+ pbn_exar_XR17V4358,
pbn_exar_XR17V8358,
pbn_exar_ibm_saturn,
pbn_pasemi_1682M,
@@ -3385,6 +3394,14 @@ static struct pciserial_board pci_boards
.reg_shift = 0,
.first_offset = 0,
},
+ [pbn_exar_XR17V4358] = {
+ .flags = FL_BASE0,
+ .num_ports = 12,
+ .base_baud = 7812500,
+ .uart_offset = 0x400,
+ .reg_shift = 0,
+ .first_offset = 0,
+ },
[pbn_exar_XR17V8358] = {
.flags = FL_BASE0,
.num_ports = 16,
@@ -4763,6 +4780,10 @@ static struct pci_device_id serial_pci_t
PCI_ANY_ID, PCI_ANY_ID,
0,
0, pbn_exar_XR17V358 },
+ { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V4358,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0,
+ 0, pbn_exar_XR17V4358 },
{ PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V8358,
PCI_ANY_ID, PCI_ANY_ID,
0,

2015-11-06 19:42:15

by Greg Kroah-Hartman

[permalink] [raw]
Subject: [PATCH 3.14 37/37] xen: fix backport of previous kexec patch

3.14-stable review patch. If anyone has any objections, please let me know.

------------------

Fixes the backport of 0b34a166f291d255755be46e43ed5497cdd194f2 upstream

Commit 0b34a166f291d255755be46e43ed5497cdd194f2 "x86/xen: Support
kexec/kdump in HVM guests by doing a soft reset" has been added to the
4.2-stable tree" needed to correct the CONFIG variable, as
CONFIG_KEXEC_CORE only showed up in 4.3.

Reported-by: David Vrabel <[email protected]>
Reported-by: Luis Henriques <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
arch/x86/xen/enlighten.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -33,7 +33,7 @@
#include <linux/memblock.h>
#include <linux/edd.h>

-#ifdef CONFIG_KEXEC_CORE
+#ifdef CONFIG_KEXEC
#include <linux/kexec.h>
#endif

@@ -1848,7 +1848,7 @@ static struct notifier_block xen_hvm_cpu
.notifier_call = xen_hvm_cpu_notify,
};

-#ifdef CONFIG_KEXEC_CORE
+#ifdef CONFIG_KEXEC
static void xen_hvm_shutdown(void)
{
native_machine_shutdown();
@@ -1879,7 +1879,7 @@ static void __init xen_hvm_guest_init(vo
x86_init.irqs.intr_init = xen_init_IRQ;
xen_hvm_init_time_ops();
xen_hvm_init_mmu_ops();
-#ifdef CONFIG_KEXEC_CORE
+#ifdef CONFIG_KEXEC
machine_ops.shutdown = xen_hvm_shutdown;
machine_ops.crash_shutdown = xen_hvm_crash_shutdown;
#endif

2015-11-07 01:41:42

by Guenter Roeck

[permalink] [raw]
Subject: Re: [PATCH 3.14 00/37] 3.14.57-stable review

On 11/06/2015 11:24 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.57 release.
> There are 37 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Nov 8 19:23:35 UTC 2015.
> Anything received after that time might be too late.
>

Build results:
total: 127 pass: 127 fail: 0
Qemu test results:
total: 81 pass: 81 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

2015-11-07 02:54:36

by Shuah Khan

[permalink] [raw]
Subject: Re: [PATCH 3.14 00/37] 3.14.57-stable review

On 11/06/2015 12:24 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.57 release.
> There are 37 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Nov 8 19:23:35 UTC 2015.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.14.57-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah


--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978

2015-11-23 14:33:06

by Soeren Grunewald

[permalink] [raw]
Subject: Re: [PATCH 3.14 35/37] serial: 8250_pci: Add support for 16 port Exar boards

Dear Greg,

Could you please also add upstream commit
899f0c1c7dbcc487fdc8756a49ff70b1d5d75f89

There was a merge conflict in the 4-1.y tree with another back-ported
patch. But in 3.14 this shouldn't be the case.
--
Thanks & regrads,
Soeren


On 11/06/2015 08:24 PM, Greg Kroah-Hartman wrote:
> 3.14-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Soeren Grunewald <[email protected]>
>
> commit 96a5d18bc1338786fecac73599f1681f59a59a8e upstream.
>
> The Exar XR17V358 chip usually provides only 8 ports. But two chips can be
> combined to act as a single 16 port chip. Therefor one chip is configured
> as master the second as slave by connecting the mode pin to VCC (master)
> or GND (slave).
>
> Then the master chip is reporting a different device-id depending on
> whether a slave is detected or not. The UARTs 8-15 are addressed from
> 0x2000-0x3fff. So the offset of 0x400 from UART to UART can be used to
> address all 16 ports as before.
>
> See: https://www.exar.com/common/content/document.ashx?id=1587 page 11
>
> Signed-off-by: Soeren Grunewald <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> ---
> drivers/tty/serial/8250/8250_pci.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -1772,6 +1772,8 @@ pci_wch_ch353_setup(struct serial_privat
> #define PCI_DEVICE_ID_SUNIX_1999 0x1999
>
>
> +#define PCI_DEVICE_ID_EXAR_XR17V8358 0x8358
> +
> /* Unknown vendors/cards - this should not be in linux/pci_ids.h */
> #define PCI_SUBDEVICE_ID_UNKNOWN_0x1584 0x1584
> #define PCI_SUBDEVICE_ID_UNKNOWN_0x1588 0x1588
> @@ -2266,6 +2268,13 @@ static struct pci_serial_quirk pci_seria
> .subdevice = PCI_ANY_ID,
> .setup = pci_xr17v35x_setup,
> },
> + {
> + .vendor = PCI_VENDOR_ID_EXAR,
> + .device = PCI_DEVICE_ID_EXAR_XR17V8358,
> + .subvendor = PCI_ANY_ID,
> + .subdevice = PCI_ANY_ID,
> + .setup = pci_xr17v35x_setup,
> + },
> /*
> * Xircom cards
> */
> @@ -2706,6 +2715,7 @@ enum pci_board_num_t {
> pbn_exar_XR17V352,
> pbn_exar_XR17V354,
> pbn_exar_XR17V358,
> + pbn_exar_XR17V8358,
> pbn_exar_ibm_saturn,
> pbn_pasemi_1682M,
> pbn_ni8430_2,
> @@ -3375,6 +3385,14 @@ static struct pciserial_board pci_boards
> .reg_shift = 0,
> .first_offset = 0,
> },
> + [pbn_exar_XR17V8358] = {
> + .flags = FL_BASE0,
> + .num_ports = 16,
> + .base_baud = 7812500,
> + .uart_offset = 0x400,
> + .reg_shift = 0,
> + .first_offset = 0,
> + },
> [pbn_exar_ibm_saturn] = {
> .flags = FL_BASE0,
> .num_ports = 1,
> @@ -4731,7 +4749,7 @@ static struct pci_device_id serial_pci_t
> 0,
> 0, pbn_exar_XR17C158 },
> /*
> - * Exar Corp. XR17V35[248] Dual/Quad/Octal PCIe UARTs
> + * Exar Corp. XR17V[48]35[248] Dual/Quad/Octal/Hexa PCIe UARTs
> */
> { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V352,
> PCI_ANY_ID, PCI_ANY_ID,
> @@ -4745,7 +4763,10 @@ static struct pci_device_id serial_pci_t
> PCI_ANY_ID, PCI_ANY_ID,
> 0,
> 0, pbn_exar_XR17V358 },
> -
> + { PCI_VENDOR_ID_EXAR, PCI_DEVICE_ID_EXAR_XR17V8358,
> + PCI_ANY_ID, PCI_ANY_ID,
> + 0,
> + 0, pbn_exar_XR17V8358 },
> /*
> * Topic TP560 Data/Fax/Voice 56k modem (reported by Evan Clarke)
> */
>
>