Skip to contentSkip to conversation

3.12.51-stable review

PATCH In review Jiri Slaby 5 participants 80 messages Nov 23, 2015 – Nov 30, 2015 Stable branch

lore
Share & tools
lore

Jiri Slaby

author
#0 lore raw

cover 3.12.51-stable review

This is the start of the stable review cycle for the 3.12.51 release. There are 72 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 Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.51-rc1.xz

and the diffstat can be found below.

thanks,
js

===============

Ani Sinha (2):
ipmr: fix possible race resulting from improper usage of
IP_INC_STATS_BH() in preemptible context.
net:socket: set msg_namelen to 0 if msg_name is passed as NULL in
msghdr struct from userland.

Anton Blanchard (1):
powerpc/pseries: Fix dedicated processor partition detection

Bjørn Mork (1):
qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module

Carol L Soto (1):
net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

Cathy Avery (1):
xen-blkfront: check for null drvdata in blkback_changed
(XenbusStateClosing)

Charles Keepax (3):
ASoC: wm8904: Correct number of EQ registers
mfd: wm5110: Add register patch for rev D chip
mfd: wm5110: Add register patch for rev E and above

Dan Carpenter (2):
mptfusion: prevent some memory corruption
irda: precedence bug in irlmp_seq_hb_idx()

Dan Williams (1):
ahci: avoton port-disable reset-quirk

David Howells (2):
KEYS: Fix race between key destruction and finding a keyring by name
KEYS: Fix crash when attempt to garbage collect an uninstantiated
keyring

David S. Miller (1):
sfc: Fix memcpy() with const destination compiler warning.

Doron Tsur (1):
IB/cm: Fix rb-tree duplicate free and use-after-free

Dāvis Mosāns (1):
mvsas: Fix NULL pointer dereference in mvs_slot_task_free

Eric Dumazet (3):
sit: fix sit0 percpu double allocations
net: avoid NULL deref in inet_ctl_sock_destroy()
net: fix a race in dst_release()

Eric Northup (1):
KVM: x86: work around infinite loop in microcode when #AC is delivered

Florian Fainelli (1):
ARM: orion: Fix DSA platform device after mvmdio conversion

Guillaume Nault (1):
ppp: fix pppoe_dev deletion condition in pppoe_release()

Hans de Goede (1):
libahci: Allow drivers to override start_engine

Herbert Xu (1):
crypto: api - Only abort operations on fatal signal

Holger Eitzenberger (1):
netfilter: xt_NFQUEUE: fix --queue-bypass regression

Ilia Mirkin (1):
drm/nouveau/gem: return only valid domain when there's only one

Ilya Dryomov (2):
rbd: don't leak parent_spec in rbd_dev_probe_parent()
rbd: prevent kernel stack blow up on rbd map

Jan Kara (1):
mm: make sendfile(2) killable

Jason Wang (2):
macvtap: unbreak receiving of gro skb with frag list
virtio-net: drop NETIF_F_FRAGLIST

Jes Sorensen (2):
md/raid1: submit_bio_wait() returns 0 on success md/raid10: submit_bio_wait() returns 0 on success

Joe Thornber (1):
dm btree remove: fix a bug when rebalancing nodes after removal

Joerg Roedel (1):
iommu/amd: Don't clear DTE flags when modifying it

Johannes Berg (3):
iwlwifi: dvm: fix D3 firmware PN programming
iwlwifi: fix firmware filename for 3160
iwlwifi: mvm: fix D3 firmware PN programming

Lad, Prabhakar (1):
power: bq24190_charger: suppress build warning

Laura Abbott (1):
xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

Marc Zyngier (1):
net: sun4i-emac: fix memory leak on bad packet

Marcelo Leitner (1):
ipv6: addrconf: validate new MTU before applying it

Mathias Nyman (1):
xhci: handle no ping response error properly

Mike Snitzer (1):
dm btree: fix leak of bufio-backed block in btree_split_beneath error
path

Nadav Amit (3):
KVM: x86: Defining missing x86 vectors
KVM: x86: Fix far-jump to non-canonical check
KVM: x86: Use new is_noncanonical_address in _linearize

Paolo Bonzini (1):
KVM: svm: unconditionally intercept #DB

Paul Moore (2):
audit: correctly record file names with different path name types
audit: create private file name copies when auditing inodes

Peter Hurley (1):
serial: 8250_dw: Fix deadlock in LCR workaround

Peter Zijlstra (1):
module: Fix locking in symbol_put_addr()

Phil Reid (1):
stmmac: Correctly report PTP capabilities.

Ronny Hegewald (1):
rbd: require stable pages if message data CRCs are enabled

Sasha Levin (1):
RDS: verify the underlying transport exists before creating a
connection

SeongJae Park (1):
spi: fix pointer-integer size mismatch warning

Soeren Grunewald (2):
serial: 8250_pci: Add support for 16 port Exar boards
serial: 8250_pci: Add support for 12 port Exar boards

Sowmini Varadhan (1):
RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in
rds_tcp_data_recv

Tom Tucker (1):
Fix regression in NFSRDMA server

Vasant Hegde (1):
powerpc/rtas: Validate rtas.entry before calling enter_rtas()

Vasily Averin (1):
bridge: superfluous skb->nfct check in br_nf_dev_queue_xmit

Wei Yongjun (1):
macmace: add missing platform_set_drvdata() in mace_probe()

Will Deacon (1):
Revert "ARM64: unwind: Fix PC calculation"

Yan, Zheng (3):
ceph: make sure request isn't in any waiting list when kicking
request.
ceph: protect kick_requests() with mdsc->mutex
ceph: fix kick_requests()

Yasuaki Ishimatsu (2):
x86/mm/hotplug: Pass sync_global_pgds() a correct argument in
remove_pagetable()
x86/mm/hotplug: Modify PGD entry when removing memory

hayeswang (2):
r8169: fix the incorrect tx descriptor version
r8169: disable L23

 arch/arm/plat-orion/common.c                       |   2 +-
 arch/arm64/kernel/stacktrace.c                     |   6 +-
 arch/powerpc/include/asm/lppaca.h                  |  12 +--
 arch/powerpc/kernel/rtas.c                         |   3 +
 arch/x86/include/asm/pgtable_64.h                  |   3 +-
 arch/x86/include/uapi/asm/kvm.h                    |   3 +
 arch/x86/include/uapi/asm/svm.h                    |   1 +
 arch/x86/kvm/emulate.c                             |  10 +-
 arch/x86/kvm/svm.c                                 |  22 ++---
 arch/x86/kvm/vmx.c                                 |   5 +-
 arch/x86/mm/fault.c                                |   2 +-
 arch/x86/mm/init_64.c                              |  36 ++++---
 crypto/ablkcipher.c                                |   2 +-
 crypto/algapi.c                                    |   2 +-
 crypto/api.c                                       |   6 +-
 crypto/crypto_user.c                               |   2 +-
 drivers/ata/ahci.c                                 | 109 +++++++++++++++++++--
 drivers/ata/ahci.h                                 |   6 ++
 drivers/ata/libahci.c                              |  26 +++--
 drivers/ata/sata_highbank.c                        |   3 +-
 drivers/block/rbd.c                                |  67 +++++++------
 drivers/block/xen-blkfront.c                       |   3 +-
 drivers/gpu/drm/nouveau/nouveau_gem.c              |   5 +-
 drivers/infiniband/core/cm.c                       |  10 +-
 drivers/iommu/amd_iommu.c                          |   4 +-
 drivers/iommu/amd_iommu_types.h                    |   1 +
 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/message/fusion/mptctl.c                    |   9 ++
 drivers/mfd/wm5110-tables.c                        |  44 ++++++++-
 drivers/net/ethernet/allwinner/sun4i-emac.c        |   6 +-
 drivers/net/ethernet/apple/macmace.c               |   1 +
 drivers/net/ethernet/mellanox/mlx4/cmd.c           |   2 +-
 drivers/net/ethernet/mellanox/mlx4/eq.c            |   2 +-
 drivers/net/ethernet/realtek/r8169.c               |  27 ++++-
 drivers/net/ethernet/sfc/selftest.c                |   2 +-
 .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c   |   7 +-
 drivers/net/macvtap.c                              |   2 +-
 drivers/net/ppp/pppoe.c                            |   2 +-
 drivers/net/usb/qmi_wwan.c                         |   5 +-
 drivers/net/virtio_net.c                           |   4 +-
 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/power/bq24190_charger.c                    |   2 +-
 drivers/scsi/mvsas/mv_sas.c                        |   2 +
 drivers/spi/spi-gpio.c                             |   2 +-
 drivers/tty/serial/8250/8250_dw.c                  |  10 +-
 drivers/tty/serial/8250/8250_pci.c                 |  46 ++++++++-
 drivers/usb/host/xhci-pci.c                        |   1 +
 drivers/usb/host/xhci-ring.c                       |  20 +++-
 fs/ceph/mds_client.c                               |  11 ++-
 include/net/inet_common.h                          |   3 +-
 include/sound/wm8904.h                             |   2 +-
 kernel/auditsc.c                                   |  49 +++++++--
 kernel/module.c                                    |   8 +-
 mm/filemap.c                                       |   9 +-
 net/bridge/br_netfilter.c                          |   4 +-
 net/core/dst.c                                     |   2 +-
 net/ipv4/ipmr.c                                    |   6 +-
 net/ipv6/addrconf.c                                |  17 +++-
 net/ipv6/sit.c                                     |  20 +---
 net/irda/irlmp.c                                   |   2 +-
 net/netfilter/xt_NFQUEUE.c                         |   7 +-
 net/rds/connection.c                               |   6 ++
 net/rds/tcp_recv.c                                 |  11 ++-
 net/socket.c                                       |   3 +
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c            |  12 +--
 net/sunrpc/xprtrdma/svc_rdma_sendto.c              |   1 +
 security/keys/gc.c                                 |  10 +-
 72 files changed, 569 insertions(+), 200 deletions(-)
Signature · 1 line
2.6.3
author
#1 lore raw

PATCH 1/72 dm btree remove: fix a bug when rebalancing nodes after removal

From: Joe Thornber <[email protected]>

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

===============

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

---
 drivers/md/persistent-data/dm-btree-remove.c | 17 +++++++++++------
 1 file changed, 11 insertions(+), 6 deletions(-)
drivers/md/persistent-data/dm-btree-remove.c +11 -6
index 7c0d75547ccf..92cd09f3c69b 100644
@@ -301,11 +301,16 @@ static void redistribute3(struct dm_btree_info *info, struct btree_node *parent,
 {
 	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_btree_info *info, struct btree_node *parent,
 		} 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_btree_info *info, struct btree_node *parent,
 		} 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];
Signature · 1 line
2.6.3
author
#2 lore raw

PATCH 2/72 iwlwifi: dvm: fix D3 firmware PN programming

From: Johannes Berg <[email protected]>

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

===============

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.

---
 drivers/net/wireless/iwlwifi/dvm/lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/iwlwifi/dvm/lib.c +1 -1
index 3d5bdc4217a8..d8ab09cb3bc9 100644
@@ -1023,7 +1023,7 @@ static void iwlagn_wowlan_program_keys(struct ieee80211_hw *hw,
 			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) |
Signature · 1 line
2.6.3
author
#3 lore raw

PATCH 3/72 iwlwifi: fix firmware filename for 3160

In reply to Jiri Slaby

From: Johannes Berg <[email protected]>

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

===============

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.

---
 drivers/net/wireless/iwlwifi/iwl-7000.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/wireless/iwlwifi/iwl-7000.c +1 -1
index 200f0d98471a..2a64a84d7488 100644
@@ -190,4 +190,4 @@ const struct iwl_cfg iwl3160_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));
Signature · 1 line
2.6.3
author
#4 lore raw

PATCH 4/72 iwlwifi: mvm: fix D3 firmware PN programming

In reply to Jiri Slaby

From: Johannes Berg <[email protected]>

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

===============

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.

---
 drivers/net/wireless/iwlwifi/mvm/d3.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
drivers/net/wireless/iwlwifi/mvm/d3.c +6 -6
index 417639f77b01..a25f608d8ab4 100644
@@ -296,12 +296,12 @@ static void iwl_mvm_wowlan_program_keys(struct ieee80211_hw *hw,
 			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;
Signature · 1 line
2.6.3
author
#5 lore raw

PATCH 5/72 iommu/amd: Don't clear DTE flags when modifying it

In reply to Jiri Slaby

From: Joerg Roedel <[email protected]>

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

===============

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.

---
 drivers/iommu/amd_iommu.c       | 4 ++--
 drivers/iommu/amd_iommu_types.h | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)
drivers/iommu/amd_iommu.c +2 -2
index d22b4af761f5..382c9ee08a25 100644
@@ -2147,8 +2147,8 @@ static void set_dte_entry(u16 devid, struct protection_domain *domain, bool ats)
 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);
 }
drivers/iommu/amd_iommu_types.h +1 -0
index 97e81fe5c330..271191980d6a 100644
@@ -289,6 +289,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)
Signature · 1 line
2.6.3
author
#6 lore raw

PATCH 6/72 powerpc/rtas: Validate rtas.entry before calling enter_rtas()

In reply to Jiri Slaby

From: Vasant Hegde <[email protected]>

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

===============

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")
[mpe: Reword change log, trim oops, and add stable + fixes]
---
 arch/powerpc/kernel/rtas.c | 3 +++
 1 file changed, 3 insertions(+)
arch/powerpc/kernel/rtas.c +3 -0
index c4bc8d6cfd79..e6b028d3b1e7 100644
@@ -1041,6 +1041,9 @@ asmlinkage int ppc_rtas(struct rtas_args __user *uargs)
 	if (!capable(CAP_SYS_ADMIN))
 		return -EPERM;
 
+	if (!rtas.entry)
+		return -EINVAL;
+
 	if (copy_from_user(&args, uargs, 3 * sizeof(u32)) != 0)
 		return -EFAULT;
 
Signature · 1 line
2.6.3
author
#7 lore raw

PATCH 7/72 ASoC: wm8904: Correct number of EQ registers

In reply to Jiri Slaby

From: Charles Keepax <[email protected]>

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

===============

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.

---
 include/sound/wm8904.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
include/sound/wm8904.h +1 -1
index 898be3a8db9a..6d8f8fba3341 100644
@@ -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
Signature · 1 line
2.6.3
author
#8 lore raw

PATCH 8/72 mm: make sendfile(2) killable

In reply to Jiri Slaby

From: Jan Kara <[email protected]>

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

===============

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.

---
 mm/filemap.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
mm/filemap.c +5 -4
index bd08e9bbf347..af9e11ea4ecf 100644
@@ -2511,6 +2511,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))
@@ -2548,10 +2553,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;
Signature · 1 line
2.6.3
author
#9 lore raw

PATCH 9/72 sfc: Fix memcpy() with const destination compiler warning.

In reply to Jiri Slaby

From: "David S. Miller" <[email protected]>

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

===============

commit 1d20a16062e771b6e26b843c0cde3b17c1146e00 upstream.

drivers/net/ethernet/sfc/selftest.c: In function ‘efx_iterate_state’:
drivers/net/ethernet/sfc/selftest.c:388:9: warning: passing argument 1 of ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]

This is because the msg[] member of struct efx_loopback_payload is marked as 'const'. Remove that.

---
 drivers/net/ethernet/sfc/selftest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/sfc/selftest.c +1 -1
index 144bbff5a4ae..1a5cb0cadfda 100644
@@ -46,7 +46,7 @@ struct efx_loopback_payload {
 	struct iphdr ip;
 	struct udphdr udp;
 	__be16 iteration;
-	const char msg[64];
+	char msg[64];
 } __packed;
 
 /* Loopback test source MAC address */
Signature · 1 line
2.6.3
author
#10 lore raw

PATCH 10/72 power: bq24190_charger: suppress build warning

In reply to Jiri Slaby

From: "Lad, Prabhakar" <[email protected]>

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

===============

commit 31f50e48e3e4ea9d503285a389d6a1b5349d66c0 upstream.

This patch fixes following build warning:

In file included from include/linux/printk.h:261:0,

                 from include/linux/kernel.h:13,
                 from include/linux/list.h:8,
                 from include/linux/module.h:9,
                 from drivers/power/bq24190_charger.c:11:
drivers/power/bq24190_charger.c: In function ‘bq24190_irq_handler_thread’:
include/linux/dynamic_debug.h:86:20: warning: ‘ss_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                    ^
drivers/power/bq24190_charger.c:1211:5: note: ‘ss_reg’ was declared here
  u8 ss_reg, f_reg;
     ^
In file included from include/linux/printk.h:261:0,
                 from include/linux/kernel.h:13,
                 from include/linux/list.h:8,
                 from include/linux/module.h:9,
                 from drivers/power/bq24190_charger.c:11:
include/linux/dynamic_debug.h:86:20: warning: ‘f_reg’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   __dynamic_dev_dbg(&descriptor, dev, fmt, \
                    ^

drivers/power/bq24190_charger.c:1211:13: note: ‘f_reg’ was declared here
u8 ss_reg, f_reg;

---
 drivers/power/bq24190_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/power/bq24190_charger.c +1 -1
index e4c95e1a6733..d0e8236a6404 100644
@@ -1208,7 +1208,7 @@ static irqreturn_t bq24190_irq_handler_thread(int irq, void *data)
 {
 	struct bq24190_dev_info *bdi = data;
 	bool alert_userspace = false;
-	u8 ss_reg, f_reg;
+	u8 ss_reg = 0, f_reg = 0;
 	int ret;
 
 	pm_runtime_get_sync(bdi->dev);
Signature · 1 line
2.6.3
author
#11 lore raw

PATCH 11/72 spi: fix pointer-integer size mismatch warning

From: SeongJae Park <[email protected]>

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

===============

commit e1bde3b11fedace5042f0232339da90bc85666af upstream.

Fix the pointer-integer size mismatch warning below:
drivers/spi/spi-gpio.c: In function ‘spi_gpio_setup’:
drivers/spi/spi-gpio.c:252:8: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
cs = (unsigned int) spi->controller_data;
^

---
 drivers/spi/spi-gpio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/spi/spi-gpio.c +1 -1
index 68b69fec13a9..64cebdb0a8b6 100644
@@ -249,7 +249,7 @@ static int spi_gpio_setup(struct spi_device *spi)
 		/*
 		 * ... otherwise, take it from spi->controller_data
 		 */
-		cs = (unsigned int) spi->controller_data;
+		cs = (unsigned int)(uintptr_t) spi->controller_data;
 	}
 
 	if (!spi->controller_state) {
Signature · 1 line
2.6.3
author
#12 lore raw

PATCH 12/72 drm/nouveau/gem: return only valid domain when there's only one

In reply to Jiri Slaby

From: Ilia Mirkin <[email protected]>

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

===============

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

---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_gem.c +3 -2
index d2dfdf7663c2..152d39daac3e 100644
@@ -205,11 +205,12 @@ nouveau_gem_info(struct drm_file *file_priv, struct drm_gem_object *gem,
 	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);
Signature · 1 line
2.6.3
author
#13 lore raw

PATCH 13/72 rbd: require stable pages if message data CRCs are enabled

In reply to Jiri Slaby

From: Ronny Hegewald <[email protected]>

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

===============

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).

[[email protected]: require stable pages only in crc case, changelog]
[[email protected]: backport to 3.9-3.17: context]
---
 drivers/block/rbd.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/block/rbd.c +3 -0
index 66f632730969..6d3ec00ba845 100644
@@ -3441,6 +3441,9 @@ static int rbd_init_disk(struct rbd_device *rbd_dev)
 	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;
Signature · 1 line
2.6.3
author
#14 lore raw

PATCH 14/72 Revert "ARM64: unwind: Fix PC calculation"

In reply to Jiri Slaby

From: Will Deacon <[email protected]>

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

===============

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.

---
 arch/arm64/kernel/stacktrace.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)
arch/arm64/kernel/stacktrace.c +1 -5
index 048334bb2651..d25459ff57fc 100644
@@ -48,11 +48,7 @@ int unwind_frame(struct stackframe *frame)
 
 	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;
 }
Signature · 1 line
2.6.3
author
#15 lore raw

PATCH 15/72 dm btree: fix leak of bufio-backed block in btree_split_beneath error path

In reply to Jiri Slaby

From: Mike Snitzer <[email protected]>

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

===============

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().

---
 drivers/md/persistent-data/dm-btree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/persistent-data/dm-btree.c +1 -1
index 50cf11119af9..fc3d733aab1c 100644
@@ -523,7 +523,7 @@ static int btree_split_beneath(struct shadow_spine *s, uint64_t key)
 
 	r = new_block(s->info, &right);
 	if (r < 0) {
-		/* FIXME: put left */
+		unlock_block(s->info, left);
 		return r;
 	}
 
Signature · 1 line
2.6.3
author
#16 lore raw

PATCH 16/72 xhci: handle no ping response error properly

In reply to Jiri Slaby

From: Mathias Nyman <[email protected]>

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

===============

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.

---
 drivers/usb/host/xhci-ring.c | 20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)
drivers/usb/host/xhci-ring.c +15 -5
index ad381c22e5ac..2c9d2c33b834 100644
@@ -2387,6 +2387,7 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 	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];
@@ -2520,6 +2521,10 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 		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;
@@ -2651,13 +2656,18 @@ static int handle_tx_event(struct xhci_hcd *xhci,
 						 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;
@@ -2692,7 +2702,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;
 }
Signature · 1 line
2.6.3
author
#17 lore raw

PATCH 17/72 xhci: Add spurious wakeup quirk for LynxPoint-LP controllers

In reply to Jiri Slaby

From: Laura Abbott <[email protected]>

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

===============

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.

Cc Takashi Iwai <[email protected]>
Cc Oliver Neukum <[email protected]>
[Added more history to commit message -Mathias]
---
 drivers/usb/host/xhci-pci.c | 1 +
 1 file changed, 1 insertion(+)
drivers/usb/host/xhci-pci.c +1 -0
index 68b8bc2e82d9..aedc7e479a23 100644
@@ -131,6 +131,7 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
 	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
 		pdev->device == PCI_DEVICE_ID_INTEL_LYNXPOINT_LP_XHCI) {
 		xhci->quirks |= XHCI_SPURIOUS_REBOOT;
+		xhci->quirks |= XHCI_SPURIOUS_WAKEUP;
 	}
 	if (pdev->vendor == PCI_VENDOR_ID_INTEL &&
 		(pdev->device == PCI_DEVICE_ID_INTEL_SUNRISEPOINT_LP_XHCI ||
Signature · 1 line
2.6.3
author
#18 lore raw

PATCH 18/72 xen-blkfront: check for null drvdata in blkback_changed (XenbusStateClosing)

In reply to Jiri Slaby

From: Cathy Avery <[email protected]>

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

===============

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.

---
 drivers/block/xen-blkfront.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/block/xen-blkfront.c +2 -1
index 7d0eb3f8d629..0b6932c376fb 100644
@@ -1965,7 +1965,8 @@ static void blkback_changed(struct xenbus_device *dev,
 			break;
 		/* Missed the backend's Closing state -- fallthrough */
 	case XenbusStateClosing:
-		blkfront_closing(info);
+		if (info)
+			blkfront_closing(info);
 		break;
 	}
 }
Signature · 1 line
2.6.3
author
#19 lore raw

PATCH 19/72 module: Fix locking in symbol_put_addr()

In reply to Jiri Slaby

From: Peter Zijlstra <[email protected]>

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

===============

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().

Fixes a6e6abd575fc ("module: remove module_text_address()")
---
 kernel/module.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)
kernel/module.c +6 -2
index a97785308f25..3e3f90d82ecc 100644
@@ -950,11 +950,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);
 
Signature · 1 line
2.6.3
author
#20 lore raw

PATCH 20/72 crypto: api - Only abort operations on fatal signal

In reply to Jiri Slaby

From: Herbert Xu <[email protected]>

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

===============

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.

---
 crypto/ablkcipher.c  | 2 +-
 crypto/algapi.c      | 2 +-
 crypto/api.c         | 6 +++---
 crypto/crypto_user.c | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)
crypto/ablkcipher.c +1 -1
index 7d4a8d28277e..ebcec7439a1a 100644
@@ -700,7 +700,7 @@ struct crypto_ablkcipher *crypto_alloc_ablkcipher(const char *alg_name,
 err:
 		if (err != -EAGAIN)
 			break;
-		if (signal_pending(current)) {
+		if (fatal_signal_pending(current)) {
 			err = -EINTR;
 			break;
 		}
crypto/algapi.c +1 -1
index 00d8d939733b..daf2f653b131 100644
@@ -325,7 +325,7 @@ static void crypto_wait_for_test(struct crypto_larval *larval)
 		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:
crypto/api.c +3 -3
index 2a81e98a0021..7db2e89a3114 100644
@@ -172,7 +172,7 @@ static struct crypto_alg *crypto_larval_wait(struct crypto_alg *alg)
 	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(const char *alg_name, u32 type, u32 mask)
 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_name,
 err:
 		if (err != -EAGAIN)
 			break;
-		if (signal_pending(current)) {
+		if (fatal_signal_pending(current)) {
 			err = -EINTR;
 			break;
 		}
crypto/crypto_user.c +1 -1
index 43665d0d0905..c7666f401381 100644
@@ -361,7 +361,7 @@ static struct crypto_alg *crypto_user_aead_alg(const char *name, u32 type,
 		err = PTR_ERR(alg);
 		if (err != -EAGAIN)
 			break;
-		if (signal_pending(current)) {
+		if (fatal_signal_pending(current)) {
 			err = -EINTR;
 			break;
 		}
Signature · 1 line
2.6.3
author
#21 lore raw

PATCH 21/72 md/raid1: submit_bio_wait() returns 0 on success

In reply to Jiri Slaby

From: Jes Sorensen <[email protected]>

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

===============

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")
---
 drivers/md/raid1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/raid1.c +1 -1
index 1cb7642c1ba9..479828ad2021 100644
@@ -2148,7 +2148,7 @@ static int narrow_write_error(struct r1bio *r1_bio, int i)
 		md_trim_bio(wbio, sector - r1_bio->sector, sectors);
 		wbio->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)
Signature · 1 line
2.6.3
author
#22 lore raw

PATCH 22/72 md/raid10: submit_bio_wait() returns 0 on success

In reply to Jiri Slaby

From: Jes Sorensen <[email protected]>

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

===============

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")
---
 drivers/md/raid10.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/md/raid10.c +1 -1
index d525d663bb22..98c856dd8ccc 100644
@@ -2618,7 +2618,7 @@ static int narrow_write_error(struct r10bio *r10_bio, int i)
 				   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)
Signature · 1 line
2.6.3
author
#23 lore raw

PATCH 23/72 mvsas: Fix NULL pointer dereference in mvs_slot_task_free

In reply to Jiri Slaby

From: Dāvis Mosāns <[email protected]>

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

===============

commit 2280521719e81919283b82902ac24058f87dfc1b upstream.

When pci_pool_alloc fails in mvs_task_prep then task->lldd_task stays NULL but it's later used in mvs_abort_task as slot which is passed to mvs_slot_task_free causing NULL pointer dereference.

Just return from mvs_slot_task_free when passed with NULL slot.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101891

---
 drivers/scsi/mvsas/mv_sas.c | 2 ++
 1 file changed, 2 insertions(+)
drivers/scsi/mvsas/mv_sas.c +2 -0
index 1aa2a8cbb4df..783288db47c0 100644
@@ -988,6 +988,8 @@ static void mvs_slot_free(struct mvs_info *mvi, u32 rx_desc)
 static void mvs_slot_task_free(struct mvs_info *mvi, struct sas_task *task,
 			  struct mvs_slot_info *slot, u32 slot_idx)
 {
+	if (!slot)
+		return;
 	if (!slot->task)
 		return;
 	if (!sas_protocol_ata(task->task_proto))
Signature · 1 line
2.6.3
author
#24 lore raw

PATCH 24/72 IB/cm: Fix rb-tree duplicate free and use-after-free

In reply to Jiri Slaby

From: Doron Tsur <[email protected]>

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

===============

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')
---
 drivers/infiniband/core/cm.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/infiniband/core/cm.c +9 -1
index 784b97cb05b0..c410217fbe89 100644
@@ -857,6 +857,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);
@@ -3093,7 +3098,10 @@ int ib_send_cm_sidr_rep(struct ib_cm_id *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;
 
Signature · 1 line
2.6.3
author
#25 lore raw

PATCH 25/72 serial: 8250_pci: Add support for 16 port Exar boards

In reply to Jiri Slaby

From: Soeren Grunewald <[email protected]>

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

===============

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

---
 drivers/tty/serial/8250/8250_pci.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_pci.c +23 -2
index eac50ec4c70d..bdbfb25ace6d 100644
@@ -1574,6 +1574,8 @@ pci_wch_ch353_setup(struct serial_private *priv,
 #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
@@ -2029,6 +2031,13 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
 		.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
 	 */
@@ -2456,6 +2465,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,
@@ -3121,6 +3131,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,
@@ -4454,7 +4472,7 @@ static struct pci_device_id serial_pci_tbl[] = {
 		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,
@@ -4468,7 +4486,10 @@ static struct pci_device_id serial_pci_tbl[] = {
 		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)
 	 */
Signature · 1 line
2.6.3
#26 lore raw

Re: [PATCH 3.12 25/72] serial: 8250_pci: Add support for 16 port Exar boards

Dear Jiri,

You should also add upstream commit 899f0c1c7dbcc487fdc8756a49ff70b1d5d75f89

Greg had a merge conflict in 4-1.y with another back-ported patch. But in 3.12 this shouldn't be the case.

Signature · 2 lines
Cheers,
Soeren
Quoted 98 lines · Jiri Slaby

From: Soeren Grunewald <[email protected]>

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

===============

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

---
  drivers/tty/serial/8250/8250_pci.c | 25 +++++++++++++++++++++++--
  1 file changed, 23 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_pci.c +23 -2
index eac50ec4c70d..bdbfb25ace6d 100644
@@ -1574,6 +1574,8 @@ pci_wch_ch353_setup(struct serial_private *priv,
  #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
@@ -2029,6 +2031,13 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
  		.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
  	 */
@@ -2456,6 +2465,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,
@@ -3121,6 +3131,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,
@@ -4454,7 +4472,7 @@ static struct pci_device_id serial_pci_tbl[] = {
  		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,
@@ -4468,7 +4486,10 @@ static struct pci_device_id serial_pci_tbl[] = {
  		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)
  	 */
author
#27 lore raw

PATCH 26/72 serial: 8250_pci: Add support for 12 port Exar boards

In reply to Jiri Slaby

From: Soeren Grunewald <[email protected]>

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

===============

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.

---
 drivers/tty/serial/8250/8250_pci.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
drivers/tty/serial/8250/8250_pci.c +21 -0
index bdbfb25ace6d..ebb823cc9140 100644
@@ -1574,6 +1574,7 @@ pci_wch_ch353_setup(struct serial_private *priv,
 #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 */
@@ -2033,6 +2034,13 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
 	},
 	{
 		.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,
@@ -2465,6 +2473,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,
@@ -3131,6 +3140,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,
@@ -4486,6 +4503,10 @@ static struct pci_device_id serial_pci_tbl[] = {
 		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,
Signature · 1 line
2.6.3
author
#28 lore raw

PATCH 27/72 mfd: wm5110: Add register patch for rev D chip

In reply to Jiri Slaby

From: Charles Keepax <[email protected]>

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

===============

commit 02915661dbb91b25b621ab3f387ab55311bded7f upstream.

Evaluation of revision D of WM5110 suggests updates to the register patch for optimal performance. For the sake of clarity rev C of the chip does not require a register patch.

---
 drivers/mfd/wm5110-tables.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)
drivers/mfd/wm5110-tables.c +29 -1
index 3113e39b318e..f1854d5aa55f 100644
@@ -223,6 +223,31 @@ static const struct reg_default wm5110_revb_patch[] = {
 	{ 0x80, 0x0 },
 };
 
+static const struct reg_default wm5110_revd_patch[] = {
+	{ 0x80, 0x3 },
+	{ 0x80, 0x3 },
+	{ 0x393, 0x27 },
+	{ 0x394, 0x27 },
+	{ 0x395, 0x27 },
+	{ 0x396, 0x27 },
+	{ 0x397, 0x27 },
+	{ 0x398, 0x26 },
+	{ 0x221, 0x90 },
+	{ 0x211, 0x8 },
+	{ 0x36c, 0x1fb },
+	{ 0x26e, 0x64 },
+	{ 0x26f, 0xea },
+	{ 0x270, 0x1f16 },
+	{ 0x51b, 0x1 },
+	{ 0x55b, 0x1 },
+	{ 0x59b, 0x1 },
+	{ 0x4f0, 0x633 },
+	{ 0x441, 0xc059 },
+	{ 0x209, 0x27 },
+	{ 0x80, 0x0 },
+	{ 0x80, 0x0 },
+};
+
 /* We use a function so we can use ARRAY_SIZE() */
 int wm5110_patch(struct arizona *arizona)
 {
@@ -235,7 +260,10 @@ int wm5110_patch(struct arizona *arizona)
 		return regmap_register_patch(arizona->regmap,
 					     wm5110_revb_patch,
 					     ARRAY_SIZE(wm5110_revb_patch));
-
+	case 3:
+		return regmap_register_patch(arizona->regmap,
+					     wm5110_revd_patch,
+					     ARRAY_SIZE(wm5110_revd_patch));
 	default:
 		return 0;
 	}
Signature · 1 line
2.6.3
author
#29 lore raw

PATCH 28/72 mfd: wm5110: Add register patch for rev E and above

In reply to Jiri Slaby

From: Charles Keepax <[email protected]>

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

===============

commit 81207880cef207cd89db863f9aa1d65f22b4f2a2 upstream.

Add a register patch for rev E and above that configures the location of some write sequences to assist with the headphone enables.

---
 drivers/mfd/wm5110-tables.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)
drivers/mfd/wm5110-tables.c +13 -1
index f1854d5aa55f..154e4cadecf6 100644
@@ -248,6 +248,16 @@ static const struct reg_default wm5110_revd_patch[] = {
 	{ 0x80, 0x0 },
 };
 
+/* Add extra headphone write sequence locations */
+static const struct reg_default wm5110_reve_patch[] = {
+	{ 0x80, 0x3 },
+	{ 0x80, 0x3 },
+	{ 0x4b, 0x138 },
+	{ 0x4c, 0x13d },
+	{ 0x80, 0x0 },
+	{ 0x80, 0x0 },
+};
+
 /* We use a function so we can use ARRAY_SIZE() */
 int wm5110_patch(struct arizona *arizona)
 {
@@ -265,7 +275,9 @@ int wm5110_patch(struct arizona *arizona)
 					     wm5110_revd_patch,
 					     ARRAY_SIZE(wm5110_revd_patch));
 	default:
-		return 0;
+		return regmap_register_patch(arizona->regmap,
+					     wm5110_reve_patch,
+					     ARRAY_SIZE(wm5110_reve_patch));
 	}
 }
 EXPORT_SYMBOL_GPL(wm5110_patch);
Signature · 1 line
2.6.3
author
#30 lore raw

PATCH 29/72 mptfusion: prevent some memory corruption

In reply to Jiri Slaby

From: Dan Carpenter <[email protected]>

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

===============

commit e819cdb198319cccf4af4fc12ac4d796109d8c23 upstream.

These are signed values the come from the user, we put a cap on the upper bounds but not on the lower bounds.

We use "karg.dataSgeOffset" to calculate "sz". We verify "sz" and proceed as if that means that "karg.dataSgeOffset" is correct but this fails to consider that the "sz" calculations can have integer overflows.

---
 drivers/message/fusion/mptctl.c | 9 +++++++++
 1 file changed, 9 insertions(+)
drivers/message/fusion/mptctl.c +9 -0
index dcc8385adeb3..39e824f65f5c 100644
@@ -1872,6 +1872,15 @@ mptctl_do_mpt_command (struct mpt_ioctl_command karg, void __user *mfPtr)
 	}
 	spin_unlock_irqrestore(&ioc->taskmgmt_lock, flags);
 
+	/* Basic sanity checks to prevent underflows or integer overflows */
+	if (karg.maxReplyBytes < 0 ||
+	    karg.dataInSize < 0 ||
+	    karg.dataOutSize < 0 ||
+	    karg.dataSgeOffset < 0 ||
+	    karg.maxSenseBytes < 0 ||
+	    karg.dataSgeOffset > ioc->req_sz / 4)
+		return -EINVAL;
+
 	/* Verify that the final request frame will not be too large.
 	 */
 	sz = karg.dataSgeOffset * 4;
Signature · 1 line
2.6.3
author
#31 lore raw

PATCH 30/72 audit: correctly record file names with different path name types

In reply to Jiri Slaby

From: Paul Moore <[email protected]>

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

===============

commit 4a92843601ad0f5067f441d2f0dca55bbe18c076 upstream.

There is a problem with the audit system when multiple audit records are created for the same path, each with a different path name type. The root cause of the problem is in __audit_inode() when an exact match (both the path name and path name type) is not found for a path name record; the existing code creates a new path name record, but it never sets the path name in this record, leaving it NULL. This patch corrects this problem by assigning the path name to these newly created records.

There are many ways to reproduce this problem, but one of the easiest is the following (assuming auditd is running):

  # mkdir /root/tmp/test
  # touch /root/tmp/test/567
  # auditctl -a always,exit -F dir=/root/tmp/test
  # touch /root/tmp/test/567

Afterwards, or while the commands above are running, check the audit log and pay special attention to the PATH records. A faulty kernel will display something like the following for the file creation:

type=SYSCALL msg=audit(1416957442.025:93): arch=c000003e syscall=2

    success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
  type=CWD msg=audit(1416957442.025:93):  cwd="/root/tmp"
  type=PATH msg=audit(1416957442.025:93): item=0 name="test/"
    inode=401409 ... nametype=PARENT
  type=PATH msg=audit(1416957442.025:93): item=1 name=(null)
    inode=393804 ... nametype=NORMAL
  type=PATH msg=audit(1416957442.025:93): item=2 name=(null)
    inode=393804 ... nametype=NORMAL

While a patched kernel will show the following:

type=SYSCALL msg=audit(1416955786.566:89): arch=c000003e syscall=2

    success=yes exit=3 ... comm="touch" exe="/usr/bin/touch"
  type=CWD msg=audit(1416955786.566:89):  cwd="/root/tmp"
  type=PATH msg=audit(1416955786.566:89): item=0 name="test/"
    inode=401409 ... nametype=PARENT
  type=PATH msg=audit(1416955786.566:89): item=1 name="test/567"
    inode=393804 ... nametype=NORMAL

This issue was brought up by a number of people, but special credit should go to [email protected] for reporting the problem along with an explanation of the problem and a patch. While the original patch did have some problems (see the archive link below), it did demonstrate the problem and helped kickstart the fix presented here.

* https://lkml.org/lkml/2014/9/5/66

---
 kernel/auditsc.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)
kernel/auditsc.c +10 -4
index 979c00bf24aa..24bec1d98074 100644
@@ -1834,12 +1834,18 @@ void __audit_inode(struct filename *name, const struct dentry *dentry,
 	}
 
 out_alloc:
-	/* unable to find the name from a previous getname(). Allocate a new
-	 * anonymous entry.
-	 */
-	n = audit_alloc_name(context, AUDIT_TYPE_NORMAL);
+	/* unable to find an entry with both a matching name and type */
+	n = audit_alloc_name(context, AUDIT_TYPE_UNKNOWN);
 	if (!n)
 		return;
+	if (name)
+		/* since name is not NULL we know there is already a matching
+		 * name record, see audit_getname(), so there must be a type
+		 * mismatch; reuse the string path since the original name
+		 * record will keep the string valid until we free it in
+		 * audit_free_names() */
+		n->name = name;
+
 out:
 	if (parent) {
 		n->name_len = n->name ? parent_len(n->name->name) : AUDIT_NAME_FULL;
Signature · 1 line
2.6.3
author
#32 lore raw

PATCH 31/72 audit: create private file name copies when auditing inodes

In reply to Jiri Slaby

From: Paul Moore <[email protected]>

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

===============

commit fcf22d8267ad2601fe9b6c549d1be96401c23e0b upstream.

Unfortunately, while commit 4a928436 ("audit: correctly record file names with different path name types") fixed a problem where we were not recording filenames, it created a new problem by attempting to use these file names after they had been freed. This patch resolves the issue by creating a copy of the filename which the audit subsystem frees after it is done with the string.

At some point it would be nice to resolve this issue with refcounts, or something similar, instead of having to allocate/copy strings, but that is almost surely beyond the scope of a -rcX patch so we'll defer that for later. On the plus side, only audit users should be impacted by the string copying.

---
 kernel/auditsc.c | 51 +++++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 41 insertions(+), 10 deletions(-)
kernel/auditsc.c +41 -10
index 24bec1d98074..8847de2b3c68 100644
@@ -68,6 +68,8 @@
 #include <linux/capability.h>
 #include <linux/fs_struct.h>
 #include <linux/compat.h>
+#include <linux/string.h>
+#include <uapi/linux/limits.h>
 
 #include "audit.h"
 
@@ -1818,8 +1820,7 @@ void __audit_inode(struct filename *name, const struct dentry *dentry,
 	}
 
 	list_for_each_entry_reverse(n, &context->names_list, list) {
-		/* does the name pointer match? */
-		if (!n->name || n->name->name != name->name)
+		if (!n->name || strcmp(n->name->name, name->name))
 			continue;
 
 		/* match the correct record type */
@@ -1838,14 +1839,44 @@ out_alloc:
 	n = audit_alloc_name(context, AUDIT_TYPE_UNKNOWN);
 	if (!n)
 		return;
-	if (name)
-		/* since name is not NULL we know there is already a matching
-		 * name record, see audit_getname(), so there must be a type
-		 * mismatch; reuse the string path since the original name
-		 * record will keep the string valid until we free it in
-		 * audit_free_names() */
-		n->name = name;
-
+	/* unfortunately, while we may have a path name to record with the
+	 * inode, we can't always rely on the string lasting until the end of
+	 * the syscall so we need to create our own copy, it may fail due to
+	 * memory allocation issues, but we do our best */
+	if (name) {
+		/* we can't use getname_kernel() due to size limits */
+		size_t len = strlen(name->name) + 1;
+		struct filename *new = __getname();
+
+		if (unlikely(!new))
+			goto out;
+
+		if (len <= (PATH_MAX - sizeof(*new))) {
+			new->name = (char *)(new) + sizeof(*new);
+			new->separate = false;
+		} else if (len <= PATH_MAX) {
+			/* this looks odd, but is due to final_putname() */
+			struct filename *new2;
+
+			new2 = kmalloc(sizeof(*new2), GFP_KERNEL);
+			if (unlikely(!new2)) {
+				__putname(new);
+				goto out;
+			}
+			new2->name = (char *)new;
+			new2->separate = true;
+			new = new2;
+		} else {
+			/* we should never get here, but let's be safe */
+			__putname(new);
+			goto out;
+		}
+		strlcpy((char *)new->name, name->name, len);
+		new->uptr = NULL;
+		new->aname = n;
+		n->name = new;
+		n->name_put = true;
+	}
 out:
 	if (parent) {
 		n->name_len = n->name ? parent_len(n->name->name) : AUDIT_NAME_FULL;
Signature · 1 line
2.6.3
author
#33 lore raw

PATCH 32/72 libahci: Allow drivers to override start_engine

In reply to Jiri Slaby

From: Hans de Goede <[email protected]>

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

===============

commit 039ece38da45f5e6a94be3aa7611cf3634bc2461 upstream.

Allwinner A10 and A20 ARM SoCs have an AHCI sata controller which needs a special register to be poked before starting the DMA engine.

This register gets reset on an ahci_stop_engine call, so there is no other place then ahci_start_engine where this poking can be done.

This commit allows drivers to override ahci_start_engine behavior for use by the Allwinner AHCI driver (and potentially other drivers in the future).

---
 drivers/ata/ahci.c          |  6 ++++--
 drivers/ata/ahci.h          |  6 ++++++
 drivers/ata/libahci.c       | 26 +++++++++++++++++++-------
 drivers/ata/sata_highbank.c |  3 ++-
 4 files changed, 31 insertions(+), 10 deletions(-)
drivers/ata/ahci.c +4 -2
index 53111fd27ebb..548bf80a70e3 100644
@@ -608,6 +608,7 @@ static int ahci_vt8251_hardreset(struct ata_link *link, unsigned int *class,
 				 unsigned long deadline)
 {
 	struct ata_port *ap = link->ap;
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	bool online;
 	int rc;
 
@@ -618,7 +619,7 @@ static int ahci_vt8251_hardreset(struct ata_link *link, unsigned int *class,
 	rc = sata_link_hardreset(link, sata_ehc_deb_timing(&link->eh_context),
 				 deadline, &online, NULL);
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 
 	DPRINTK("EXIT, rc=%d, class=%u\n", rc, *class);
 
@@ -633,6 +634,7 @@ static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
 {
 	struct ata_port *ap = link->ap;
 	struct ahci_port_priv *pp = ap->private_data;
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
 	struct ata_taskfile tf;
 	bool online;
@@ -648,7 +650,7 @@ static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
 	rc = sata_link_hardreset(link, sata_ehc_deb_timing(&link->eh_context),
 				 deadline, &online, NULL);
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 
 	/* The pseudo configuration device on SIMG4726 attached to
 	 * ASUS P5W-DH Deluxe doesn't send signature FIS after
drivers/ata/ahci.h +6 -0
index 11456371f29b..e06ac08754bb 100644
@@ -323,6 +323,12 @@ struct ahci_host_priv {
 	u32			em_msg_type;	/* EM message type */
 	struct clk		*clk;		/* Only for platforms supporting clk */
 	void			*plat_data;	/* Other platform data */
+	/*
+	 * Optional ahci_start_engine override, if not set this gets set to the
+	 * default ahci_start_engine during ahci_save_initial_config, this can
+	 * be overridden anytime before the host is activated.
+	 */
+	void			(*start_engine)(struct ata_port *ap);
 };
 
 extern int ahci_ignore_sss;
drivers/ata/libahci.c +19 -7
index 9764d9c0447e..07b3f90306fb 100644
@@ -394,6 +394,9 @@ static ssize_t ahci_show_em_supported(struct device *dev,
  *
  *	If inconsistent, config values are fixed up by this function.
  *
+ *	If it is not set already this function sets hpriv->start_engine to
+ *	ahci_start_engine.
+ *
  *	LOCKING:
  *	None.
  */
@@ -500,6 +503,9 @@ void ahci_save_initial_config(struct device *dev,
 	hpriv->cap = cap;
 	hpriv->cap2 = cap2;
 	hpriv->port_map = port_map;
+
+	if (!hpriv->start_engine)
+		hpriv->start_engine = ahci_start_engine;
 }
 EXPORT_SYMBOL_GPL(ahci_save_initial_config);
 
@@ -766,7 +772,7 @@ static void ahci_start_port(struct ata_port *ap)
 
 	/* enable DMA */
 	if (!(hpriv->flags & AHCI_HFLAG_DELAY_ENGINE))
-		ahci_start_engine(ap);
+		hpriv->start_engine(ap);
 
 	/* turn on LEDs */
 	if (ap->flags & ATA_FLAG_EM) {
@@ -1234,7 +1240,7 @@ int ahci_kick_engine(struct ata_port *ap)
 
 	/* restart engine */
  out_restart:
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 	return rc;
 }
 EXPORT_SYMBOL_GPL(ahci_kick_engine);
@@ -1426,6 +1432,7 @@ static int ahci_hardreset(struct ata_link *link, unsigned int *class,
 	const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
 	struct ata_port *ap = link->ap;
 	struct ahci_port_priv *pp = ap->private_data;
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
 	struct ata_taskfile tf;
 	bool online;
@@ -1443,7 +1450,7 @@ static int ahci_hardreset(struct ata_link *link, unsigned int *class,
 	rc = sata_link_hardreset(link, timing, deadline, &online,
 				 ahci_check_ready);
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 
 	if (online)
 		*class = ahci_dev_classify(ap);
@@ -2006,10 +2013,12 @@ static void ahci_thaw(struct ata_port *ap)
 
 static void ahci_error_handler(struct ata_port *ap)
 {
+	struct ahci_host_priv *hpriv = ap->host->private_data;
+
 	if (!(ap->pflags & ATA_PFLAG_FROZEN)) {
 		/* restart engine */
 		ahci_stop_engine(ap);
-		ahci_start_engine(ap);
+		hpriv->start_engine(ap);
 	}
 
 	sata_pmp_error_handler(ap);
@@ -2029,6 +2038,7 @@ static void ahci_post_internal_cmd(struct ata_queued_cmd *qc)
 
 static void ahci_set_aggressive_devslp(struct ata_port *ap, bool sleep)
 {
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	void __iomem *port_mmio = ahci_port_base(ap);
 	struct ata_device *dev = ap->link.device;
 	u32 devslp, dm, dito, mdat, deto;
@@ -2092,7 +2102,7 @@ static void ahci_set_aggressive_devslp(struct ata_port *ap, bool sleep)
 		   PORT_DEVSLP_ADSE);
 	writel(devslp, port_mmio + PORT_DEVSLP);
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 
 	/* enable device sleep feature for the drive */
 	err_mask = ata_dev_set_feature(dev,
@@ -2104,6 +2114,7 @@ static void ahci_set_aggressive_devslp(struct ata_port *ap, bool sleep)
 
 static void ahci_enable_fbs(struct ata_port *ap)
 {
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	struct ahci_port_priv *pp = ap->private_data;
 	void __iomem *port_mmio = ahci_port_base(ap);
 	u32 fbs;
@@ -2132,11 +2143,12 @@ static void ahci_enable_fbs(struct ata_port *ap)
 	} else
 		dev_err(ap->host->dev, "Failed to enable FBS\n");
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 }
 
 static void ahci_disable_fbs(struct ata_port *ap)
 {
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	struct ahci_port_priv *pp = ap->private_data;
 	void __iomem *port_mmio = ahci_port_base(ap);
 	u32 fbs;
@@ -2164,7 +2176,7 @@ static void ahci_disable_fbs(struct ata_port *ap)
 		pp->fbs_enabled = false;
 	}
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 }
 
 static void ahci_pmp_attach(struct ata_port *ap)
drivers/ata/sata_highbank.c +2 -1
index 7f5e5d96327f..fa402bbbb4d4 100644
@@ -406,6 +406,7 @@ static int ahci_highbank_hardreset(struct ata_link *link, unsigned int *class,
 	static const unsigned long timing[] = { 5, 100, 500};
 	struct ata_port *ap = link->ap;
 	struct ahci_port_priv *pp = ap->private_data;
+	struct ahci_host_priv *hpriv = ap->host->private_data;
 	u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
 	struct ata_taskfile tf;
 	bool online;
@@ -434,7 +435,7 @@ static int ahci_highbank_hardreset(struct ata_link *link, unsigned int *class,
 			break;
 	} while (!online && retry--);
 
-	ahci_start_engine(ap);
+	hpriv->start_engine(ap);
 
 	if (online)
 		*class = ahci_dev_classify(ap);
Signature · 1 line
2.6.3
author
#34 lore raw

PATCH 33/72 ahci: avoton port-disable reset-quirk

In reply to Jiri Slaby

From: Dan Williams <[email protected]>

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

===============

commit dbfe8ef5599a5370abc441fcdbb382b656563eb4 upstream.

Avoton AHCI occasionally sees drive probe timeouts at driver load time. When this happens SCR_STATUS indicates device detected, but no D2H FIS reception. Reset the internal link state machines by bouncing port-enable in the PCS register when this occurs.

---
 drivers/ata/ahci.c | 103 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 95 insertions(+), 8 deletions(-)
drivers/ata/ahci.c +95 -8
index 548bf80a70e3..f354867a3b95 100644
@@ -67,6 +67,7 @@ enum board_ids {
 	board_ahci_yes_fbs,
 
 	/* board IDs for specific chipsets in alphabetical order */
+	board_ahci_avn,
 	board_ahci_mcp65,
 	board_ahci_mcp77,
 	board_ahci_mcp89,
@@ -85,6 +86,8 @@ enum board_ids {
 static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent);
 static int ahci_vt8251_hardreset(struct ata_link *link, unsigned int *class,
 				 unsigned long deadline);
+static int ahci_avn_hardreset(struct ata_link *link, unsigned int *class,
+			      unsigned long deadline);
 static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
 				unsigned long deadline);
 #ifdef CONFIG_PM
@@ -106,6 +109,11 @@ static struct ata_port_operations ahci_p5wdh_ops = {
 	.hardreset		= ahci_p5wdh_hardreset,
 };
 
+static struct ata_port_operations ahci_avn_ops = {
+	.inherits		= &ahci_ops,
+	.hardreset		= ahci_avn_hardreset,
+};
+
 static const struct ata_port_info ahci_port_info[] = {
 	/* by features */
 	[board_ahci] = {
@@ -150,6 +158,12 @@ static const struct ata_port_info ahci_port_info[] = {
 		.port_ops	= &ahci_ops,
 	},
 	/* by chipsets */
+	[board_ahci_avn] = {
+		.flags		= AHCI_FLAG_COMMON,
+		.pio_mask	= ATA_PIO4,
+		.udma_mask	= ATA_UDMA6,
+		.port_ops	= &ahci_avn_ops,
+	},
 	[board_ahci_mcp65] = {
 		AHCI_HFLAGS	(AHCI_HFLAG_NO_FPDMA_AA | AHCI_HFLAG_NO_PMP |
 				 AHCI_HFLAG_YES_NCQ),
@@ -289,14 +303,14 @@ static const struct pci_device_id ahci_pci_tbl[] = {
 	{ PCI_VDEVICE(INTEL, 0x1f27), board_ahci }, /* Avoton RAID */
 	{ PCI_VDEVICE(INTEL, 0x1f2e), board_ahci }, /* Avoton RAID */
 	{ PCI_VDEVICE(INTEL, 0x1f2f), board_ahci }, /* Avoton RAID */
-	{ PCI_VDEVICE(INTEL, 0x1f32), board_ahci }, /* Avoton AHCI */
-	{ PCI_VDEVICE(INTEL, 0x1f33), board_ahci }, /* Avoton AHCI */
-	{ PCI_VDEVICE(INTEL, 0x1f34), board_ahci }, /* Avoton RAID */
-	{ PCI_VDEVICE(INTEL, 0x1f35), board_ahci }, /* Avoton RAID */
-	{ PCI_VDEVICE(INTEL, 0x1f36), board_ahci }, /* Avoton RAID */
-	{ PCI_VDEVICE(INTEL, 0x1f37), board_ahci }, /* Avoton RAID */
-	{ PCI_VDEVICE(INTEL, 0x1f3e), board_ahci }, /* Avoton RAID */
-	{ PCI_VDEVICE(INTEL, 0x1f3f), board_ahci }, /* Avoton RAID */
+	{ PCI_VDEVICE(INTEL, 0x1f32), board_ahci_avn }, /* Avoton AHCI */
+	{ PCI_VDEVICE(INTEL, 0x1f33), board_ahci_avn }, /* Avoton AHCI */
+	{ PCI_VDEVICE(INTEL, 0x1f34), board_ahci_avn }, /* Avoton RAID */
+	{ PCI_VDEVICE(INTEL, 0x1f35), board_ahci_avn }, /* Avoton RAID */
+	{ PCI_VDEVICE(INTEL, 0x1f36), board_ahci_avn }, /* Avoton RAID */
+	{ PCI_VDEVICE(INTEL, 0x1f37), board_ahci_avn }, /* Avoton RAID */
+	{ PCI_VDEVICE(INTEL, 0x1f3e), board_ahci_avn }, /* Avoton RAID */
+	{ PCI_VDEVICE(INTEL, 0x1f3f), board_ahci_avn }, /* Avoton RAID */
 	{ PCI_VDEVICE(INTEL, 0x2823), board_ahci }, /* Wellsburg RAID */
 	{ PCI_VDEVICE(INTEL, 0x2827), board_ahci }, /* Wellsburg RAID */
 	{ PCI_VDEVICE(INTEL, 0x8d02), board_ahci }, /* Wellsburg AHCI */
@@ -674,6 +688,79 @@ static int ahci_p5wdh_hardreset(struct ata_link *link, unsigned int *class,
 	return rc;
 }
 
+/*
+ * ahci_avn_hardreset - attempt more aggressive recovery of Avoton ports.
+ *
+ * It has been observed with some SSDs that the timing of events in the
+ * link synchronization phase can leave the port in a state that can not
+ * be recovered by a SATA-hard-reset alone.  The failing signature is
+ * SStatus.DET stuck at 1 ("Device presence detected but Phy
+ * communication not established").  It was found that unloading and
+ * reloading the driver when this problem occurs allows the drive
+ * connection to be recovered (DET advanced to 0x3).  The critical
+ * component of reloading the driver is that the port state machines are
+ * reset by bouncing "port enable" in the AHCI PCS configuration
+ * register.  So, reproduce that effect by bouncing a port whenever we
+ * see DET==1 after a reset.
+ */
+static int ahci_avn_hardreset(struct ata_link *link, unsigned int *class,
+			      unsigned long deadline)
+{
+	const unsigned long *timing = sata_ehc_deb_timing(&link->eh_context);
+	struct ata_port *ap = link->ap;
+	struct ahci_port_priv *pp = ap->private_data;
+	struct ahci_host_priv *hpriv = ap->host->private_data;
+	u8 *d2h_fis = pp->rx_fis + RX_FIS_D2H_REG;
+	unsigned long tmo = deadline - jiffies;
+	struct ata_taskfile tf;
+	bool online;
+	int rc, i;
+
+	DPRINTK("ENTER\n");
+
+	ahci_stop_engine(ap);
+
+	for (i = 0; i < 2; i++) {
+		u16 val;
+		u32 sstatus;
+		int port = ap->port_no;
+		struct ata_host *host = ap->host;
+		struct pci_dev *pdev = to_pci_dev(host->dev);
+
+		/* clear D2H reception area to properly wait for D2H FIS */
+		ata_tf_init(link->device, &tf);
+		tf.command = ATA_BUSY;
+		ata_tf_to_fis(&tf, 0, 0, d2h_fis);
+
+		rc = sata_link_hardreset(link, timing, deadline, &online,
+				ahci_check_ready);
+
+		if (sata_scr_read(link, SCR_STATUS, &sstatus) != 0 ||
+				(sstatus & 0xf) != 1)
+			break;
+
+		ata_link_printk(link, KERN_INFO, "avn bounce port%d\n",
+				port);
+
+		pci_read_config_word(pdev, 0x92, &val);
+		val &= ~(1 << port);
+		pci_write_config_word(pdev, 0x92, val);
+		ata_msleep(ap, 1000);
+		val |= 1 << port;
+		pci_write_config_word(pdev, 0x92, val);
+		deadline += tmo;
+	}
+
+	hpriv->start_engine(ap);
+
+	if (online)
+		*class = ahci_dev_classify(ap);
+
+	DPRINTK("EXIT, rc=%d, class=%u\n", rc, *class);
+	return rc;
+}
+
+
 #ifdef CONFIG_PM
 static int ahci_pci_device_suspend(struct pci_dev *pdev, pm_message_t mesg)
 {
Signature · 1 line
2.6.3
author
#35 lore raw

PATCH 34/72 Fix regression in NFSRDMA server

In reply to Jiri Slaby

From: Tom Tucker <[email protected]>

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

===============

commit 7e4359e2611f95a97037e2b6905eab52f28afbeb upstream.

The server regression was caused by the addition of rq_next_page (afc59400d6c65bad66d4ad0b2daf879cbff8e23e). There were a few places that were missed with the update of the rq_respages array.

---
 net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 12 ++++--------
 net/sunrpc/xprtrdma/svc_rdma_sendto.c   |  1 +
 2 files changed, 5 insertions(+), 8 deletions(-)
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c +4 -8
index 0ce75524ed21..8d904e4eef15 100644
@@ -90,6 +90,7 @@ static void rdma_build_arg_xdr(struct svc_rqst *rqstp,
 		sge_no++;
 	}
 	rqstp->rq_respages = &rqstp->rq_pages[sge_no];
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
 
 	/* We should never run out of SGE because the limit is defined to
 	 * support the max allowed RPC data length
@@ -169,6 +170,7 @@ static int map_read_chunks(struct svcxprt_rdma *xprt,
 		 */
 		head->arg.pages[page_no] = rqstp->rq_arg.pages[page_no];
 		rqstp->rq_respages = &rqstp->rq_arg.pages[page_no+1];
+		rqstp->rq_next_page = rqstp->rq_respages + 1;
 
 		byte_count -= sge_bytes;
 		ch_bytes -= sge_bytes;
@@ -276,6 +278,7 @@ static int fast_reg_read_chunks(struct svcxprt_rdma *xprt,
 
 	/* rq_respages points one past arg pages */
 	rqstp->rq_respages = &rqstp->rq_arg.pages[page_no];
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
 
 	/* Create the reply and chunk maps */
 	offset = 0;
@@ -520,13 +523,6 @@ next_sge:
 	for (ch_no = 0; &rqstp->rq_pages[ch_no] < rqstp->rq_respages; ch_no++)
 		rqstp->rq_pages[ch_no] = NULL;
 
-	/*
-	 * Detach res pages. If svc_release sees any it will attempt to
-	 * put them.
-	 */
-	while (rqstp->rq_next_page != rqstp->rq_respages)
-		*(--rqstp->rq_next_page) = NULL;
-
 	return err;
 }
 
@@ -550,7 +546,7 @@ static int rdma_read_complete(struct svc_rqst *rqstp,
 
 	/* rq_respages starts after the last arg page */
 	rqstp->rq_respages = &rqstp->rq_arg.pages[page_no];
-	rqstp->rq_next_page = &rqstp->rq_arg.pages[page_no];
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
 
 	/* Rebuild rq_arg head and tail. */
 	rqstp->rq_arg.head[0] = head->arg.head[0];
net/sunrpc/xprtrdma/svc_rdma_sendto.c +1 -0
index c1d124dc772b..11e90f8c0fc5 100644
@@ -625,6 +625,7 @@ static int send_reply(struct svcxprt_rdma *rdma,
 		if (page_no+1 >= sge_no)
 			ctxt->sge[page_no+1].length = 0;
 	}
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
 	BUG_ON(sge_no > rdma->sc_max_sge);
 	memset(&send_wr, 0, sizeof send_wr);
 	ctxt->wr_op = IB_WR_SEND;
Signature · 1 line
2.6.3
#36 lore raw

Re: [PATCH 3.12 34/72] Fix regression in NFSRDMA server

Seems like part of a patch was dropped or there was a merge problem. The code in my tree has all these changes. Very strange.

Tom

Quoted 26 lines · Jiri Slaby

From: Tom Tucker <[email protected]>

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

===============

commit 7e4359e2611f95a97037e2b6905eab52f28afbeb upstream.

The server regression was caused by the addition of rq_next_page (afc59400d6c65bad66d4ad0b2daf879cbff8e23e). There were a few places that were missed with the update of the rq_respages array.

---
  net/sunrpc/xprtrdma/svc_rdma_recvfrom.c | 12 ++++--------
  net/sunrpc/xprtrdma/svc_rdma_sendto.c   |  1 +
  2 files changed, 5 insertions(+), 8 deletions(-)
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c +0 -0
index 0ce75524ed21..8d904e4eef15 100644

net/sunrpc/xprtrdma/svc_rdma_recvfrom.c static void rdma_build_arg_xdr(struct svc_rqst *rqstp, · line 93

Quoted 4 lines
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c +1 -0
@@ -90,6 +90,7 @@ static void rdma_build_arg_xdr(struct svc_rqst *rqstp,
  		sge_no++;
  	}
  	rqstp->rq_respages = &rqstp->rq_pages[sge_no];
+	rqstp->rq_next_page = rqstp->rq_respages + 1;

This was fixed in an older version.

Quoted 54 lines
net/sunrpc/xprtrdma/svc_rdma_recvfrom.c +3 -8
  	/* We should never run out of SGE because the limit is defined to
  	 * support the max allowed RPC data length
@@ -169,6 +170,7 @@ static int map_read_chunks(struct svcxprt_rdma *xprt,
  		 */
  		head->arg.pages[page_no] = rqstp->rq_arg.pages[page_no];
  		rqstp->rq_respages = &rqstp->rq_arg.pages[page_no+1];
+		rqstp->rq_next_page = rqstp->rq_respages + 1;
 
  		byte_count -= sge_bytes;
  		ch_bytes -= sge_bytes;
@@ -276,6 +278,7 @@ static int fast_reg_read_chunks(struct svcxprt_rdma *xprt,
 
  	/* rq_respages points one past arg pages */
  	rqstp->rq_respages = &rqstp->rq_arg.pages[page_no];
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
 
  	/* Create the reply and chunk maps */
  	offset = 0;
@@ -520,13 +523,6 @@ next_sge:
  	for (ch_no = 0; &rqstp->rq_pages[ch_no] < rqstp->rq_respages; ch_no++)
  		rqstp->rq_pages[ch_no] = NULL;
 
-	/*
-	 * Detach res pages. If svc_release sees any it will attempt to
-	 * put them.
-	 */
-	while (rqstp->rq_next_page != rqstp->rq_respages)
-		*(--rqstp->rq_next_page) = NULL;
-
  	return err;
  }
 
@@ -550,7 +546,7 @@ static int rdma_read_complete(struct svc_rqst *rqstp,
 
  	/* rq_respages starts after the last arg page */
  	rqstp->rq_respages = &rqstp->rq_arg.pages[page_no];
-	rqstp->rq_next_page = &rqstp->rq_arg.pages[page_no];
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
 
  	/* Rebuild rq_arg head and tail. */
  	rqstp->rq_arg.head[0] = head->arg.head[0];
net/sunrpc/xprtrdma/svc_rdma_sendto.c +1 -0
index c1d124dc772b..11e90f8c0fc5 100644
@@ -625,6 +625,7 @@ static int send_reply(struct svcxprt_rdma *rdma,
  		if (page_no+1 >= sge_no)
  			ctxt->sge[page_no+1].length = 0;
  	}
+	rqstp->rq_next_page = rqstp->rq_respages + 1;
  	BUG_ON(sge_no > rdma->sc_max_sge);
  	memset(&send_wr, 0, sizeof send_wr);
  	ctxt->wr_op = IB_WR_SEND;
author
#37 lore raw

PATCH 35/72 irda: precedence bug in irlmp_seq_hb_idx()

In reply to Jiri Slaby

From: Dan Carpenter <[email protected]>

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

===============

[ Upstream commit 50010c20597d14667eff0fdb628309986f195230 ]

This is decrementing the pointer, instead of the value stored in the pointer. KASan detects it as an out of bounds reference.

---
 net/irda/irlmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/irda/irlmp.c +1 -1
index 98ad6ec4bd3c..8ad149478e19 100644
@@ -1876,7 +1876,7 @@ static void *irlmp_seq_hb_idx(struct irlmp_iter_state *iter, loff_t *off)
 	for (element = hashbin_get_first(iter->hashbin);
 	     element != NULL;
 	     element = hashbin_get_next(iter->hashbin)) {
-		if (!off || *off-- == 0) {
+		if (!off || (*off)-- == 0) {
 			/* NB: hashbin left locked */
 			return element;
 		}
Signature · 1 line
2.6.3
author
#38 lore raw

PATCH 36/72 macvtap: unbreak receiving of gro skb with frag list

In reply to Jiri Slaby

From: Jason Wang <[email protected]>

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

===============

[ Upstream commit f23d538bc24a83c16127c2eb82c9cf1adc2b5149 ]

We don't have fraglist support in TAP_FEATURES. This will lead software segmentation of gro skb with frag list. Fixes by having frag list support in TAP_FEATURES.

With this patch single session of netperf receiving were restored from about 5Gb/s to about 12Gb/s on mlx4.

Fixes a567dd6252 ("macvtap: simplify usage of tap_features")

---
 drivers/net/macvtap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/macvtap.c +1 -1
index 393873fb792e..ee53a9d06e8e 100644
@@ -69,7 +69,7 @@ static const struct proto_ops macvtap_socket_ops;
 #define TUN_OFFLOADS (NETIF_F_HW_CSUM | NETIF_F_TSO_ECN | NETIF_F_TSO | \
 		      NETIF_F_TSO6 | NETIF_F_UFO)
 #define RX_OFFLOADS (NETIF_F_GRO | NETIF_F_LRO)
-#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG)
+#define TAP_FEATURES (NETIF_F_GSO | NETIF_F_SG | NETIF_F_FRAGLIST)
 
 /*
  * RCU usage:
Signature · 1 line
2.6.3
author
#39 lore raw

PATCH 37/72 ppp: fix pppoe_dev deletion condition in pppoe_release()

In reply to Jiri Slaby

From: Guillaume Nault <[email protected]>

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

===============

[ Upstream commit 1acea4f6ce1b1c0941438aca75dd2e5c6b09db60 ]

We can't rely on PPPOX_ZOMBIE to decide whether to clear po->pppoe_dev. PPPOX_ZOMBIE can be set by pppoe_disc_rcv() even when po->pppoe_dev is NULL. So we have no guarantee that (sk->sk_state & PPPOX_ZOMBIE) implies (po->pppoe_dev != NULL).
Since we're releasing a PPPoE socket, we want to release the pppoe_dev if it exists and reset sk_state to PPPOX_DEAD, no matter the previous value of sk_state. So we can just check for po->pppoe_dev and avoid any assumption on sk->sk_state.

Fixes 2b018d57ff18 ("pppoe: drop PPPOX_ZOMBIEs in pppoe_release")
---
 drivers/net/ppp/pppoe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ppp/pppoe.c +1 -1
index d66cf214e95e..1cfd4e841854 100644
@@ -569,7 +569,7 @@ static int pppoe_release(struct socket *sock)
 
 	po = pppox_sk(sk);
 
-	if (sk->sk_state & (PPPOX_CONNECTED | PPPOX_BOUND | PPPOX_ZOMBIE)) {
+	if (po->pppoe_dev) {
 		dev_put(po->pppoe_dev);
 		po->pppoe_dev = NULL;
 	}
Signature · 1 line
2.6.3
author
#40 lore raw

PATCH 38/72 RDS-TCP: Recover correctly from pskb_pull()/pksb_trim() failure in rds_tcp_data_recv

In reply to Jiri Slaby

From: Sowmini Varadhan <[email protected]>

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

===============

[ Upstream commit 8ce675ff39b9958d1c10f86cf58e357efaafc856 ]

Either of pskb_pull() or pskb_trim() may fail under low memory conditions. If rds_tcp_data_recv() ignores such failures, the application will receive corrupted data because the skb has not been correctly carved to the RDS datagram size.

Avoid this by handling pskb_pull/pskb_trim failure in the same manner as the skb_clone failure: bail out of rds_tcp_data_recv(), and retry via the deferred call to rds_send_worker() that gets set up on ENOMEM from rds_tcp_read_sock()

---
 net/rds/tcp_recv.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)
net/rds/tcp_recv.c +9 -2
index 4fac4f2bb9dc..8b33d9967b56 100644
@@ -234,8 +234,15 @@ static int rds_tcp_data_recv(read_descriptor_t *desc, struct sk_buff *skb,
 			}
 
 			to_copy = min(tc->t_tinc_data_rem, left);
-			pskb_pull(clone, offset);
-			pskb_trim(clone, to_copy);
+			if (!pskb_pull(clone, offset) ||
+			    pskb_trim(clone, to_copy)) {
+				pr_warn("rds_tcp_data_recv: pull/trim failed "
+					"left %zu data_rem %zu skb_len %d\n",
+					left, tc->t_tinc_data_rem, skb->len);
+				kfree_skb(clone);
+				desc->error = -ENOMEM;
+				goto out;
+			}
 			skb_queue_tail(&tinc->ti_skb_list, clone);
 
 			rdsdebug("skb %p data %p len %d off %u to_copy %zu -> "
Signature · 1 line
2.6.3
author
#41 lore raw

PATCH 39/72 net/mlx4: Copy/set only sizeof struct mlx4_eqe bytes

In reply to Jiri Slaby

From: Carol L Soto <[email protected]>

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

===============

[ Upstream commit c02b05011fadf8e409e41910217ca689f2fc9d91 ]

When doing memcpy/memset of EQEs, we should use sizeof struct mlx4_eqe as the base size and not caps.eqe_size which could be bigger.

If caps.eqe_size is bigger than the struct mlx4_eqe then we corrupt data in the master context.

When using a 64 byte stride, the memcpy copied over 63 bytes to the slave_eq structure. This resulted in copying over the entire eqe of interest, including its ownership bit -- and also 31 bytes of garbage into the next WQE in the slave EQ -- which did NOT include the ownership bit (and therefore had no impact).

However, once the stride is increased to 128, we are overwriting the ownership bits of *three* eqes in the slave_eq struct. This results in an incorrect ownership bit for those eqes, which causes the eq to seem to be full. The issue therefore surfaced only once 128-byte EQEs started being used in SRIOV and (overarchitectures that have 128/256 byte cache-lines such as PPC) - e.g after commit 77507aa249ae "net/mlx4_core: Enable CQE/EQE stride support".

Fixes 08ff32352d6f ('mlx4: 64-byte CQE/EQE support')
---
 drivers/net/ethernet/mellanox/mlx4/cmd.c | 2 +-
 drivers/net/ethernet/mellanox/mlx4/eq.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/mellanox/mlx4/cmd.c +1 -1
index bb11624a1f39..8a9c18529bfd 100644
@@ -1983,7 +1983,7 @@ int mlx4_multi_func_init(struct mlx4_dev *dev)
 			spin_lock_init(&s_state->lock);
 		}
 
-		memset(&priv->mfunc.master.cmd_eqe, 0, dev->caps.eqe_size);
+		memset(&priv->mfunc.master.cmd_eqe, 0, sizeof(struct mlx4_eqe));
 		priv->mfunc.master.cmd_eqe.type = MLX4_EVENT_TYPE_CMD;
 		INIT_WORK(&priv->mfunc.master.comm_work,
 			  mlx4_master_comm_channel);
drivers/net/ethernet/mellanox/mlx4/eq.c +1 -1
index 3990b435a081..b13d5a7a2b18 100644
@@ -184,7 +184,7 @@ static void slave_event(struct mlx4_dev *dev, u8 slave, struct mlx4_eqe *eqe)
 		return;
 	}
 
-	memcpy(s_eqe, eqe, dev->caps.eqe_size - 1);
+	memcpy(s_eqe, eqe, sizeof(struct mlx4_eqe) - 1);
 	s_eqe->slave_id = slave;
 	/* ensure all information is written before setting the ownersip bit */
 	wmb();
Signature · 1 line
2.6.3
author
#42 lore raw

PATCH 40/72 stmmac: Correctly report PTP capabilities.

In reply to Jiri Slaby

From: Phil Reid <[email protected]>

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

===============

[ Upstream commit e6dbe1eb2db0d7a14991c06278dd3030c45fb825 ]

priv->hwts_*_en indicate if timestamping is enabled/disabled at run time. But priv->dma_cap.time_stamp and priv->dma_cap.atime_stamp indicates HW is support for PTPv1/PTPv2.

---
 drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c +5 -2
index c5f9cb85c8ef..ff08be535a4d 100644
@@ -731,10 +731,13 @@ static int stmmac_get_ts_info(struct net_device *dev,
 {
 	struct stmmac_priv *priv = netdev_priv(dev);
 
-	if ((priv->hwts_tx_en) && (priv->hwts_rx_en)) {
+	if ((priv->dma_cap.time_stamp || priv->dma_cap.atime_stamp)) {
 
-		info->so_timestamping = SOF_TIMESTAMPING_TX_HARDWARE |
+		info->so_timestamping = SOF_TIMESTAMPING_TX_SOFTWARE |
+					SOF_TIMESTAMPING_TX_HARDWARE |
+					SOF_TIMESTAMPING_RX_SOFTWARE |
 					SOF_TIMESTAMPING_RX_HARDWARE |
+					SOF_TIMESTAMPING_SOFTWARE |
 					SOF_TIMESTAMPING_RAW_HARDWARE;
 
 		if (priv->ptp_clock)
Signature · 1 line
2.6.3
author
#43 lore raw

PATCH 41/72 ipmr: fix possible race resulting from improper usage of IP_INC_STATS_BH() in preemptible context.

In reply to Jiri Slaby

From: Ani Sinha <[email protected]>

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

===============

[ Upstream commit 44f49dd8b5a606870a1f21101522a0f9c4414784 ]

Fixes the following kernel BUG :

BUG: using __this_cpu_add() in preemptible [00000000] code: bash/2758
caller is __this_cpu_preempt_check+0x13/0x15
CPU: 0 PID: 2758 Comm: bash Tainted: P           O   3.18.19 #2
 ffffffff8170eaca ffff880110d1b788 ffffffff81482b2a 0000000000000000
 0000000000000000 ffff880110d1b7b8 ffffffff812010ae ffff880007cab800
 ffff88001a060800 ffff88013a899108 ffff880108b84240 ffff880110d1b7c8
Call Trace:
[<ffffffff81482b2a>] dump_stack+0x52/0x80
[<ffffffff812010ae>] check_preemption_disabled+0xce/0xe1
[<ffffffff812010d4>] __this_cpu_preempt_check+0x13/0x15
[<ffffffff81419d60>] ipmr_queue_xmit+0x647/0x70c
[<ffffffff8141a154>] ip_mr_forward+0x32f/0x34e
[<ffffffff8141af76>] ip_mroute_setsockopt+0xe03/0x108c
[<ffffffff810553fc>] ? get_parent_ip+0x11/0x42
[<ffffffff810e6974>] ? pollwake+0x4d/0x51
[<ffffffff81058ac0>] ? default_wake_function+0x0/0xf
[<ffffffff810553fc>] ? get_parent_ip+0x11/0x42
[<ffffffff810613d9>] ? __wake_up_common+0x45/0x77
[<ffffffff81486ea9>] ? _raw_spin_unlock_irqrestore+0x1d/0x32
[<ffffffff810618bc>] ? __wake_up_sync_key+0x4a/0x53
[<ffffffff8139a519>] ? sock_def_readable+0x71/0x75
[<ffffffff813dd226>] do_ip_setsockopt+0x9d/0xb55
[<ffffffff81429818>] ? unix_seqpacket_sendmsg+0x3f/0x41
[<ffffffff813963fe>] ? sock_sendmsg+0x6d/0x86
[<ffffffff813959d4>] ? sockfd_lookup_light+0x12/0x5d
[<ffffffff8139650a>] ? SyS_sendto+0xf3/0x11b
[<ffffffff810d5738>] ? new_sync_read+0x82/0xaa
[<ffffffff813ddd19>] compat_ip_setsockopt+0x3b/0x99
[<ffffffff813fb24a>] compat_raw_setsockopt+0x11/0x32
[<ffffffff81399052>] compat_sock_common_setsockopt+0x18/0x1f
[<ffffffff813c4d05>] compat_SyS_setsockopt+0x1a9/0x1cf
[<ffffffff813c4149>] compat_SyS_socketcall+0x180/0x1e3
[<ffffffff81488ea1>] cstar_dispatch+0x7/0x1e
---
 net/ipv4/ipmr.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
net/ipv4/ipmr.c +3 -3
index 648ba5e6ea3c..a99f914dd021 100644
@@ -1672,8 +1672,8 @@ static inline int ipmr_forward_finish(struct sk_buff *skb)
 {
 	struct ip_options *opt = &(IPCB(skb)->opt);
 
-	IP_INC_STATS_BH(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTFORWDATAGRAMS);
-	IP_ADD_STATS_BH(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTOCTETS, skb->len);
+	IP_INC_STATS(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTFORWDATAGRAMS);
+	IP_ADD_STATS(dev_net(skb_dst(skb)->dev), IPSTATS_MIB_OUTOCTETS, skb->len);
 
 	if (unlikely(opt->optlen))
 		ip_forward_options(skb);
@@ -1735,7 +1735,7 @@ static void ipmr_queue_xmit(struct net *net, struct mr_table *mrt,
 		 * to blackhole.
 		 */
 
-		IP_INC_STATS_BH(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
+		IP_INC_STATS(dev_net(dev), IPSTATS_MIB_FRAGFAILS);
 		ip_rt_put(rt);
 		goto out_free;
 	}
Signature · 1 line
2.6.3
author
#44 lore raw

PATCH 42/72 qmi_wwan: fix entry for HP lt4112 LTE/HSPA+ Gobi 4G Module

In reply to Jiri Slaby

From: Bjørn Mork <[email protected]>

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

===============

[ Upstream commit 70910791731b5956171e1bfcad707766b8e18fee ]

The lt4112 is a HP branded Huawei me906e modem. Like other Huawei modems, it does not have a fixed interface to function mapping. Instead it uses a Huawei specific scheme: functions are mapped by subclass and protocol.

However, the HP vendor ID is used for modems from many different manufacturers using different schemes, so we cannot apply a generic vendor rule like we do for the Huawei vendor ID.

Replace the previous lt4112 entry pointing to an arbitrary interface number with a device specific subclass + protocol match.

Reported-and-tested-by Muri Nicanor <[email protected]>
Fixes bb2bdeb83fb1 ("qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem")
---
 drivers/net/usb/qmi_wwan.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/net/usb/qmi_wwan.c +4 -1
index 7f22d27070fc..e47d50335ff0 100644
@@ -515,6 +515,10 @@ static const struct usb_device_id products[] = {
 					      USB_CDC_PROTO_NONE),
 		.driver_info        = (unsigned long)&qmi_wwan_info,
 	},
+	{	/* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
+		USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x581d, USB_CLASS_VENDOR_SPEC, 1, 7),
+		.driver_info = (unsigned long)&qmi_wwan_info,
+	},
 
 	/* 3. Combined interface devices matching on interface number */
 	{QMI_FIXED_INTF(0x0408, 0xea42, 4)},	/* Yota / Megafon M100-1 */
@@ -756,7 +760,6 @@ static const struct usb_device_id products[] = {
 	{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},	/* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
 	{QMI_FIXED_INTF(0x413c, 0x81a8, 8)},	/* Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card */
 	{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},	/* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
-	{QMI_FIXED_INTF(0x03f0, 0x581d, 4)},	/* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
 
 	/* 4. Gobi 1000 devices */
 	{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
Signature · 1 line
2.6.3
author
#45 lore raw

PATCH 43/72 sit: fix sit0 percpu double allocations

In reply to Jiri Slaby

From: Eric Dumazet <[email protected]>

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

===============

[ Upstream commit 4ece9009774596ee3df0acba65a324b7ea79387c ]

sit0 device allocates its percpu storage twice :
- One time in ipip6_tunnel_init()
- One time in ipip6_fb_tunnel_init()

Thus we leak 48 bytes per possible cpu per network namespace dismantle.

ipip6_fb_tunnel_init() can be much simpler and does not return an error, and should be called after register_netdev()

Note that ipip6_tunnel_clone_6rd() also needs to be called after register_netdev() (calling ipip6_tunnel_init())

Fixes ebe084aafb7e ("sit: Use ipip6_tunnel_init as the ndo_init function.")
Cc Steffen Klassert <[email protected]>
---
 net/ipv6/sit.c | 20 ++++----------------
 1 file changed, 4 insertions(+), 16 deletions(-)
net/ipv6/sit.c +4 -16
index 8e8fc32a080f..eb1fe0759752 100644
@@ -1323,27 +1323,20 @@ static int ipip6_tunnel_init(struct net_device *dev)
 	return 0;
 }
 
-static int __net_init ipip6_fb_tunnel_init(struct net_device *dev)
+static void __net_init ipip6_fb_tunnel_init(struct net_device *dev)
 {
 	struct ip_tunnel *tunnel = netdev_priv(dev);
 	struct iphdr *iph = &tunnel->parms.iph;
 	struct net *net = dev_net(dev);
 	struct sit_net *sitn = net_generic(net, sit_net_id);
 
-	tunnel->dev = dev;
-	tunnel->net = dev_net(dev);
-
 	iph->version		= 4;
 	iph->protocol		= IPPROTO_IPV6;
 	iph->ihl		= 5;
 	iph->ttl		= 64;
 
-	dev->tstats = alloc_percpu(struct pcpu_tstats);
-	if (!dev->tstats)
-		return -ENOMEM;
 	dev_hold(dev);
 	rcu_assign_pointer(sitn->tunnels_wc[0], tunnel);
-	return 0;
 }
 
 static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[])
@@ -1680,23 +1673,18 @@ static int __net_init sit_init_net(struct net *net)
 	 */
 	sitn->fb_tunnel_dev->features |= NETIF_F_NETNS_LOCAL;
 
-	err = ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
-	if (err)
-		goto err_dev_free;
-
-	ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
-
 	if ((err = register_netdev(sitn->fb_tunnel_dev)))
 		goto err_reg_dev;
 
+	ipip6_tunnel_clone_6rd(sitn->fb_tunnel_dev, sitn);
+	ipip6_fb_tunnel_init(sitn->fb_tunnel_dev);
+
 	t = netdev_priv(sitn->fb_tunnel_dev);
 
 	strcpy(t->parms.name, sitn->fb_tunnel_dev->name);
 	return 0;
 
 err_reg_dev:
-	dev_put(sitn->fb_tunnel_dev);
-err_dev_free:
 	ipip6_dev_free(sitn->fb_tunnel_dev);
 err_alloc_dev:
 	return err;
Signature · 1 line
2.6.3
author
#46 lore raw

PATCH 44/72 net: avoid NULL deref in inet_ctl_sock_destroy()

In reply to Jiri Slaby

From: Eric Dumazet <[email protected]>

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

===============

[ Upstream commit 8fa677d2706d325d71dab91bf6e6512c05214e37 ]

Under low memory conditions, tcp_sk_init() and icmp_sk_init() can both iterate on all possible cpus and call inet_ctl_sock_destroy(), with eventual NULL pointer.

---
 include/net/inet_common.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
include/net/inet_common.h +2 -1
index 234008782c8c..102fc42c7fb1 100644
@@ -40,7 +40,8 @@ extern int inet_ctl_sock_create(struct sock **sk, unsigned short family,
 
 static inline void inet_ctl_sock_destroy(struct sock *sk)
 {
-	sk_release_kernel(sk);
+	if (sk)
+		sk_release_kernel(sk);
 }
 
 #endif
Signature · 1 line
2.6.3
author
#47 lore raw

PATCH 45/72 net: fix a race in dst_release()

In reply to Jiri Slaby

From: Eric Dumazet <[email protected]>

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

===============

[ Upstream commit d69bbf88c8d0b367cf3e3a052f6daadf630ee566 ]

Only cpu seeing dst refcount going to 0 can safely dereference dst->flags.

Otherwise an other cpu might already have freed the dst.

Fixes 27b75c95f10d ("net: avoid RCU for NOCACHE dst")
---
 net/core/dst.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/dst.c +1 -1
index 15b6792e6ebb..c07070544e3f 100644
@@ -283,7 +283,7 @@ void dst_release(struct dst_entry *dst)
 
 		newrefcnt = atomic_dec_return(&dst->__refcnt);
 		WARN_ON(newrefcnt < 0);
-		if (unlikely(dst->flags & DST_NOCACHE) && !newrefcnt)
+		if (!newrefcnt && unlikely(dst->flags & DST_NOCACHE))
 			call_rcu(&dst->rcu_head, dst_destroy_rcu);
 	}
 }
Signature · 1 line
2.6.3
author
#48 lore raw

PATCH 46/72 virtio-net: drop NETIF_F_FRAGLIST

In reply to Jiri Slaby

From: Jason Wang <[email protected]>

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

===============

[ Upstream commit 48900cb6af4282fa0fb6ff4d72a81aa3dadb5c39 ]

virtio declares support for NETIF_F_FRAGLIST, but assumes that there are at most MAX_SKB_FRAGS + 2 fragments which isn't always true with a fraglist.

A longer fraglist in the skb will make the call to skb_to_sgvec overflow the sg array, leading to memory corruption.

Drop NETIF_F_FRAGLIST so we only get what we can handle.

---
 drivers/net/virtio_net.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/virtio_net.c +2 -2
index 0232156dade3..5d080516d0c5 100644
@@ -1567,9 +1567,9 @@ static int virtnet_probe(struct virtio_device *vdev)
 	/* Do we support "hardware" checksums? */
 	if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
 		/* This opens up the world of extra features. */
-		dev->hw_features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
+		dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
 		if (csum)
-			dev->features |= NETIF_F_HW_CSUM|NETIF_F_SG|NETIF_F_FRAGLIST;
+			dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
 
 		if (virtio_has_feature(vdev, VIRTIO_NET_F_GSO)) {
 			dev->hw_features |= NETIF_F_TSO | NETIF_F_UFO
Signature · 1 line
2.6.3
author
#49 lore raw

PATCH 47/72 RDS: verify the underlying transport exists before creating a connection

In reply to Jiri Slaby

From: Sasha Levin <[email protected]>

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

===============

[ Upstream commit 74e98eb085889b0d2d4908f59f6e00026063014f ]

There was no verification that an underlying transport exists when creating a connection, this would cause dereferencing a NULL ptr.

It might happen on sockets that weren't properly bound before attempting to send a message, which will cause a NULL ptr deref:

[135546.047719] kasan: GPF could be caused by NULL-ptr deref or user memory accessgeneral protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
[135546.051270] Modules linked in:
[135546.051781] CPU: 4 PID: 15650 Comm: trinity-c4 Not tainted 4.2.0-next-20150902-sasha-00041-gbaa1222-dirty #2527
[135546.053217] task: ffff8800835bc000 ti: ffff8800bc708000 task.ti: ffff8800bc708000
[135546.054291] RIP: __rds_conn_create (net/rds/connection.c:194)
[135546.055666] RSP: 0018:ffff8800bc70fab0  EFLAGS: 00010202
[135546.056457] RAX: dffffc0000000000 RBX: 0000000000000f2c RCX: ffff8800835bc000
[135546.057494] RDX: 0000000000000007 RSI: ffff8800835bccd8 RDI: 0000000000000038
[135546.058530] RBP: ffff8800bc70fb18 R08: 0000000000000001 R09: 0000000000000000
[135546.059556] R10: ffffed014d7a3a23 R11: ffffed014d7a3a21 R12: 0000000000000000
[135546.060614] R13: 0000000000000001 R14: ffff8801ec3d0000 R15: 0000000000000000
[135546.061668] FS:  00007faad4ffb700(0000) GS:ffff880252000000(0000) knlGS:0000000000000000
[135546.062836] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[135546.063682] CR2: 000000000000846a CR3: 000000009d137000 CR4: 00000000000006a0
[135546.064723] Stack:
[135546.065048]  ffffffffafe2055c ffffffffafe23fc1 ffffed00493097bf ffff8801ec3d0008
[135546.066247]  0000000000000000 00000000000000d0 0000000000000000 ac194a24c0586342
[135546.067438]  1ffff100178e1f78 ffff880320581b00 ffff8800bc70fdd0 ffff880320581b00
[135546.068629] Call Trace:
[135546.069028] ? __rds_conn_create (include/linux/rcupdate.h:856 net/rds/connection.c:134)
[135546.069989] ? rds_message_copy_from_user (net/rds/message.c:298)
[135546.071021] rds_conn_create_outgoing (net/rds/connection.c:278)
[135546.071981] rds_sendmsg (net/rds/send.c:1058)
[135546.072858] ? perf_trace_lock (include/trace/events/lock.h:38)
[135546.073744] ? lockdep_init (kernel/locking/lockdep.c:3298)
[135546.074577] ? rds_send_drop_to (net/rds/send.c:976)
[135546.075508] ? __might_fault (./arch/x86/include/asm/current.h:14 mm/memory.c:3795)
[135546.076349] ? __might_fault (mm/memory.c:3795)
[135546.077179] ? rds_send_drop_to (net/rds/send.c:976)
[135546.078114] sock_sendmsg (net/socket.c:611 net/socket.c:620)
[135546.078856] SYSC_sendto (net/socket.c:1657)
[135546.079596] ? SYSC_connect (net/socket.c:1628)
[135546.080510] ? trace_dump_stack (kernel/trace/trace.c:1926)
[135546.081397] ? ring_buffer_unlock_commit (kernel/trace/ring_buffer.c:2479 kernel/trace/ring_buffer.c:2558 kernel/trace/ring_buffer.c:2674)
[135546.082390] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749)
[135546.083410] ? trace_event_raw_event_sys_enter (include/trace/events/syscalls.h:16)
[135546.084481] ? do_audit_syscall_entry (include/trace/events/syscalls.h:16)
[135546.085438] ? trace_buffer_unlock_commit (kernel/trace/trace.c:1749)
[135546.085515] rds_ib_laddr_check(): addr 36.74.25.172 ret -99 node type -1
---
 net/rds/connection.c | 6 ++++++
 1 file changed, 6 insertions(+)
net/rds/connection.c +6 -0
index 642ad42c416b..e88bf3976e54 100644
@@ -177,6 +177,12 @@ static struct rds_connection *__rds_conn_create(__be32 laddr, __be32 faddr,
 		}
 	}
 
+	if (trans == NULL) {
+		kmem_cache_free(rds_conn_slab, conn);
+		conn = ERR_PTR(-ENODEV);
+		goto out;
+	}
+
 	conn->c_trans = trans;
 
 	ret = trans->conn_alloc(conn, gfp);
Signature · 1 line
2.6.3
author
#50 lore raw

PATCH 48/72 netfilter: xt_NFQUEUE: fix --queue-bypass regression

In reply to Jiri Slaby

From: Holger Eitzenberger <[email protected]>

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

===============

commit d954777324ffcba0b2f8119c102237426c654eeb upstream.

V3 of the NFQUEUE target ignores the --queue-bypass flag, causing packets to be dropped when the userspace listener isn't running.

Regression is in since 8746ddcf12bb26 ("netfilter: xt_NFQUEUE:
introduce CPU fanout").

---
 net/netfilter/xt_NFQUEUE.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
net/netfilter/xt_NFQUEUE.c +6 -1
index 1e2fae32f81b..ed00fef58996 100644
@@ -147,6 +147,7 @@ nfqueue_tg_v3(struct sk_buff *skb, const struct xt_action_param *par)
 {
 	const struct xt_NFQ_info_v3 *info = par->targinfo;
 	u32 queue = info->queuenum;
+	int ret;
 
 	if (info->queues_total > 1) {
 		if (info->flags & NFQ_FLAG_CPU_FANOUT) {
@@ -157,7 +158,11 @@ nfqueue_tg_v3(struct sk_buff *skb, const struct xt_action_param *par)
 			queue = nfqueue_hash(skb, par);
 	}
 
-	return NF_QUEUE_NR(queue);
+	ret = NF_QUEUE_NR(queue);
+	if (info->flags & NFQ_FLAG_BYPASS)
+		ret |= NF_VERDICT_FLAG_QUEUE_BYPASS;
+
+	return ret;
 }
 
 static struct xt_target nfqueue_tg_reg[] __read_mostly = {
Signature · 1 line
2.6.3
author
#51 lore raw

PATCH 49/72 powerpc/pseries: Fix dedicated processor partition detection

From: Anton Blanchard <[email protected]>

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

===============

commit 733187e29576041ceccf3b82092ca900fc929170 upstream.

commit f13c13a00512 (powerpc: Stop using non-architected shared_proc field in lppaca) fixed a potential issue with shared/dedicated partition detection. The old method of detection relied on an unarchitected field (shared_proc), and this patch switched to using something architected (a non zero yield_count).

Unfortunately the assertion in the Linux header that yield_count is only non zero on shared processor partitions is not true. It turns out dedicated processor partitions can increment yield_count and as such we falsely detect dedicated partitions as shared.

Fix the comment, and switch back to using the old method.

---
 arch/powerpc/include/asm/lppaca.h | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)
arch/powerpc/include/asm/lppaca.h +6 -6
index 4470d1e34d23..844c28de7ec0 100644
@@ -84,8 +84,8 @@ struct lppaca {
 	 * the processor is yielded (either because of an OS yield or a
 	 * hypervisor preempt).  An even value implies that the processor is
 	 * currently executing.
-	 * NOTE: This value will ALWAYS be zero for dedicated processors and
-	 * will NEVER be zero for shared processors (ie, initialized to a 1).
+	 * NOTE: Even dedicated processor partitions can yield so this
+	 * field cannot be used to determine if we are shared or dedicated.
 	 */
 	volatile __be32 yield_count;
 	volatile __be32 dispersion_count; /* dispatch changed physical cpu */
@@ -106,15 +106,15 @@ extern struct lppaca lppaca[];
 #define lppaca_of(cpu)	(*paca[cpu].lppaca_ptr)
 
 /*
- * Old kernels used a reserved bit in the VPA to determine if it was running
- * in shared processor mode. New kernels look for a non zero yield count
- * but KVM still needs to set the bit to keep the old stuff happy.
+ * We are using a non architected field to determine if a partition is
+ * shared or dedicated. This currently works on both KVM and PHYP, but
+ * we will have to transition to something better.
  */
 #define LPPACA_OLD_SHARED_PROC		2
 
 static inline bool lppaca_shared_proc(struct lppaca *l)
 {
-	return l->yield_count != 0;
+	return !!(l->__old_status & LPPACA_OLD_SHARED_PROC);
 }
 
 /*
Signature · 1 line
2.6.3
author
#52 lore raw

PATCH 50/72 bridge: superfluous skb->nfct check in br_nf_dev_queue_xmit

In reply to Jiri Slaby

From: Vasily Averin <[email protected]>

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

===============

commit aff09ce303f83bd370772349238482ae422a2341 upstream.

Currently bridge can silently drop ipv4 fragments.
If node have loaded nf_defrag_ipv4 module but have no nf_conntrack_ipv4, br_nf_pre_routing defragments incoming ipv4 fragments
but nfct check in br_nf_dev_queue_xmit does not allow re-fragment combined packet back, and therefore it is dropped in br_dev_queue_push_xmit without incrementing of any failcounters

It seems the only way to hit the ip_fragment code in the bridge xmit path is to have a fragment list whose reassembled fragments go over the mtu. This only happens if nf_defrag is enabled. Thanks to Florian Westphal for providing feedback to clarify this.

Defragmentation ipv4 is required not only in conntracks but at least in TPROXY target and socket match, therefore #ifdef is changed from NF_CONNTRACK_IPV4 to NF_DEFRAG_IPV4

---
 net/bridge/br_netfilter.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
net/bridge/br_netfilter.c +2 -2
index f87736270eaa..bc9dc3877b1f 100644
@@ -853,12 +853,12 @@ static unsigned int br_nf_forward_arp(unsigned int hook, struct sk_buff *skb,
 	return NF_STOLEN;
 }
 
-#if IS_ENABLED(CONFIG_NF_CONNTRACK_IPV4)
+#if IS_ENABLED(CONFIG_NF_DEFRAG_IPV4)
 static int br_nf_dev_queue_xmit(struct sk_buff *skb)
 {
 	int ret;
 
-	if (skb->nfct != NULL && skb->protocol == htons(ETH_P_IP) &&
+	if (skb->protocol == htons(ETH_P_IP) &&
 	    skb->len + nf_bridge_mtu_reduction(skb) > skb->dev->mtu &&
 	    !skb_is_gso(skb)) {
 		if (br_parse_ip_options(skb))
Signature · 1 line
2.6.3
author
#53 lore raw

PATCH 51/72 net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr struct from userland.

In reply to Jiri Slaby

From: Ani Sinha <[email protected]>

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

===============

commit 6a2a2b3ae0759843b22c929881cc184b00cc63ff upstream.

Linux manpage for recvmsg and sendmsg calls does not explicitly mention setting msg_namelen to 0 when msg_name passed set as NULL. When developers don't set msg_namelen member in msghdr, it might contain garbage value which will fail the validation check and sendmsg and recvmsg calls from kernel will return EINVAL. This will break old binaries and any code for which there is no access to source code.
To fix this, we set msg_namelen to 0 when msg_name is passed as NULL from userland.

---
 net/socket.c | 3 +++
 1 file changed, 3 insertions(+)
net/socket.c +3 -0
index 432b0bddd9e1..00634623573f 100644
@@ -1970,6 +1970,9 @@ static int copy_msghdr_from_user(struct msghdr *kmsg,
 	if (copy_from_user(kmsg, umsg, sizeof(struct msghdr)))
 		return -EFAULT;
 
+	if (kmsg->msg_name == NULL)
+		kmsg->msg_namelen = 0;
+
 	if (kmsg->msg_namelen < 0)
 		return -EINVAL;
 
Signature · 1 line
2.6.3
author
#54 lore raw

PATCH 52/72 ceph: make sure request isn't in any waiting list when kicking request.

In reply to Jiri Slaby

From: "Yan, Zheng" <[email protected]>

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

===============

commit 03974e8177b36d672eb59658f976f03cb77c1129 upstream.

we may corrupt waiting list if a request in the waiting list is kicked.

---
 fs/ceph/mds_client.c | 1 +
 1 file changed, 1 insertion(+)
fs/ceph/mds_client.c +1 -0
index 6f1161324f91..3e07f82a3c9d 100644
@@ -1985,6 +1985,7 @@ static void kick_requests(struct ceph_mds_client *mdsc, int mds)
 		if (req->r_session &&
 		    req->r_session->s_mds == mds) {
 			dout(" kicking tid %llu\n", req->r_tid);
+			list_del_init(&req->r_wait);
 			__do_request(mdsc, req);
 		}
 	}
Signature · 1 line
2.6.3
author
#55 lore raw

PATCH 53/72 ceph: protect kick_requests() with mdsc->mutex

In reply to Jiri Slaby

From: "Yan, Zheng" <[email protected]>

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

===============

commit 656e4382948d4b2c81bdaf707f1400f53eff2625 upstream.

---
 fs/ceph/mds_client.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
fs/ceph/mds_client.c +3 -2
index 3e07f82a3c9d..16c7e4ab94f0 100644
@@ -2389,9 +2389,8 @@ static void handle_session(struct ceph_mds_session *session,
 		if (session->s_state == CEPH_MDS_SESSION_RECONNECTING)
 			pr_info("mds%d reconnect denied\n", session->s_mds);
 		remove_session_caps(session);
-		wake = 1; /* for good measure */
+		wake = 2; /* for good measure */
 		wake_up_all(&mdsc->session_close_wq);
-		kick_requests(mdsc, mds);
 		break;
 
 	case CEPH_SESSION_STALE:
@@ -2417,6 +2416,8 @@ static void handle_session(struct ceph_mds_session *session,
 	if (wake) {
 		mutex_lock(&mdsc->mutex);
 		__wake_requests(mdsc, &session->s_waiting);
+		if (wake == 2)
+			kick_requests(mdsc, mds);
 		mutex_unlock(&mdsc->mutex);
 	}
 	return;
Signature · 1 line
2.6.3
author
#56 lore raw

PATCH 54/72 ceph: fix kick_requests()

In reply to Jiri Slaby

From: "Yan, Zheng" <[email protected]>

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

===============

commit 282c105225ec3229f344c5fced795b9e1e634440 upstream.

__do_request() may unregister the request. So we should update iterator 'p' before calling __do_request()

---
 fs/ceph/mds_client.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
fs/ceph/mds_client.c +3 -2
index 16c7e4ab94f0..5ef4c6ca5cb5 100644
@@ -1975,11 +1975,12 @@ static void __wake_requests(struct ceph_mds_client *mdsc,
 static void kick_requests(struct ceph_mds_client *mdsc, int mds)
 {
 	struct ceph_mds_request *req;
-	struct rb_node *p;
+	struct rb_node *p = rb_first(&mdsc->request_tree);
 
 	dout("kick_requests mds%d\n", mds);
-	for (p = rb_first(&mdsc->request_tree); p; p = rb_next(p)) {
+	while (p) {
 		req = rb_entry(p, struct ceph_mds_request, r_node);
+		p = rb_next(p);
 		if (req->r_got_unsafe)
 			continue;
 		if (req->r_session &&
Signature · 1 line
2.6.3
author
#57 lore raw

PATCH 55/72 net: sun4i-emac: fix memory leak on bad packet

In reply to Jiri Slaby

From: Marc Zyngier <[email protected]>

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

===============

commit 2670cc699a66c4cf268cb3e3f6dfc325ec14f224 upstream.

Upon reception of a new frame, the emac driver checks for a number of error conditions, and flag the packet as "bad" if any of these are present. It then allocates a skb unconditionally, but only uses it if the packet is "good". On the error path, the skb is just forgotten, and the system leaks memory.

The piece of junk I have on my desk seems to encounter such error frequently enough so that the box goes OOM after a couple of days, which makes me grumpy.

Fix this by moving the allocation on the "good_packet" path (and convert it to netdev_alloc_skb while we're at it).

Tested on a random Allwinner A20 board.

---
 drivers/net/ethernet/allwinner/sun4i-emac.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/net/ethernet/allwinner/sun4i-emac.c +4 -2
index 81576c6c31e0..ac735537fe2e 100644
@@ -623,8 +623,10 @@ static void emac_rx(struct net_device *dev)
 		}
 
 		/* Move data from EMAC */
-		skb = dev_alloc_skb(rxlen + 4);
-		if (good_packet && skb) {
+		if (good_packet) {
+			skb = netdev_alloc_skb(dev, rxlen + 4);
+			if (!skb)
+				continue;
 			skb_reserve(skb, 2);
 			rdptr = (u8 *) skb_put(skb, rxlen - 4);
 
Signature · 1 line
2.6.3
author
#58 lore raw

PATCH 56/72 macmace: add missing platform_set_drvdata() in mace_probe()

In reply to Jiri Slaby

From: Wei Yongjun <[email protected]>

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

===============

commit 06a2feb9e3bd0d2d555ccb19607ff5583cfa03e8 upstream.

Add missing platform_set_drvdata() in mace_probe(), otherwise calling platform_get_drvdata() in mac_mace_device_remove() may returns NULL.

---
 drivers/net/ethernet/apple/macmace.c | 1 +
 1 file changed, 1 insertion(+)
drivers/net/ethernet/apple/macmace.c +1 -0
index 4ce8ceb62205..58a200df4c35 100644
@@ -211,6 +211,7 @@ static int mace_probe(struct platform_device *pdev)
 	mp = netdev_priv(dev);
 
 	mp->device = &pdev->dev;
+	platform_set_drvdata(pdev, dev);
 	SET_NETDEV_DEV(dev, &pdev->dev);
 
 	dev->base_addr = (u32)MACE_BASE;
Signature · 1 line
2.6.3
author
#59 lore raw

PATCH 57/72 r8169: fix the incorrect tx descriptor version

In reply to Jiri Slaby

From: hayeswang <[email protected]>

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

===============

commit f75761b6b5bf6277296505941d2dd8e11f9b5c35 upstream.

The tx descriptor version of RTL8111B belong to RTL_TD_0.

---
 drivers/net/ethernet/realtek/r8169.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/realtek/r8169.c +1 -1
index 8808a16eb691..48b7d41eced1 100644
@@ -210,7 +210,7 @@ static const struct {
 	[RTL_GIGA_MAC_VER_16] =
 		_R("RTL8101e",		RTL_TD_0, NULL, JUMBO_1K, true),
 	[RTL_GIGA_MAC_VER_17] =
-		_R("RTL8168b/8111b",	RTL_TD_1, NULL, JUMBO_4K, false),
+		_R("RTL8168b/8111b",	RTL_TD_0, NULL, JUMBO_4K, false),
 	[RTL_GIGA_MAC_VER_18] =
 		_R("RTL8168cp/8111cp",	RTL_TD_1, NULL, JUMBO_6K, false),
 	[RTL_GIGA_MAC_VER_19] =
Signature · 1 line
2.6.3
author
#60 lore raw

PATCH 58/72 r8169: disable L23

In reply to Jiri Slaby

From: hayeswang <[email protected]>

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

===============

commit b51ecea852b712618796d9eab8428a7d5f1f106f upstream.

For RTL8411, RTL8111G, RTL8402, RTL8105, and RTL8106, disable the feature of entering the L2/L3 link state of the PCIe. When the nic starts the process of entering the L2/L3 link state and the PCI reset occurs before the work is finished, the work would be queued and continue after the next the PCI reset occurs. This causes the device stays in L2/L3 link state, and the system couldn't find the device.

---
 drivers/net/ethernet/realtek/r8169.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)
drivers/net/ethernet/realtek/r8169.c +25 -0
index 48b7d41eced1..208f023d37ac 100644
@@ -539,6 +539,7 @@ enum rtl_register_content {
 	MagicPacket	= (1 << 5),	/* Wake up when receives a Magic Packet */
 	LinkUp		= (1 << 4),	/* Wake up when the cable connection is re-established */
 	Jumbo_En0	= (1 << 2),	/* 8168 only. Reserved in the 8168b */
+	Rdy_to_L23	= (1 << 1),	/* L23 Enable */
 	Beacon_en	= (1 << 0),	/* 8168 only. Reserved in the 8168b */
 
 	/* Config4 register */
@@ -4898,6 +4899,21 @@ static void rtl_enable_clock_request(struct pci_dev *pdev)
 				 PCI_EXP_LNKCTL_CLKREQ_EN);
 }
 
+static void rtl_pcie_state_l2l3_enable(struct rtl8169_private *tp, bool enable)
+{
+	void __iomem *ioaddr = tp->mmio_addr;
+	u8 data;
+
+	data = RTL_R8(Config3);
+
+	if (enable)
+		data |= Rdy_to_L23;
+	else
+		data &= ~Rdy_to_L23;
+
+	RTL_W8(Config3, data);
+}
+
 #define R8168_CPCMD_QUIRK_MASK (\
 	EnableBist | \
 	Mac_dbgo_oe | \
@@ -5247,6 +5263,7 @@ static void rtl_hw_start_8411(struct rtl8169_private *tp)
 	};
 
 	rtl_hw_start_8168f(tp);
+	rtl_pcie_state_l2l3_enable(tp, false);
 
 	rtl_ephy_init(tp, e_info_8168f_1, ARRAY_SIZE(e_info_8168f_1));
 
@@ -5285,6 +5302,8 @@ static void rtl_hw_start_8168g_1(struct rtl8169_private *tp)
 
 	rtl_w1w0_eri(tp, 0x2fc, ERIAR_MASK_0001, 0x01, 0x06, ERIAR_EXGMAC);
 	rtl_w1w0_eri(tp, 0x1b0, ERIAR_MASK_0011, 0x0000, 0x1000, ERIAR_EXGMAC);
+
+	rtl_pcie_state_l2l3_enable(tp, false);
 }
 
 static void rtl_hw_start_8168g_2(struct rtl8169_private *tp)
@@ -5537,6 +5556,8 @@ static void rtl_hw_start_8105e_1(struct rtl8169_private *tp)
 	RTL_W8(DLLPR, RTL_R8(DLLPR) | PFM_EN);
 
 	rtl_ephy_init(tp, e_info_8105e_1, ARRAY_SIZE(e_info_8105e_1));
+
+	rtl_pcie_state_l2l3_enable(tp, false);
 }
 
 static void rtl_hw_start_8105e_2(struct rtl8169_private *tp)
@@ -5572,6 +5593,8 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
 	rtl_eri_write(tp, 0xc0, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
 	rtl_eri_write(tp, 0xb8, ERIAR_MASK_0011, 0x0000, ERIAR_EXGMAC);
 	rtl_w1w0_eri(tp, 0x0d4, ERIAR_MASK_0011, 0x0e00, 0xff00, ERIAR_EXGMAC);
+
+	rtl_pcie_state_l2l3_enable(tp, false);
 }
 
 static void rtl_hw_start_8106(struct rtl8169_private *tp)
@@ -5584,6 +5607,8 @@ static void rtl_hw_start_8106(struct rtl8169_private *tp)
 	RTL_W32(MISC, (RTL_R32(MISC) | DISABLE_LAN_EN) & ~EARLY_TALLY_EN);
 	RTL_W8(MCU, RTL_R8(MCU) | EN_NDP | EN_OOB_RESET);
 	RTL_W8(DLLPR, RTL_R8(DLLPR) & ~PFM_EN);
+
+	rtl_pcie_state_l2l3_enable(tp, false);
 }
 
 static void rtl_hw_start_8101(struct net_device *dev)
Signature · 1 line
2.6.3
author
#61 lore raw

PATCH 59/72 serial: 8250_dw: Fix deadlock in LCR workaround

In reply to Jiri Slaby

From: Peter Hurley <[email protected]>

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

===============

commit 7fd6f640f2dd17dac6ddd6702c378cb0bb9cfa11 upstream.

Trying to write console output from within the serial console driver while the port->lock is held causes recursive deadlock:

CPU 0
spin_lock_irqsave(&port->lock)
printk()
console_unlock()

    call_console_drivers()
      serial8250_console_write()
        spin_lock_irqsave(&port->lock)

** DEADLOCK **

The 8250_dw i/o accessors try to write a console error message if the LCR workaround was unsuccessful. When the port->lock is already held (eg., when called from serial8250_set_termios()), this deadlocks.

Make the error message a FIXME until a general solution is devised.

---
 drivers/tty/serial/8250/8250_dw.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/tty/serial/8250/8250_dw.c +8 -2
index 70ecf541b77a..1831a138480c 100644
@@ -101,7 +101,10 @@ static void dw8250_serial_out(struct uart_port *p, int offset, int value)
 			dw8250_force_idle(p);
 			writeb(value, p->membase + (UART_LCR << p->regshift));
 		}
-		dev_err(p->dev, "Couldn't set LCR to %d\n", value);
+		/*
+		 * FIXME: this deadlocks if port->lock is already held
+		 * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
+		 */
 	}
 }
 
@@ -138,7 +141,10 @@ static void dw8250_serial_out32(struct uart_port *p, int offset, int value)
 			dw8250_force_idle(p);
 			writel(value, p->membase + (UART_LCR << p->regshift));
 		}
-		dev_err(p->dev, "Couldn't set LCR to %d\n", value);
+		/*
+		 * FIXME: this deadlocks if port->lock is already held
+		 * dev_err(p->dev, "Couldn't set LCR to %d\n", value);
+		 */
 	}
 }
 
Signature · 1 line
2.6.3
author
#62 lore raw

PATCH 60/72 ARM: orion: Fix DSA platform device after mvmdio conversion

In reply to Jiri Slaby

From: Florian Fainelli <[email protected]>

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

===============

commit d836ace65ee98d7079bc3c5afdbcc0e27dca20a3 upstream.

DSA expects the host_dev pointer to be the device structure associated with the MDIO bus controller driver. First commit breaking that was c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver"), and then, it got completely under the radar for a while.

Fixes c3a07134e6aa ("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
---
 arch/arm/plat-orion/common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/plat-orion/common.c +1 -1
index c66d163d7a2a..b1e00f37016e 100644
@@ -498,7 +498,7 @@ void __init orion_ge00_switch_init(struct dsa_platform_data *d, int irq)
 
 	d->netdev = &orion_ge00.dev;
 	for (i = 0; i < d->nr_chips; i++)
-		d->chip[i].mii_bus = &orion_ge00_shared.dev;
+		d->chip[i].mii_bus = &orion_ge_mvmdio.dev;
 	orion_switch_device.dev.platform_data = d;
 
 	platform_device_register(&orion_switch_device);
Signature · 1 line
2.6.3
author
#63 lore raw

PATCH 61/72 rbd: don't leak parent_spec in rbd_dev_probe_parent()

In reply to Jiri Slaby

From: Ilya Dryomov <[email protected]>

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

===============

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.

---
 drivers/block/rbd.c | 35 +++++++++++++++--------------------
 1 file changed, 15 insertions(+), 20 deletions(-)
drivers/block/rbd.c +15 -20
index 6d3ec00ba845..5a8f190b828e 100644
@@ -4842,41 +4842,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;
 }
 
Signature · 1 line
2.6.3
author
#64 lore raw

PATCH 62/72 rbd: prevent kernel stack blow up on rbd map

In reply to Jiri Slaby

From: Ilya Dryomov <[email protected]>

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

===============

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.

---
 drivers/block/rbd.c | 29 +++++++++++++++++++++--------
 1 file changed, 21 insertions(+), 8 deletions(-)
drivers/block/rbd.c +21 -8
index 5a8f190b828e..6be31539332f 100644
@@ -93,6 +93,8 @@ static int atomic_dec_return_safe(atomic_t *v)
 
 #define RBD_MINORS_PER_MAJOR	256		/* max minors per blkdev */
 
+#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))
@@ -394,7 +396,7 @@ static ssize_t rbd_add(struct bus_type *bus, const char *buf,
 		       size_t count);
 static ssize_t rbd_remove(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 BUS_ATTR(add, S_IWUSR, NULL, rbd_add);
@@ -4839,7 +4841,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;
@@ -4847,6 +4854,12 @@ static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
 	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;
@@ -4860,7 +4873,7 @@ static int rbd_dev_probe_parent(struct rbd_device *rbd_dev)
 	__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;
 
@@ -4977,7 +4990,7 @@ static void rbd_dev_image_release(struct rbd_device *rbd_dev)
  * 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;
 	int tmp;
@@ -4998,7 +5011,7 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
 	if (ret)
 		goto err_out_format;
 
-	if (mapping) {
+	if (!depth) {
 		ret = rbd_dev_header_watch_sync(rbd_dev, true);
 		if (ret)
 			goto out_header_name;
@@ -5015,7 +5028,7 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
 	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;
 
@@ -5026,7 +5039,7 @@ static int rbd_dev_image_probe(struct rbd_device *rbd_dev, bool mapping)
 err_out_probe:
 	rbd_dev_unprobe(rbd_dev);
 err_out_watch:
-	if (mapping) {
+	if (!depth) {
 		tmp = rbd_dev_header_watch_sync(rbd_dev, false);
 		if (tmp)
 			rbd_warn(rbd_dev, "unable to tear down "
@@ -5097,7 +5110,7 @@ static ssize_t rbd_add(struct bus_type *bus,
 	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;
 
Signature · 1 line
2.6.3
author
#65 lore raw

PATCH 63/72 KEYS: Fix race between key destruction and finding a keyring by name

In reply to Jiri Slaby

From: David Howells <[email protected]>

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

===============

commit 94c4554ba07adbdde396748ee7ae01e86cf2d8d7 upstream.

There appears to be a race between:

(1) key_gc_unused_keys() which frees key->security and then calls keyring_destroy() to unlink the name from the name list

(2) find_keyring_by_name() which calls key_permission(), thus accessing key->security, on a key before checking to see whether the key usage is 0 (ie. the key is dead and might be cleaned up).

Fix this by calling ->destroy() before cleaning up the core key data - including key->security.

---
 security/keys/gc.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
security/keys/gc.c +4 -4
index 797818695c87..483ebdf9c383 100644
@@ -187,6 +187,10 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
 		kdebug("- %u", key->serial);
 		key_check(key);
 
+		/* Throw away the key data */
+		if (key->type->destroy)
+			key->type->destroy(key);
+
 		security_key_free(key);
 
 		/* deal with the user's key tracking and quota */
@@ -201,10 +205,6 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
 		if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags))
 			atomic_dec(&key->user->nikeys);
 
-		/* now throw away the key memory */
-		if (key->type->destroy)
-			key->type->destroy(key);
-
 		key_user_put(key->user);
 
 		kfree(key->description);
Signature · 1 line
2.6.3
author
#66 lore raw

PATCH 64/72 KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring

In reply to Jiri Slaby

From: David Howells <[email protected]>

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

===============

commit f05819df10d7b09f6d1eb6f8534a8f68e5a4fe61 upstream.

The following sequence of commands:

i=keyctl add user a a @s
keyctl request2 keyring foo bar @t
keyctl unlink $i @s

tries to invoke an upcall to instantiate a keyring if one doesn't already exist by that name within the user's keyring set. However, if the upcall fails, the code sets keyring->type_data.reject_error to -ENOKEY or some other error code. When the key is garbage collected, the key destroy function is called unconditionally and keyring_destroy() uses list_empty() on keyring->type_data.link - which is in a union with reject_error. Subsequently, the kernel tries to unlink the keyring from the keyring names list - which oopses like this:

	BUG: unable to handle kernel paging request at 00000000ffffff8a
	IP: [<ffffffff8126e051>] keyring_destroy+0x3d/0x88
	...
	Workqueue: events key_garbage_collector
	...
	RIP: 0010:[<ffffffff8126e051>] keyring_destroy+0x3d/0x88
	RSP: 0018:ffff88003e2f3d30  EFLAGS: 00010203
	RAX: 00000000ffffff82 RBX: ffff88003bf1a900 RCX: 0000000000000000
	RDX: 0000000000000000 RSI: 000000003bfc6901 RDI: ffffffff81a73a40
	RBP: ffff88003e2f3d38 R08: 0000000000000152 R09: 0000000000000000
	R10: ffff88003e2f3c18 R11: 000000000000865b R12: ffff88003bf1a900
	R13: 0000000000000000 R14: ffff88003bf1a908 R15: ffff88003e2f4000
	...
	CR2: 00000000ffffff8a CR3: 000000003e3ec000 CR4: 00000000000006f0
	...
	Call Trace:
	 [<ffffffff8126c756>] key_gc_unused_keys.constprop.1+0x5d/0x10f
	 [<ffffffff8126ca71>] key_garbage_collector+0x1fa/0x351
	 [<ffffffff8105ec9b>] process_one_work+0x28e/0x547
	 [<ffffffff8105fd17>] worker_thread+0x26e/0x361
	 [<ffffffff8105faa9>] ? rescuer_thread+0x2a8/0x2a8
	 [<ffffffff810648ad>] kthread+0xf3/0xfb
	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2
	 [<ffffffff815f2ccf>] ret_from_fork+0x3f/0x70
	 [<ffffffff810647ba>] ? kthread_create_on_node+0x1c2/0x1c2

Note the value in RAX. This is a 32-bit representation of -ENOKEY.

The solution is to only call ->destroy() if the key was successfully instantiated.

---
 security/keys/gc.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)
security/keys/gc.c +4 -2
index 483ebdf9c383..de34c290bd6f 100644
@@ -187,8 +187,10 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
 		kdebug("- %u", key->serial);
 		key_check(key);
 
-		/* Throw away the key data */
-		if (key->type->destroy)
+		/* Throw away the key data if the key is instantiated */
+		if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags) &&
+		    !test_bit(KEY_FLAG_NEGATIVE, &key->flags) &&
+		    key->type->destroy)
 			key->type->destroy(key);
 
 		security_key_free(key);
Signature · 1 line
2.6.3
author
#67 lore raw

PATCH 65/72 KVM: x86: Defining missing x86 vectors

In reply to Jiri Slaby

From: Nadav Amit <[email protected]>

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

===============

commit c9cdd085bb75226879fd468b88e2e7eb467325b7 upstream.

Defining XE, XM and VE vector numbers.

---
 arch/x86/include/uapi/asm/kvm.h | 3 +++
 1 file changed, 3 insertions(+)
arch/x86/include/uapi/asm/kvm.h +3 -0
index 5d9a3033b3d7..53077f94ec1f 100644
@@ -23,7 +23,10 @@
 #define GP_VECTOR 13
 #define PF_VECTOR 14
 #define MF_VECTOR 16
+#define AC_VECTOR 17
 #define MC_VECTOR 18
+#define XM_VECTOR 19
+#define VE_VECTOR 20
 
 /* Select x86 specific features in <linux/kvm.h> */
 #define __KVM_HAVE_PIT
Signature · 1 line
2.6.3
author
#68 lore raw

PATCH 66/72 KVM: x86: work around infinite loop in microcode when #AC is delivered

In reply to Jiri Slaby

From: Eric Northup <[email protected]>

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

===============

commit 54a20552e1eae07aa240fa370a0293e006b5faed upstream.

It was found that a guest can DoS a host by triggering an infinite stream of "alignment check" (#AC) exceptions. This causes the microcode to enter an infinite loop where the core never receives another interrupt. The host kernel panics pretty quickly due to the effects (CVE-2015-5307).

---
 arch/x86/include/uapi/asm/svm.h | 1 +
 arch/x86/kvm/svm.c              | 8 ++++++++
 arch/x86/kvm/vmx.c              | 5 ++++-
 3 files changed, 13 insertions(+), 1 deletion(-)
arch/x86/include/uapi/asm/svm.h +1 -0
index b5d7640abc5d..8a4add8e4639 100644
@@ -100,6 +100,7 @@
 	{ SVM_EXIT_EXCP_BASE + UD_VECTOR,       "UD excp" }, \
 	{ SVM_EXIT_EXCP_BASE + PF_VECTOR,       "PF excp" }, \
 	{ SVM_EXIT_EXCP_BASE + NM_VECTOR,       "NM excp" }, \
+	{ SVM_EXIT_EXCP_BASE + AC_VECTOR,       "AC excp" }, \
 	{ SVM_EXIT_EXCP_BASE + MC_VECTOR,       "MC excp" }, \
 	{ SVM_EXIT_INTR,        "interrupt" }, \
 	{ SVM_EXIT_NMI,         "nmi" }, \
arch/x86/kvm/svm.c +8 -0
index d1a065ec683f..db4108b82e6b 100644
@@ -1103,6 +1103,7 @@ static void init_vmcb(struct vcpu_svm *svm)
 	set_exception_intercept(svm, PF_VECTOR);
 	set_exception_intercept(svm, UD_VECTOR);
 	set_exception_intercept(svm, MC_VECTOR);
+	set_exception_intercept(svm, AC_VECTOR);
 
 	set_intercept(svm, INTERCEPT_INTR);
 	set_intercept(svm, INTERCEPT_NMI);
@@ -1765,6 +1766,12 @@ static int ud_interception(struct vcpu_svm *svm)
 	return 1;
 }
 
+static int ac_interception(struct vcpu_svm *svm)
+{
+	kvm_queue_exception_e(&svm->vcpu, AC_VECTOR, 0);
+	return 1;
+}
+
 static void svm_fpu_activate(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
@@ -3285,6 +3292,7 @@ static int (*const svm_exit_handlers[])(struct vcpu_svm *svm) = {
 	[SVM_EXIT_EXCP_BASE + PF_VECTOR]	= pf_interception,
 	[SVM_EXIT_EXCP_BASE + NM_VECTOR]	= nm_interception,
 	[SVM_EXIT_EXCP_BASE + MC_VECTOR]	= mc_interception,
+	[SVM_EXIT_EXCP_BASE + AC_VECTOR]	= ac_interception,
 	[SVM_EXIT_INTR]				= intr_interception,
 	[SVM_EXIT_NMI]				= nmi_interception,
 	[SVM_EXIT_SMI]				= nop_on_interception,
arch/x86/kvm/vmx.c +4 -1
index f5ddacc4c885..53fede68963d 100644
@@ -1388,7 +1388,7 @@ static void update_exception_bitmap(struct kvm_vcpu *vcpu)
 	u32 eb;
 
 	eb = (1u << PF_VECTOR) | (1u << UD_VECTOR) | (1u << MC_VECTOR) |
-	     (1u << NM_VECTOR) | (1u << DB_VECTOR);
+	     (1u << NM_VECTOR) | (1u << DB_VECTOR) | (1u << AC_VECTOR);
 	if ((vcpu->guest_debug &
 	     (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP)) ==
 	    (KVM_GUESTDBG_ENABLE | KVM_GUESTDBG_USE_SW_BP))
@@ -4812,6 +4812,9 @@ static int handle_exception(struct kvm_vcpu *vcpu)
 		return handle_rmode_exception(vcpu, ex_no, error_code);
 
 	switch (ex_no) {
+	case AC_VECTOR:
+		kvm_queue_exception_e(vcpu, AC_VECTOR, error_code);
+		return 1;
 	case DB_VECTOR:
 		dr6 = vmcs_readl(EXIT_QUALIFICATION);
 		if (!(vcpu->guest_debug &
Signature · 1 line
2.6.3
author
#69 lore raw

PATCH 67/72 KVM: svm: unconditionally intercept #DB

In reply to Jiri Slaby

From: Paolo Bonzini <[email protected]>

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

===============

commit cbdb967af3d54993f5814f1cee0ed311a055377d upstream.

This is needed to avoid the possibility that the guest triggers an infinite stream of #DB exceptions (CVE-2015-8104).

VMX is not affected: because it does not save DR6 in the VMCS, it already intercepts #DB unconditionally.

---
 arch/x86/kvm/svm.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)
arch/x86/kvm/svm.c +3 -11
index db4108b82e6b..289897326da4 100644
@@ -1104,6 +1104,7 @@ static void init_vmcb(struct vcpu_svm *svm)
 	set_exception_intercept(svm, UD_VECTOR);
 	set_exception_intercept(svm, MC_VECTOR);
 	set_exception_intercept(svm, AC_VECTOR);
+	set_exception_intercept(svm, DB_VECTOR);
 
 	set_intercept(svm, INTERCEPT_INTR);
 	set_intercept(svm, INTERCEPT_NMI);
@@ -1640,20 +1641,13 @@ static void svm_set_segment(struct kvm_vcpu *vcpu,
 	mark_dirty(svm->vmcb, VMCB_SEG);
 }
 
-static void update_db_bp_intercept(struct kvm_vcpu *vcpu)
+static void update_bp_intercept(struct kvm_vcpu *vcpu)
 {
 	struct vcpu_svm *svm = to_svm(vcpu);
 
-	clr_exception_intercept(svm, DB_VECTOR);
 	clr_exception_intercept(svm, BP_VECTOR);
 
-	if (svm->nmi_singlestep)
-		set_exception_intercept(svm, DB_VECTOR);
-
 	if (vcpu->guest_debug & KVM_GUESTDBG_ENABLE) {
-		if (vcpu->guest_debug &
-		    (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))
-			set_exception_intercept(svm, DB_VECTOR);
 		if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
 			set_exception_intercept(svm, BP_VECTOR);
 	} else
@@ -1731,7 +1725,6 @@ static int db_interception(struct vcpu_svm *svm)
 		if (!(svm->vcpu.guest_debug & KVM_GUESTDBG_SINGLESTEP))
 			svm->vmcb->save.rflags &=
 				~(X86_EFLAGS_TF | X86_EFLAGS_RF);
-		update_db_bp_intercept(&svm->vcpu);
 	}
 
 	if (svm->vcpu.guest_debug &
@@ -3681,7 +3674,6 @@ static int enable_nmi_window(struct kvm_vcpu *vcpu)
 	 */
 	svm->nmi_singlestep = true;
 	svm->vmcb->save.rflags |= (X86_EFLAGS_TF | X86_EFLAGS_RF);
-	update_db_bp_intercept(vcpu);
 	return 0;
 }
 
@@ -4283,7 +4275,7 @@ static struct kvm_x86_ops svm_x86_ops = {
 	.vcpu_load = svm_vcpu_load,
 	.vcpu_put = svm_vcpu_put,
 
-	.update_db_bp_intercept = update_db_bp_intercept,
+	.update_db_bp_intercept = update_bp_intercept,
 	.get_msr = svm_get_msr,
 	.set_msr = svm_set_msr,
 	.get_segment_base = svm_get_segment_base,
Signature · 1 line
2.6.3
author
#70 lore raw

PATCH 68/72 KVM: x86: Fix far-jump to non-canonical check

In reply to Jiri Slaby

From: Nadav Amit <[email protected]>

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

===============

commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream.

Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps") introduced a bug that caused the fix to be incomplete. Due to incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may not trigger #GP. As we know, this imposes a security problem.

In addition, the condition for two warnings was incorrect.

Fixes d1442d85cc30ea75f7d399474ca738e0bc96f715
[Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
---
 arch/x86/kvm/emulate.c | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)
arch/x86/kvm/emulate.c +5 -3
index 8216f484398f..ffae11d0754a 100644
@@ -582,12 +582,14 @@ static inline int assign_eip_far(struct x86_emulate_ctxt *ctxt, ulong dst,
 	case 4:
 		ctxt->_eip = (u32)dst;
 		break;
+#ifdef CONFIG_X86_64
 	case 8:
 		if ((cs_l && is_noncanonical_address(dst)) ||
-		    (!cs_l && (dst & ~(u32)-1)))
+		    (!cs_l && (dst >> 32) != 0))
 			return emulate_gp(ctxt, 0);
 		ctxt->_eip = dst;
 		break;
+#endif
 	default:
 		WARN(1, "unsupported eip assignment size\n");
 	}
@@ -2000,7 +2002,7 @@ static int em_jmp_far(struct x86_emulate_ctxt *ctxt)
 
 	rc = assign_eip_far(ctxt, ctxt->src.val, new_desc.l);
 	if (rc != X86EMUL_CONTINUE) {
-		WARN_ON(!ctxt->mode != X86EMUL_MODE_PROT64);
+		WARN_ON(ctxt->mode != X86EMUL_MODE_PROT64);
 		/* assigning eip failed; restore the old cs */
 		ops->set_segment(ctxt, old_sel, &old_desc, 0, VCPU_SREG_CS);
 		return rc;
@@ -2084,7 +2086,7 @@ static int em_ret_far(struct x86_emulate_ctxt *ctxt)
 		return rc;
 	rc = assign_eip_far(ctxt, eip, new_desc.l);
 	if (rc != X86EMUL_CONTINUE) {
-		WARN_ON(!ctxt->mode != X86EMUL_MODE_PROT64);
+		WARN_ON(ctxt->mode != X86EMUL_MODE_PROT64);
 		ops->set_segment(ctxt, old_cs, &old_desc, 0, VCPU_SREG_CS);
 	}
 	return rc;
Signature · 1 line
2.6.3
author
#71 lore raw

PATCH 69/72 KVM: x86: Use new is_noncanonical_address in _linearize

In reply to Jiri Slaby

From: Nadav Amit <[email protected]>

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

===============

commit 4be4de7ef9fd3a4d77320d4713970299ffecd286 upstream.

Replace the current canonical address check with the new function which is identical.

---
 arch/x86/kvm/emulate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/kvm/emulate.c +1 -1
index ffae11d0754a..cad86cd56f82 100644
@@ -664,7 +664,7 @@ static int __linearize(struct x86_emulate_ctxt *ctxt,
 	la = seg_base(ctxt, addr.seg) + addr.ea;
 	switch (ctxt->mode) {
 	case X86EMUL_MODE_PROT64:
-		if (((signed long)la << 16) >> 16 != la)
+		if (is_noncanonical_address(la))
 			return emulate_gp(ctxt, 0);
 		break;
 	default:
Signature · 1 line
2.6.3
author
#72 lore raw

PATCH 70/72 ipv6: addrconf: validate new MTU before applying it

In reply to Jiri Slaby

From: Marcelo Leitner <[email protected]>

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

===============

commit 77751427a1ff25b27d47a4c36b12c3c8667855ac upstream.

Currently we don't check if the new MTU is valid or not and this allows one to configure a smaller than minimum allowed by RFCs or even bigger than interface own MTU, which is a problem as it may lead to packet drops.

If you have a daemon like NetworkManager running, this may be exploited by remote attackers by forging RA packets with an invalid MTU, possibly leading to a DoS. (NetworkManager currently only validates for values too small, but not for too big ones.)

The fix is just to make sure the new value is valid. That is, between IPV6_MIN_MTU and interface's MTU.

Note that similar check is already performed at ndisc_router_discovery(), for when kernel itself parses the RA.

---
 net/ipv6/addrconf.c | 17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)
net/ipv6/addrconf.c +16 -1
index 87f1a70bd234..38540a3ed92f 100644
@@ -4656,6 +4656,21 @@ int addrconf_sysctl_forward(struct ctl_table *ctl, int write,
 	return ret;
 }
 
+static
+int addrconf_sysctl_mtu(struct ctl_table *ctl, int write,
+			void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+	struct inet6_dev *idev = ctl->extra1;
+	int min_mtu = IPV6_MIN_MTU;
+	struct ctl_table lctl;
+
+	lctl = *ctl;
+	lctl.extra1 = &min_mtu;
+	lctl.extra2 = idev ? &idev->dev->mtu : NULL;
+
+	return proc_dointvec_minmax(&lctl, write, buffer, lenp, ppos);
+}
+
 static void dev_disable_change(struct inet6_dev *idev)
 {
 	struct netdev_notifier_info info;
@@ -4767,7 +4782,7 @@ static struct addrconf_sysctl_table
 			.data		= &ipv6_devconf.mtu6,
 			.maxlen		= sizeof(int),
 			.mode		= 0644,
-			.proc_handler	= proc_dointvec,
+			.proc_handler	= addrconf_sysctl_mtu,
 		},
 		{
 			.procname	= "accept_ra",
Signature · 1 line
2.6.3
author
#73 lore raw

PATCH 71/72 x86/mm/hotplug: Pass sync_global_pgds() a correct argument in remove_pagetable()

In reply to Jiri Slaby

From: Yasuaki Ishimatsu <[email protected]>

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

===============

commit 5255e0a79fcc0ff47b387af92bd9ef5729b1b859 upstream.

When hot-adding memory after hot-removing memory, following call traces are shown:

kernel BUG at arch/x86/mm/init_64.c:206!
...

 [<ffffffff815e0c80>] kernel_physical_mapping_init+0x1b2/0x1d2
 [<ffffffff815ced94>] init_memory_mapping+0x1d4/0x380
 [<ffffffff8104aebd>] arch_add_memory+0x3d/0xd0
 [<ffffffff815d03d9>] add_memory+0xb9/0x1b0
 [<ffffffff81352415>] acpi_memory_device_add+0x1af/0x28e
 [<ffffffff81325dc4>] acpi_bus_device_attach+0x8c/0xf0
 [<ffffffff813413b9>] acpi_ns_walk_namespace+0xc8/0x17f
 [<ffffffff81325d38>] ? acpi_bus_type_and_status+0xb7/0xb7
 [<ffffffff81325d38>] ? acpi_bus_type_and_status+0xb7/0xb7
 [<ffffffff813418ed>] acpi_walk_namespace+0x95/0xc5
 [<ffffffff81326b4c>] acpi_bus_scan+0x9a/0xc2
 [<ffffffff81326bff>] acpi_scan_bus_device_check+0x8b/0x12e
 [<ffffffff81326cb5>] acpi_scan_device_check+0x13/0x15
 [<ffffffff81320122>] acpi_os_execute_deferred+0x25/0x32
 [<ffffffff8107e02b>] process_one_work+0x17b/0x460
 [<ffffffff8107edfb>] worker_thread+0x11b/0x400
 [<ffffffff8107ece0>] ? rescuer_thread+0x400/0x400
 [<ffffffff81085aef>] kthread+0xcf/0xe0
 [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
 [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0
 [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140

The patch-set fixes the issue.

This patch (of 2):

remove_pagetable() gets start argument and passes the argument to sync_global_pgds(). In this case, the argument must not be modified. If the argument is modified and passed to sync_global_pgds(), sync_global_pgds() does not correctly synchronize PGD to PGD entries of all processes MM since synchronized range of memory [start, end] is wrong.

Unfortunately the start argument is modified in remove_pagetable(). So this patch fixes the issue.

---
 arch/x86/mm/init_64.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
arch/x86/mm/init_64.c +5 -4
index a93e32722ab1..427b536a5fd6 100644
@@ -975,19 +975,20 @@ static void __meminit
 remove_pagetable(unsigned long start, unsigned long end, bool direct)
 {
 	unsigned long next;
+	unsigned long addr;
 	pgd_t *pgd;
 	pud_t *pud;
 	bool pgd_changed = false;
 
-	for (; start < end; start = next) {
-		next = pgd_addr_end(start, end);
+	for (addr = start; addr < end; addr = next) {
+		next = pgd_addr_end(addr, end);
 
-		pgd = pgd_offset_k(start);
+		pgd = pgd_offset_k(addr);
 		if (!pgd_present(*pgd))
 			continue;
 
 		pud = (pud_t *)pgd_page_vaddr(*pgd);
-		remove_pud_table(pud, start, next, direct);
+		remove_pud_table(pud, addr, next, direct);
 		if (free_pud_table(pud, pgd))
 			pgd_changed = true;
 	}
Signature · 1 line
2.6.3
author
#74 lore raw

PATCH 72/72 x86/mm/hotplug: Modify PGD entry when removing memory

In reply to Jiri Slaby

From: Yasuaki Ishimatsu <[email protected]>

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

===============

commit 9661d5bcd058fe15b4138a00d96bd36516134543 upstream.

When hot-adding/removing memory, sync_global_pgds() is called for synchronizing PGD to PGD entries of all processes MM. But when hot-removing memory, sync_global_pgds() does not work correctly.

At first, sync_global_pgds() checks whether target PGD is none or not. And if PGD is none, the PGD is skipped. But when hot-removing memory, PGD may be none since PGD may be cleared by free_pud_table(). So when sync_global_pgds() is called after hot-removing memory, sync_global_pgds() should not skip PGD even if the PGD is none. And sync_global_pgds() must clear PGD entries of all processes MM.

Currently sync_global_pgds() does not clear PGD entries of all processes MM when hot-removing memory. So when hot adding memory which is same memory range as removed memory after hot-removing memory, following call traces are shown:

kernel BUG at arch/x86/mm/init_64.c:206!
...

 [<ffffffff815e0c80>] kernel_physical_mapping_init+0x1b2/0x1d2
 [<ffffffff815ced94>] init_memory_mapping+0x1d4/0x380
 [<ffffffff8104aebd>] arch_add_memory+0x3d/0xd0
 [<ffffffff815d03d9>] add_memory+0xb9/0x1b0
 [<ffffffff81352415>] acpi_memory_device_add+0x1af/0x28e
 [<ffffffff81325dc4>] acpi_bus_device_attach+0x8c/0xf0
 [<ffffffff813413b9>] acpi_ns_walk_namespace+0xc8/0x17f
 [<ffffffff81325d38>] ? acpi_bus_type_and_status+0xb7/0xb7
 [<ffffffff81325d38>] ? acpi_bus_type_and_status+0xb7/0xb7
 [<ffffffff813418ed>] acpi_walk_namespace+0x95/0xc5
 [<ffffffff81326b4c>] acpi_bus_scan+0x9a/0xc2
 [<ffffffff81326bff>] acpi_scan_bus_device_check+0x8b/0x12e
 [<ffffffff81326cb5>] acpi_scan_device_check+0x13/0x15
 [<ffffffff81320122>] acpi_os_execute_deferred+0x25/0x32
 [<ffffffff8107e02b>] process_one_work+0x17b/0x460
 [<ffffffff8107edfb>] worker_thread+0x11b/0x400
 [<ffffffff8107ece0>] ? rescuer_thread+0x400/0x400
 [<ffffffff81085aef>] kthread+0xcf/0xe0
 [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140
 [<ffffffff815fc76c>] ret_from_fork+0x7c/0xb0
 [<ffffffff81085a20>] ? kthread_create_on_node+0x140/0x140

This patch clears PGD entries of all processes MM when sync_global_pgds() is called after hot-removing memory

---
 arch/x86/include/asm/pgtable_64.h |  3 ++-
 arch/x86/mm/fault.c               |  2 +-
 arch/x86/mm/init_64.c             | 27 +++++++++++++++++++--------
 3 files changed, 22 insertions(+), 10 deletions(-)
arch/x86/include/asm/pgtable_64.h +2 -1
index e22c1dbf7feb..60ac4a1a7761 100644
@@ -115,7 +115,8 @@ static inline void native_pgd_clear(pgd_t *pgd)
 	native_set_pgd(pgd, native_make_pgd(0));
 }
 
-extern void sync_global_pgds(unsigned long start, unsigned long end);
+extern void sync_global_pgds(unsigned long start, unsigned long end,
+			     int removed);
 
 /*
  * Conversion functions: convert a page and protection to a page entry,
arch/x86/mm/fault.c +1 -1
index 814a25d88738..43df028362f9 100644
@@ -345,7 +345,7 @@ out:
 
 void vmalloc_sync_all(void)
 {
-	sync_global_pgds(VMALLOC_START & PGDIR_MASK, VMALLOC_END);
+	sync_global_pgds(VMALLOC_START & PGDIR_MASK, VMALLOC_END, 0);
 }
 
 /*
arch/x86/mm/init_64.c +19 -8
index 427b536a5fd6..d7735ceca5ac 100644
@@ -178,7 +178,7 @@ __setup("noexec32=", nonx32_setup);
  * When memory was added/removed make sure all the processes MM have
  * suitable PGD entries in the local PGD level page.
  */
-void sync_global_pgds(unsigned long start, unsigned long end)
+void sync_global_pgds(unsigned long start, unsigned long end, int removed)
 {
 	unsigned long address;
 
@@ -186,7 +186,12 @@ void sync_global_pgds(unsigned long start, unsigned long end)
 		const pgd_t *pgd_ref = pgd_offset_k(address);
 		struct page *page;
 
-		if (pgd_none(*pgd_ref))
+		/*
+		 * When it is called after memory hot remove, pgd_none()
+		 * returns true. In this case (removed == 1), we must clear
+		 * the PGD entries in the local PGD level page.
+		 */
+		if (pgd_none(*pgd_ref) && !removed)
 			continue;
 
 		spin_lock(&pgd_lock);
@@ -199,12 +204,18 @@ void sync_global_pgds(unsigned long start, unsigned long end)
 			pgt_lock = &pgd_page_get_mm(page)->page_table_lock;
 			spin_lock(pgt_lock);
 
-			if (pgd_none(*pgd))
-				set_pgd(pgd, *pgd_ref);
-			else
+			if (!pgd_none(*pgd_ref) && !pgd_none(*pgd))
 				BUG_ON(pgd_page_vaddr(*pgd)
 				       != pgd_page_vaddr(*pgd_ref));
 
+			if (removed) {
+				if (pgd_none(*pgd_ref) && !pgd_none(*pgd))
+					pgd_clear(pgd);
+			} else {
+				if (pgd_none(*pgd))
+					set_pgd(pgd, *pgd_ref);
+			}
+
 			spin_unlock(pgt_lock);
 		}
 		spin_unlock(&pgd_lock);
@@ -633,7 +644,7 @@ kernel_physical_mapping_init(unsigned long start,
 	}
 
 	if (pgd_changed)
-		sync_global_pgds(addr, end - 1);
+		sync_global_pgds(addr, end - 1, 0);
 
 	__flush_tlb_all();
 
@@ -994,7 +1005,7 @@ remove_pagetable(unsigned long start, unsigned long end, bool direct)
 	}
 
 	if (pgd_changed)
-		sync_global_pgds(start, end - 1);
+		sync_global_pgds(start, end - 1, 1);
 
 	flush_tlb_all();
 }
@@ -1325,7 +1336,7 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node)
 	else
 		err = vmemmap_populate_basepages(start, end, node);
 	if (!err)
-		sync_global_pgds(start, end - 1);
+		sync_global_pgds(start, end - 1, 0);
 	return err;
 }
 
Signature · 1 line
2.6.3
#75 lore raw
In reply to Jiri Slaby
Quoted 8 lines · Jiri Slaby

This is the start of the stable review cycle for the 3.12.51 release. There are 72 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 Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late.

Build results:

	total: 93 pass: 93 fail: 0
Qemu test results:
	total: 58 pass: 58 fail: 0

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

Guenter

#76 lore raw
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Jiri Slaby

This is the start of the stable review cycle for the 3.12.51 release. There are 72 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 Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late.

Quoted 7 lines

Build results:

     total: 93 pass: 93 fail: 0
Qemu test results:
     total: 58 pass: 58 fail: 0

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

Oh, drat. Those are for 3.2. Please ignore the results. I'll send the results for 3.12 when available.

Sorry for the noise.

Guenter

#77 lore raw
In reply to Jiri Slaby
Quoted 8 lines · Jiri Slaby

This is the start of the stable review cycle for the 3.12.51 release. There are 72 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 Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late.

Quoted 6 lines

The whole patch series can be found in one patch at:

	http://kernel.org/pub/linux/kernel/people/jirislaby/stable-review/patch-3.12.51-rc1.xz

and the diffstat can be found below.

thanks,
js

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

thanks,
-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
#78 lore raw
In reply to Jiri Slaby
Quoted 8 lines · Jiri Slaby

This is the start of the stable review cycle for the 3.12.51 release. There are 72 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 Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late.

This time for real.

Build results:

	total: 124 pass: 124 fail: 0
Qemu test results:
	total: 78 pass: 78 fail: 0

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

Guenter

author
#79 lore raw
Quoted 18 lines · Guenter Roeck
Quoted 8 lines · Jiri Slaby

This is the start of the stable review cycle for the 3.12.51 release. There are 72 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 Wed Nov 25 14:04:50 CET 2015. Anything received after that time might be too late.

This time for real.

Build results:

    total: 124 pass: 124 fail: 0
Qemu test results:
    total: 78 pass: 78 fail: 0

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

Quoted 1 line · Shuah Khan

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

Thank you both!

Signature · 2 lines
js
suse labs