Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1608781 > unrolled thread

[PATCH 4.4 00/30] 4.4.57-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.4 00/30] 4.4.57-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:10 +0100
    [PATCH 4.4 16/30] hv_netvsc: use skb_get_hash() instead of a homegrown implementation Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 23/30] target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 21/30] powerpc/boot: Fix zImage TOC alignment Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 12/30] KVM: PPC: Book3S PR: Fix illegal opcode emulation Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 17/30] kernek/fork.c: allocate idle task for a CPU always on its local node Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 19/30] perf/core: Fix event inheritance on fork() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 01/30] usb: core: hub: hub_port_init lock controller instead of bus Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 22/30] md/raid1/10: fix potential deadlock Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 02/30] USB: dont free bandwidth_mutex too early Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 13/30] s390/pci: fix use after free in dma_init Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 15/30] tpm_tis: Use devm_free_irq not free_irq Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 24/30] scsi: lpfc: Add shutdown method for kexec Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    [PATCH 4.4 20/30] cpufreq: Fix and clean up show_cpuinfo_cur_freq() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-03-24 19:20 +0100
    Re: [PATCH 4.4 00/30] 4.4.57-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-03-25 01:10 +0100
    Re: [PATCH 4.4 00/30] 4.4.57-stable review Guenter Roeck <linux@roeck-us.net> - 2017-03-25 05:20 +0100
    Re: [PATCH 4.4 00/30] 4.4.57-stable review Guenter Roeck <linux@roeck-us.net> - 2017-03-25 05:20 +0100
      Re: [PATCH 4.4 00/30] 4.4.57-stable review Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-03-25 12:30 +0100
        Re: [PATCH 4.4 00/30] 4.4.57-stable review Alexandre Belloni <alexandre.belloni@free-electrons.com> - 2017-03-25 12:40 +0100

#1608781 — [PATCH 4.4 00/30] 4.4.57-stable review

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

Responses should be made by Sun Mar 26 15:12:02 UTC 2017.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.57-rc1.gz
or in the git tree and branch at:
  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
and the diffstat can be found below.

thanks,

greg k-h

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

Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    Linux 4.4.57-rc1

Theodore Ts'o <tytso@mit.edu>
    ext4: fix fencepost in s_first_meta_bg validation

Tahsin Erdogan <tahsin@google.com>
    percpu: acquire pcpu_lock when updating pcpu_nr_empty_pop_pages

Andreas Gruenbacher <agruenba@redhat.com>
    gfs2: Avoid alignment hole in struct lm_lockname

Johan Hovold <johan@kernel.org>
    isdn/gigaset: fix NULL-deref at probe

Max Lohrmann <post@wickenrode.com>
    target: Fix VERIFY_16 handling in sbc_parse_cdb

Chris Leech <cleech@redhat.com>
    scsi: libiscsi: add lock around task lists to fix list corruption regression

Anton Blanchard <anton@samba.org>
    scsi: lpfc: Add shutdown method for kexec

Nicholas Bellinger <nab@linux-iscsi.org>
    target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export

Shaohua Li <shli@fb.com>
    md/raid1/10: fix potential deadlock

Michael Ellerman <mpe@ellerman.id.au>
    powerpc/boot: Fix zImage TOC alignment

Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    cpufreq: Fix and clean up show_cpuinfo_cur_freq()

Peter Zijlstra <peterz@infradead.org>
    perf/core: Fix event inheritance on fork()

Linus Torvalds <torvalds@linux-foundation.org>
    give up on gcc ilog2() constant optimizations

Andi Kleen <ak@linux.intel.com>
    kernek/fork.c: allocate idle task for a CPU always on its local node

Vitaly Kuznetsov <vkuznets@redhat.com>
    hv_netvsc: use skb_get_hash() instead of a homegrown implementation

Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    tpm_tis: Use devm_free_irq not free_irq

Dave Airlie <airlied@redhat.com>
    drm/amdgpu: add missing irq.h include

Sebastian Ott <sebott@linux.vnet.ibm.com>
    s390/pci: fix use after free in dma_init

Thomas Huth <thuth@redhat.com>
    KVM: PPC: Book3S PR: Fix illegal opcode emulation

Ross Lagerwall <ross.lagerwall@citrix.com>
    xen/qspinlock: Don't kick CPU if IRQ is not initialized

Vitaly Kuznetsov <vkuznets@redhat.com>
    Drivers: hv: avoid vfree() on crash

Vitaly Kuznetsov <vkuznets@redhat.com>
    Drivers: hv: balloon: don't crash when memory is added in non-sorted order

Mika Westerberg <mika.westerberg@linux.intel.com>
    pinctrl: cherryview: Do not mask all interrupts in probe

Alex Hung <alex.hung@canonical.com>
    ACPI / video: skip evaluating _DOD when it does not exist

Manoj N. Kumar <manoj@linux.vnet.ibm.com>
    cxlflash: Increase cmd_per_lun for better throughput

Wang, Rui Y <rui.y.wang@intel.com>
    crypto: mcryptd - Fix load failure

Wang, Rui Y <rui.y.wang@intel.com>
    crypto: cryptd - Assign statesize properly

Wang, Rui Y <rui.y.wang@intel.com>
    crypto: ghash-clmulni - Fix load failure

Alan Stern <stern@rowland.harvard.edu>
    USB: don't free bandwidth_mutex too early

Chris Bainbridge <chris.bainbridge@gmail.com>
    usb: core: hub: hub_port_init lock controller instead of bus


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

Diffstat:

 Makefile                                   |  4 +-
 arch/powerpc/boot/zImage.lds.S             |  1 +
 arch/powerpc/kvm/emulate.c                 |  1 -
 arch/s390/pci/pci_dma.c                    | 16 ++++---
 arch/x86/crypto/ghash-clmulni-intel_glue.c | 26 ++++++++++++
 arch/x86/xen/spinlock.c                    |  6 +++
 crypto/cryptd.c                            |  1 +
 crypto/mcryptd.c                           |  1 +
 drivers/acpi/acpi_video.c                  |  3 ++
 drivers/char/tpm/tpm_tis.c                 |  2 +-
 drivers/cpufreq/cpufreq.c                  |  8 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c    |  1 +
 drivers/hv/hv.c                            |  8 ++--
 drivers/hv/hv_balloon.c                    |  4 +-
 drivers/hv/hyperv_vmbus.h                  |  2 +-
 drivers/hv/vmbus_drv.c                     |  8 ++--
 drivers/isdn/gigaset/bas-gigaset.c         |  3 ++
 drivers/md/raid10.c                        | 18 ++++++++
 drivers/net/hyperv/netvsc_drv.c            | 67 ++----------------------------
 drivers/pinctrl/intel/pinctrl-cherryview.c |  5 +--
 drivers/scsi/cxlflash/common.h             |  8 ++--
 drivers/scsi/cxlflash/main.c               |  2 +-
 drivers/scsi/libiscsi.c                    | 26 +++++++++++-
 drivers/scsi/lpfc/lpfc_init.c              |  1 +
 drivers/target/target_core_pscsi.c         | 47 ++++++---------------
 drivers/target/target_core_sbc.c           | 10 ++++-
 drivers/usb/core/hcd.c                     | 26 ++++++++----
 drivers/usb/core/hub.c                     |  8 ++--
 fs/ext4/super.c                            |  2 +-
 fs/gfs2/incore.h                           |  2 +-
 include/linux/log2.h                       | 13 +-----
 include/linux/usb.h                        |  3 +-
 include/linux/usb/hcd.h                    |  1 +
 include/scsi/libiscsi.h                    |  1 +
 kernel/events/core.c                       |  5 ++-
 kernel/fork.c                              | 15 ++++---
 mm/percpu.c                                |  5 ++-
 tools/include/linux/log2.h                 | 13 +-----
 38 files changed, 193 insertions(+), 180 deletions(-)

[toc] | [next] | [standalone]

#1608786 — [PATCH 4.4 16/30] hv_netvsc: use skb_get_hash() instead of a homegrown implementation

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

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

From: Vitaly Kuznetsov <vkuznets@redhat.com>

commit 757647e10e55c01fb7a9c4356529442e316a7c72 upstream.

Recent changes to 'struct flow_keys' (e.g commit d34af823ff40 ("net: Add
VLAN ID to flow_keys")) introduced a performance regression in netvsc
driver. Is problem is, however, not the above mentioned commit but the
fact that netvsc_set_hash() function did some assumptions on the struct
flow_keys data layout and this is wrong.

Get rid of netvsc_set_hash() by switching to skb_get_hash(). This change
will also imply switching to Jenkins hash from the currently used Toeplitz
but it seems there is no good excuse for Toeplitz to stay.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/net/hyperv/netvsc_drv.c |   67 +---------------------------------------
 1 file changed, 3 insertions(+), 64 deletions(-)

--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -197,65 +197,6 @@ static void *init_ppi_data(struct rndis_
 	return ppi;
 }
 
-union sub_key {
-	u64 k;
-	struct {
-		u8 pad[3];
-		u8 kb;
-		u32 ka;
-	};
-};
-
-/* Toeplitz hash function
- * data: network byte order
- * return: host byte order
- */
-static u32 comp_hash(u8 *key, int klen, void *data, int dlen)
-{
-	union sub_key subk;
-	int k_next = 4;
-	u8 dt;
-	int i, j;
-	u32 ret = 0;
-
-	subk.k = 0;
-	subk.ka = ntohl(*(u32 *)key);
-
-	for (i = 0; i < dlen; i++) {
-		subk.kb = key[k_next];
-		k_next = (k_next + 1) % klen;
-		dt = ((u8 *)data)[i];
-		for (j = 0; j < 8; j++) {
-			if (dt & 0x80)
-				ret ^= subk.ka;
-			dt <<= 1;
-			subk.k <<= 1;
-		}
-	}
-
-	return ret;
-}
-
-static bool netvsc_set_hash(u32 *hash, struct sk_buff *skb)
-{
-	struct flow_keys flow;
-	int data_len;
-
-	if (!skb_flow_dissect_flow_keys(skb, &flow, 0) ||
-	    !(flow.basic.n_proto == htons(ETH_P_IP) ||
-	      flow.basic.n_proto == htons(ETH_P_IPV6)))
-		return false;
-
-	if (flow.basic.ip_proto == IPPROTO_TCP)
-		data_len = 12;
-	else
-		data_len = 8;
-
-	*hash = comp_hash(netvsc_hash_key, HASH_KEYLEN, &flow, data_len);
-
-	return true;
-}
-
 static u16 netvsc_select_queue(struct net_device *ndev, struct sk_buff *skb,
 			void *accel_priv, select_queue_fallback_t fallback)
 {
@@ -268,11 +209,9 @@ static u16 netvsc_select_queue(struct ne
 	if (nvsc_dev == NULL || ndev->real_num_tx_queues <= 1)
 		return 0;
 
-	if (netvsc_set_hash(&hash, skb)) {
-		q_idx = nvsc_dev->send_table[hash % VRSS_SEND_TAB_SIZE] %
-			ndev->real_num_tx_queues;
-		skb_set_hash(skb, hash, PKT_HASH_TYPE_L3);
-	}
+	hash = skb_get_hash(skb);
+	q_idx = nvsc_dev->send_table[hash % VRSS_SEND_TAB_SIZE] %
+		ndev->real_num_tx_queues;
 
 	return q_idx;
 }

[toc] | [prev] | [next] | [standalone]

#1608787 — [PATCH 4.4 23/30] target/pscsi: Fix TYPE_TAPE + TYPE_MEDIMUM_CHANGER export

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

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

From: Nicholas Bellinger <nab@linux-iscsi.org>

commit a04e54f2c35823ca32d56afcd5cea5b783e2f51a upstream.

The following fixes a divide by zero OOPs with TYPE_TAPE
due to pscsi_tape_read_blocksize() failing causing a zero
sd->sector_size being propigated up via dev_attrib.hw_block_size.

It also fixes another long-standing bug where TYPE_TAPE and
TYPE_MEDIMUM_CHANGER where using pscsi_create_type_other(),
which does not call scsi_device_get() to take the device
reference.  Instead, rename pscsi_create_type_rom() to
pscsi_create_type_nondisk() and use it for all cases.

Finally, also drop a dump_stack() in pscsi_get_blocks() for
non TYPE_DISK, which in modern target-core can get invoked
via target_sense_desc_format() during CHECK_CONDITION.

Reported-by: Malcolm Haak <insanemal@gmail.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/target/target_core_pscsi.c |   47 +++++++++----------------------------
 1 file changed, 12 insertions(+), 35 deletions(-)

--- a/drivers/target/target_core_pscsi.c
+++ b/drivers/target/target_core_pscsi.c
@@ -154,7 +154,7 @@ static void pscsi_tape_read_blocksize(st
 
 	buf = kzalloc(12, GFP_KERNEL);
 	if (!buf)
-		return;
+		goto out_free;
 
 	memset(cdb, 0, MAX_COMMAND_SIZE);
 	cdb[0] = MODE_SENSE;
@@ -169,9 +169,10 @@ static void pscsi_tape_read_blocksize(st
 	 * If MODE_SENSE still returns zero, set the default value to 1024.
 	 */
 	sdev->sector_size = (buf[9] << 16) | (buf[10] << 8) | (buf[11]);
+out_free:
 	if (!sdev->sector_size)
 		sdev->sector_size = 1024;
-out_free:
+
 	kfree(buf);
 }
 
@@ -314,9 +315,10 @@ static int pscsi_add_device_to_list(stru
 				sd->lun, sd->queue_depth);
 	}
 
-	dev->dev_attrib.hw_block_size = sd->sector_size;
+	dev->dev_attrib.hw_block_size =
+		min_not_zero((int)sd->sector_size, 512);
 	dev->dev_attrib.hw_max_sectors =
-		min_t(int, sd->host->max_sectors, queue_max_hw_sectors(q));
+		min_not_zero(sd->host->max_sectors, queue_max_hw_sectors(q));
 	dev->dev_attrib.hw_queue_depth = sd->queue_depth;
 
 	/*
@@ -339,8 +341,10 @@ static int pscsi_add_device_to_list(stru
 	/*
 	 * For TYPE_TAPE, attempt to determine blocksize with MODE_SENSE.
 	 */
-	if (sd->type == TYPE_TAPE)
+	if (sd->type == TYPE_TAPE) {
 		pscsi_tape_read_blocksize(dev, sd);
+		dev->dev_attrib.hw_block_size = sd->sector_size;
+	}
 	return 0;
 }
 
@@ -406,7 +410,7 @@ static int pscsi_create_type_disk(struct
 /*
  * Called with struct Scsi_Host->host_lock called.
  */
-static int pscsi_create_type_rom(struct se_device *dev, struct scsi_device *sd)
+static int pscsi_create_type_nondisk(struct se_device *dev, struct scsi_device *sd)
 	__releases(sh->host_lock)
 {
 	struct pscsi_hba_virt *phv = dev->se_hba->hba_ptr;
@@ -433,28 +437,6 @@ static int pscsi_create_type_rom(struct
 	return 0;
 }
 
-/*
- * Called with struct Scsi_Host->host_lock called.
- */
-static int pscsi_create_type_other(struct se_device *dev,
-		struct scsi_device *sd)
-	__releases(sh->host_lock)
-{
-	struct pscsi_hba_virt *phv = dev->se_hba->hba_ptr;
-	struct Scsi_Host *sh = sd->host;
-	int ret;
-
-	spin_unlock_irq(sh->host_lock);
-	ret = pscsi_add_device_to_list(dev, sd);
-	if (ret)
-		return ret;
-
-	pr_debug("CORE_PSCSI[%d] - Added Type: %s for %d:%d:%d:%llu\n",
-		phv->phv_host_id, scsi_device_type(sd->type), sh->host_no,
-		sd->channel, sd->id, sd->lun);
-	return 0;
-}
-
 static int pscsi_configure_device(struct se_device *dev)
 {
 	struct se_hba *hba = dev->se_hba;
@@ -542,11 +524,8 @@ static int pscsi_configure_device(struct
 		case TYPE_DISK:
 			ret = pscsi_create_type_disk(dev, sd);
 			break;
-		case TYPE_ROM:
-			ret = pscsi_create_type_rom(dev, sd);
-			break;
 		default:
-			ret = pscsi_create_type_other(dev, sd);
+			ret = pscsi_create_type_nondisk(dev, sd);
 			break;
 		}
 
@@ -611,8 +590,7 @@ static void pscsi_free_device(struct se_
 		else if (pdv->pdv_lld_host)
 			scsi_host_put(pdv->pdv_lld_host);
 
-		if ((sd->type == TYPE_DISK) || (sd->type == TYPE_ROM))
-			scsi_device_put(sd);
+		scsi_device_put(sd);
 
 		pdv->pdv_sd = NULL;
 	}
@@ -1088,7 +1066,6 @@ static sector_t pscsi_get_blocks(struct
 	if (pdv->pdv_bd && pdv->pdv_bd->bd_part)
 		return pdv->pdv_bd->bd_part->nr_sects;
 
-	dump_stack();
 	return 0;
 }
 

[toc] | [prev] | [next] | [standalone]

#1608793 — [PATCH 4.4 21/30] powerpc/boot: Fix zImage TOC alignment

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

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

From: Michael Ellerman <mpe@ellerman.id.au>

commit 97ee351b50a49717543533cfb85b4bf9d88c9680 upstream.

Recent toolchains force the TOC to be 256 byte aligned. We need to
enforce this alignment in the zImage linker script, otherwise pointers
to our TOC variables (__toc_start) could be incorrect. If the actual
start of the TOC and __toc_start don't have the same value we crash
early in the zImage wrapper.

Suggested-by: Alan Modra <amodra@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/boot/zImage.lds.S |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -68,6 +68,7 @@ SECTIONS
   }
 
 #ifdef CONFIG_PPC64_BOOT_WRAPPER
+  . = ALIGN(256);
   .got :
   {
     __toc_start = .;

[toc] | [prev] | [next] | [standalone]

#1608794 — [PATCH 4.4 12/30] KVM: PPC: Book3S PR: Fix illegal opcode emulation

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

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

From: Thomas Huth <thuth@redhat.com>

commit 708e75a3ee750dce1072134e630d66c4e6eaf63c upstream.

If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate
one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls
kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction()
returned EMULATE_FAIL, so the guest gets an program interrupt for the
illegal opcode.
However, the kvmppc_emulate_instruction() also tried to inject a
program exception for this already, so the program interrupt gets
injected twice and the return address in srr0 gets destroyed.
All other callers of kvmppc_emulate_instruction() are also injecting
a program interrupt, and since the callers have the right knowledge
about the srr1 flags that should be used, it is the function
kvmppc_emulate_instruction() that should _not_ inject program
interrupts, so remove the kvmppc_core_queue_program() here.

This fixes the issue discovered by Laurent Vivier with kvm-unit-tests
where the logs are filled with these messages when the test tries
to execute an illegal instruction:

     Couldn't emulate instruction 0x00000000 (op 0 xop 0)
     kvmppc_handle_exit_pr: emulation at 700 failed (00000000)

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
Tested-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/kvm/emulate.c |    1 -
 1 file changed, 1 deletion(-)

--- a/arch/powerpc/kvm/emulate.c
+++ b/arch/powerpc/kvm/emulate.c
@@ -302,7 +302,6 @@ int kvmppc_emulate_instruction(struct kv
 			advance = 0;
 			printk(KERN_ERR "Couldn't emulate instruction 0x%08x "
 			       "(op %d xop %d)\n", inst, get_op(inst), get_xop(inst));
-			kvmppc_core_queue_program(vcpu, 0);
 		}
 	}
 

[toc] | [prev] | [next] | [standalone]

#1608795 — [PATCH 4.4 17/30] kernek/fork.c: allocate idle task for a CPU always on its local node

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

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

From: Andi Kleen <ak@linux.intel.com>

commit 725fc629ff2545b061407305ae51016c9f928fce upstream.

Linux preallocates the task structs of the idle tasks for all possible
CPUs.  This currently means they all end up on node 0.  This also
implies that the cache line of MWAIT, which is around the flags field in
the task struct, are all located in node 0.

We see a noticeable performance improvement on Knights Landing CPUs when
the cache lines used for MWAIT are located in the local nodes of the
CPUs using them.  I would expect this to give a (likely slight)
improvement on other systems too.

The patch implements placing the idle task in the node of its CPUs, by
passing the right target node to copy_process()

[akpm@linux-foundation.org: use NUMA_NO_NODE, not a bare -1]
Link: http://lkml.kernel.org/r/1463492694-15833-1-git-send-email-andi@firstfloor.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/fork.c |   15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -331,13 +331,14 @@ void set_task_stack_end_magic(struct tas
 	*stackend = STACK_END_MAGIC;	/* for overflow detection */
 }
 
-static struct task_struct *dup_task_struct(struct task_struct *orig)
+static struct task_struct *dup_task_struct(struct task_struct *orig, int node)
 {
 	struct task_struct *tsk;
 	struct thread_info *ti;
-	int node = tsk_fork_get_node(orig);
 	int err;
 
+	if (node == NUMA_NO_NODE)
+		node = tsk_fork_get_node(orig);
 	tsk = alloc_task_struct_node(node);
 	if (!tsk)
 		return NULL;
@@ -1270,7 +1271,8 @@ static struct task_struct *copy_process(
 					int __user *child_tidptr,
 					struct pid *pid,
 					int trace,
-					unsigned long tls)
+					unsigned long tls,
+					int node)
 {
 	int retval;
 	struct task_struct *p;
@@ -1323,7 +1325,7 @@ static struct task_struct *copy_process(
 		goto fork_out;
 
 	retval = -ENOMEM;
-	p = dup_task_struct(current);
+	p = dup_task_struct(current, node);
 	if (!p)
 		goto fork_out;
 
@@ -1699,7 +1701,8 @@ static inline void init_idle_pids(struct
 struct task_struct *fork_idle(int cpu)
 {
 	struct task_struct *task;
-	task = copy_process(CLONE_VM, 0, 0, NULL, &init_struct_pid, 0, 0);
+	task = copy_process(CLONE_VM, 0, 0, NULL, &init_struct_pid, 0, 0,
+			    cpu_to_node(cpu));
 	if (!IS_ERR(task)) {
 		init_idle_pids(task->pids);
 		init_idle(task, cpu);
@@ -1744,7 +1747,7 @@ long _do_fork(unsigned long clone_flags,
 	}
 
 	p = copy_process(clone_flags, stack_start, stack_size,
-			 child_tidptr, NULL, trace, tls);
+			 child_tidptr, NULL, trace, tls, NUMA_NO_NODE);
 	/*
 	 * Do this prior waking up the new thread - the thread pointer
 	 * might get invalid after that point, if the thread exits quickly.

[toc] | [prev] | [next] | [standalone]

#1608796 — [PATCH 4.4 19/30] perf/core: Fix event inheritance on fork()

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

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

From: Peter Zijlstra <peterz@infradead.org>

commit e7cc4865f0f31698ef2f7aac01a50e78968985b7 upstream.

While hunting for clues to a use-after-free, Oleg spotted that
perf_event_init_context() can loose an error value with the result
that fork() can succeed even though we did not fully inherit the perf
event context.

Spotted-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: oleg@redhat.com
Fixes: 889ff0150661 ("perf/core: Split context's event group list into pinned and non-pinned lists")
Link: http://lkml.kernel.org/r/20170316125823.190342547@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 kernel/events/core.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -9230,7 +9230,7 @@ static int perf_event_init_context(struc
 		ret = inherit_task_group(event, parent, parent_ctx,
 					 child, ctxn, &inherited_all);
 		if (ret)
-			break;
+			goto out_unlock;
 	}
 
 	/*
@@ -9246,7 +9246,7 @@ static int perf_event_init_context(struc
 		ret = inherit_task_group(event, parent, parent_ctx,
 					 child, ctxn, &inherited_all);
 		if (ret)
-			break;
+			goto out_unlock;
 	}
 
 	raw_spin_lock_irqsave(&parent_ctx->lock, flags);
@@ -9274,6 +9274,7 @@ static int perf_event_init_context(struc
 	}
 
 	raw_spin_unlock_irqrestore(&parent_ctx->lock, flags);
+out_unlock:
 	mutex_unlock(&parent_ctx->mutex);
 
 	perf_unpin_context(parent_ctx);

[toc] | [prev] | [next] | [standalone]

#1608799 — [PATCH 4.4 01/30] usb: core: hub: hub_port_init lock controller instead of bus

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

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

From: Chris Bainbridge <chris.bainbridge@gmail.com>

commit feb26ac31a2a5cb88d86680d9a94916a6343e9e6 upstream.

The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:

[    8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[   13.183701] usb 3-3: device descriptor read/all, error -110

On a test system this failure occurred on 6% of all boots.

The call traces at the point of failure are:

Call Trace:
 [<ffffffff81b9bab7>] schedule+0x37/0x90
 [<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
 [<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
 [<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
 [<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
 [<ffffffff817d07de>] hub_port_init+0x51e/0xb70
 [<ffffffff817d4697>] hub_event+0x817/0x1570
 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
 [<ffffffff810f4684>] worker_thread+0x64/0x4b0
 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
 [<ffffffff810fa7f5>] kthread+0x105/0x120
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200

Call Trace:
 [<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
 [<ffffffff817fd87e>] xhci_address_device+0xe/0x10
 [<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
 [<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
 [<ffffffff817d4697>] hub_event+0x817/0x1570
 [<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
 [<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
 [<ffffffff810f4684>] worker_thread+0x64/0x4b0
 [<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
 [<ffffffff810fa7f5>] kthread+0x105/0x120
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
 [<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
 [<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200

Which results from the two call chains:

hub_port_init
 usb_get_device_descriptor
  usb_get_descriptor
   usb_control_msg
    usb_internal_control_msg
     usb_start_wait_urb
      usb_submit_urb / wait_for_completion_timeout / usb_kill_urb

hub_port_init
 hub_set_address
  xhci_address_device
   xhci_setup_device

Mathias Nyman explains the current behaviour violates the XHCI spec:

 hub_port_reset() will end up moving the corresponding xhci device slot
 to default state.

 As hub_port_reset() is called several times in hub_port_init() it
 sounds reasonable that we could end up with two threads having their
 xhci device slots in default state at the same time, which according to
 xhci 4.5.3 specs still is a big no no:

 "Note: Software shall not transition more than one Device Slot to the
  Default State at a time"

 So both threads fail at their next task after this.
 One fails to read the descriptor, and the other fails addressing the
 device.

Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.

Fixes: 638139eb95d2 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
 [sumits: minor merge conflict resolution for linux-4.4.y]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/usb/core/hcd.c  |   15 +++++++++++++--
 drivers/usb/core/hub.c  |    8 ++++----
 include/linux/usb.h     |    3 +--
 include/linux/usb/hcd.h |    1 +
 4 files changed, 19 insertions(+), 8 deletions(-)

--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -966,7 +966,7 @@ static void usb_bus_init (struct usb_bus
 	bus->bandwidth_allocated = 0;
 	bus->bandwidth_int_reqs  = 0;
 	bus->bandwidth_isoc_reqs = 0;
-	mutex_init(&bus->usb_address0_mutex);
+	mutex_init(&bus->devnum_next_mutex);
 
 	INIT_LIST_HEAD (&bus->bus_list);
 }
@@ -2497,6 +2497,14 @@ struct usb_hcd *usb_create_shared_hcd(co
 		return NULL;
 	}
 	if (primary_hcd == NULL) {
+		hcd->address0_mutex = kmalloc(sizeof(*hcd->address0_mutex),
+				GFP_KERNEL);
+		if (!hcd->address0_mutex) {
+			kfree(hcd);
+			dev_dbg(dev, "hcd address0 mutex alloc failed\n");
+			return NULL;
+		}
+		mutex_init(hcd->address0_mutex);
 		hcd->bandwidth_mutex = kmalloc(sizeof(*hcd->bandwidth_mutex),
 				GFP_KERNEL);
 		if (!hcd->bandwidth_mutex) {
@@ -2508,6 +2516,7 @@ struct usb_hcd *usb_create_shared_hcd(co
 		dev_set_drvdata(dev, hcd);
 	} else {
 		mutex_lock(&usb_port_peer_mutex);
+		hcd->address0_mutex = primary_hcd->address0_mutex;
 		hcd->bandwidth_mutex = primary_hcd->bandwidth_mutex;
 		hcd->primary_hcd = primary_hcd;
 		primary_hcd->primary_hcd = primary_hcd;
@@ -2574,8 +2583,10 @@ static void hcd_release(struct kref *kre
 	struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
 
 	mutex_lock(&usb_port_peer_mutex);
-	if (usb_hcd_is_primary_hcd(hcd))
+	if (usb_hcd_is_primary_hcd(hcd)) {
+		kfree(hcd->address0_mutex);
 		kfree(hcd->bandwidth_mutex);
+	}
 	if (hcd->shared_hcd) {
 		struct usb_hcd *peer = hcd->shared_hcd;
 
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1980,7 +1980,7 @@ static void choose_devnum(struct usb_dev
 	struct usb_bus	*bus = udev->bus;
 
 	/* be safe when more hub events are proceed in parallel */
-	mutex_lock(&bus->usb_address0_mutex);
+	mutex_lock(&bus->devnum_next_mutex);
 	if (udev->wusb) {
 		devnum = udev->portnum + 1;
 		BUG_ON(test_bit(devnum, bus->devmap.devicemap));
@@ -1998,7 +1998,7 @@ static void choose_devnum(struct usb_dev
 		set_bit(devnum, bus->devmap.devicemap);
 		udev->devnum = devnum;
 	}
-	mutex_unlock(&bus->usb_address0_mutex);
+	mutex_unlock(&bus->devnum_next_mutex);
 }
 
 static void release_devnum(struct usb_device *udev)
@@ -4262,7 +4262,7 @@ hub_port_init(struct usb_hub *hub, struc
 	if (oldspeed == USB_SPEED_LOW)
 		delay = HUB_LONG_RESET_TIME;
 
-	mutex_lock(&hdev->bus->usb_address0_mutex);
+	mutex_lock(hcd->address0_mutex);
 
 	/* Reset the device; full speed may morph to high speed */
 	/* FIXME a USB 2.0 device may morph into SuperSpeed on reset. */
@@ -4548,7 +4548,7 @@ fail:
 		hub_port_disable(hub, port1, 0);
 		update_devnum(udev, devnum);	/* for disconnect processing */
 	}
-	mutex_unlock(&hdev->bus->usb_address0_mutex);
+	mutex_unlock(hcd->address0_mutex);
 	return retval;
 }
 
--- a/include/linux/usb.h
+++ b/include/linux/usb.h
@@ -371,14 +371,13 @@ struct usb_bus {
 
 	int devnum_next;		/* Next open device number in
 					 * round-robin allocation */
+	struct mutex devnum_next_mutex; /* devnum_next mutex */
 
 	struct usb_devmap devmap;	/* device address allocation map */
 	struct usb_device *root_hub;	/* Root hub */
 	struct usb_bus *hs_companion;	/* Companion EHCI bus, if any */
 	struct list_head bus_list;	/* list of busses */
 
-	struct mutex usb_address0_mutex; /* unaddressed device mutex */
-
 	int bandwidth_allocated;	/* on this bus: how much of the time
 					 * reserved for periodic (intr/iso)
 					 * requests is used, on average?
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -180,6 +180,7 @@ struct usb_hcd {
 	 * bandwidth_mutex should be dropped after a successful control message
 	 * to the device, or resetting the bandwidth after a failed attempt.
 	 */
+	struct mutex		*address0_mutex;
 	struct mutex		*bandwidth_mutex;
 	struct usb_hcd		*shared_hcd;
 	struct usb_hcd		*primary_hcd;

[toc] | [prev] | [next] | [standalone]

#1608801 — [PATCH 4.4 22/30] md/raid1/10: fix potential deadlock

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

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

From: Shaohua Li <shli@fb.com>

commit 61eb2b43b99ebdc9bc6bc83d9792257b243e7cb3 upstream.

Neil Brown pointed out a potential deadlock in raid 10 code with
bio_split/chain. The raid1 code could have the same issue, but recent
barrier rework makes it less likely to happen. The deadlock happens in
below sequence:

1. generic_make_request(bio), this will set current->bio_list
2. raid10_make_request will split bio to bio1 and bio2
3. __make_request(bio1), wait_barrer, add underlayer disk bio to
current->bio_list
4. __make_request(bio2), wait_barrer

If raise_barrier happens between 3 & 4, since wait_barrier runs at 3,
raise_barrier waits for IO completion from 3. And since raise_barrier
sets barrier, 4 waits for raise_barrier. But IO from 3 can't be
dispatched because raid10_make_request() doesn't finished yet.

The solution is to adjust the IO ordering. Quotes from Neil:
"
It is much safer to:

    if (need to split) {
        split = bio_split(bio, ...)
        bio_chain(...)
        make_request_fn(split);
        generic_make_request(bio);
   } else
        make_request_fn(mddev, bio);

This way we first process the initial section of the bio (in 'split')
which will queue some requests to the underlying devices.  These
requests will be queued in generic_make_request.
Then we queue the remainder of the bio, which will be added to the end
of the generic_make_request queue.
Then we return.
generic_make_request() will pop the lower-level device requests off the
queue and handle them first.  Then it will process the remainder
of the original bio once the first section has been fully processed.
"

Note, this only happens in read path. In write path, the bio is flushed to
underlaying disks either by blk flush (from schedule) or offladed to raid1/10d.
It's queued in current->bio_list.

Cc: Coly Li <colyli@suse.de>
Suggested-by: NeilBrown <neilb@suse.com>
Reviewed-by: Jack Wang <jinpu.wang@profitbricks.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/md/raid10.c |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1477,7 +1477,25 @@ static void make_request(struct mddev *m
 			split = bio;
 		}
 
+		/*
+		 * If a bio is splitted, the first part of bio will pass
+		 * barrier but the bio is queued in current->bio_list (see
+		 * generic_make_request). If there is a raise_barrier() called
+		 * here, the second part of bio can't pass barrier. But since
+		 * the first part bio isn't dispatched to underlaying disks
+		 * yet, the barrier is never released, hence raise_barrier will
+		 * alays wait. We have a deadlock.
+		 * Note, this only happens in read path. For write path, the
+		 * first part of bio is dispatched in a schedule() call
+		 * (because of blk plug) or offloaded to raid10d.
+		 * Quitting from the function immediately can change the bio
+		 * order queued in bio_list and avoid the deadlock.
+		 */
 		__make_request(mddev, split);
+		if (split != bio && bio_data_dir(bio) == READ) {
+			generic_make_request(bio);
+			break;
+		}
 	} while (split != bio);
 
 	/* In case raid10d snuck in to freeze_array */

[toc] | [prev] | [next] | [standalone]

#1608810 — [PATCH 4.4 02/30] USB: dont free bandwidth_mutex too early

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

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

From: Alan Stern <stern@rowland.harvard.edu>

commit ab2a4bf83902c170d29ba130a8abb5f9d90559e1 upstream.

The USB core contains a bug that can show up when a USB-3 host
controller is removed.  If the primary (USB-2) hcd structure is
released before the shared (USB-3) hcd, the core will try to do a
double-free of the common bandwidth_mutex.

The problem was described in graphical form by Chung-Geol Kim, who
first reported it:

=================================================
     At *remove USB(3.0) Storage
     sequence <1> --> <5> ((Problem Case))
=================================================
                                  VOLD
------------------------------------|------------
                                 (uevent)
                            ________|_________
                           |<1>               |
                           |dwc3_otg_sm_work  |
                           |usb_put_hcd       |
                           |peer_hcd(kref=2)|
                           |__________________|
                            ________|_________
                           |<2>               |
                           |New USB BUS #2    |
                           |                  |
                           |peer_hcd(kref=1)  |
                           |                  |
                         --(Link)-bandXX_mutex|
                         | |__________________|
                         |
    ___________________  |
   |<3>                | |
   |dwc3_otg_sm_work   | |
   |usb_put_hcd        | |
   |primary_hcd(kref=1)| |
   |___________________| |
    _________|_________  |
   |<4>                | |
   |New USB BUS #1     | |
   |hcd_release        | |
   |primary_hcd(kref=0)| |
   |                   | |
   |bandXX_mutex(free) |<-
   |___________________|
                               (( VOLD ))
                            ______|___________
                           |<5>               |
                           |      SCSI        |
                           |usb_put_hcd       |
                           |peer_hcd(kref=0)  |
                           |*hcd_release      |
                           |bandXX_mutex(free*)|<- double free
                           |__________________|

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

This happens because hcd_release() frees the bandwidth_mutex whenever
it sees a primary hcd being released (which is not a very good idea
in any case), but in the course of releasing the primary hcd, it
changes the pointers in the shared hcd in such a way that the shared
hcd will appear to be primary when it gets released.

This patch fixes the problem by changing hcd_release() so that it
deallocates the bandwidth_mutex only when the _last_ hcd structure
referencing it is released.  The patch also removes an unnecessary
test, so that when an hcd is released, both the shared_hcd and
primary_hcd pointers in the hcd's peer will be cleared.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Chung-Geol Kim <chunggeol.kim@samsung.com>
Tested-by: Chung-Geol Kim <chunggeol.kim@samsung.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


---
 drivers/usb/core/hcd.c |   17 +++++++----------
 1 file changed, 7 insertions(+), 10 deletions(-)

--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2573,26 +2573,23 @@ EXPORT_SYMBOL_GPL(usb_create_hcd);
  * Don't deallocate the bandwidth_mutex until the last shared usb_hcd is
  * deallocated.
  *
- * Make sure to only deallocate the bandwidth_mutex when the primary HCD is
- * freed.  When hcd_release() is called for either hcd in a peer set
- * invalidate the peer's ->shared_hcd and ->primary_hcd pointers to
- * block new peering attempts
+ * Make sure to deallocate the bandwidth_mutex only when the last HCD is
+ * freed.  When hcd_release() is called for either hcd in a peer set,
+ * invalidate the peer's ->shared_hcd and ->primary_hcd pointers.
  */
 static void hcd_release(struct kref *kref)
 {
 	struct usb_hcd *hcd = container_of (kref, struct usb_hcd, kref);
 
 	mutex_lock(&usb_port_peer_mutex);
-	if (usb_hcd_is_primary_hcd(hcd)) {
-		kfree(hcd->address0_mutex);
-		kfree(hcd->bandwidth_mutex);
-	}
 	if (hcd->shared_hcd) {
 		struct usb_hcd *peer = hcd->shared_hcd;
 
 		peer->shared_hcd = NULL;
-		if (peer->primary_hcd == hcd)
-			peer->primary_hcd = NULL;
+		peer->primary_hcd = NULL;
+	} else {
+		kfree(hcd->address0_mutex);
+		kfree(hcd->bandwidth_mutex);
 	}
 	mutex_unlock(&usb_port_peer_mutex);
 	kfree(hcd);

[toc] | [prev] | [next] | [standalone]

#1608811 — [PATCH 4.4 13/30] s390/pci: fix use after free in dma_init

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

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

From: Sebastian Ott <sebott@linux.vnet.ibm.com>

commit dba599091c191d209b1499511a524ad9657c0e5a upstream.

After a failure during registration of the dma_table (because of the
function being in error state) we free its memory but don't reset the
associated pointer to zero.

When we then receive a notification from firmware (about the function
being in error state) we'll try to walk and free the dma_table again.

Fix this by resetting the dma_table pointer. In addition to that make
sure that we free the iommu_bitmap when appropriate.

Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/s390/pci/pci_dma.c |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

--- a/arch/s390/pci/pci_dma.c
+++ b/arch/s390/pci/pci_dma.c
@@ -455,7 +455,7 @@ int zpci_dma_init_device(struct zpci_dev
 	zdev->dma_table = dma_alloc_cpu_table();
 	if (!zdev->dma_table) {
 		rc = -ENOMEM;
-		goto out_clean;
+		goto out;
 	}
 
 	/*
@@ -475,18 +475,22 @@ int zpci_dma_init_device(struct zpci_dev
 	zdev->iommu_bitmap = vzalloc(zdev->iommu_pages / 8);
 	if (!zdev->iommu_bitmap) {
 		rc = -ENOMEM;
-		goto out_reg;
+		goto free_dma_table;
 	}
 
 	rc = zpci_register_ioat(zdev, 0, zdev->start_dma, zdev->end_dma,
 				(u64) zdev->dma_table);
 	if (rc)
-		goto out_reg;
-	return 0;
+		goto free_bitmap;
 
-out_reg:
+	return 0;
+free_bitmap:
+	vfree(zdev->iommu_bitmap);
+	zdev->iommu_bitmap = NULL;
+free_dma_table:
 	dma_free_cpu_table(zdev->dma_table);
-out_clean:
+	zdev->dma_table = NULL;
+out:
 	return rc;
 }
 

[toc] | [prev] | [next] | [standalone]

#1608813 — [PATCH 4.4 15/30] tpm_tis: Use devm_free_irq not free_irq

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

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

From: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>

commit 727f28b8ca24a581c7bd868326b8cea1058c720a upstream.

The interrupt is always allocated with devm_request_irq so it
must always be freed with devm_free_irq.

Fixes: 448e9c55c12d ("tpm_tis: verify interrupt during init")
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Tested-by: Martin Wilck <Martin.Wilck@ts.fujitsu.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Acked-by: Peter Huewe <peterhuewe@gmx.de>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/char/tpm/tpm_tis.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -401,7 +401,7 @@ static void disable_interrupts(struct tp
 	iowrite32(intmask,
 		  chip->vendor.iobase +
 		  TPM_INT_ENABLE(chip->vendor.locality));
-	free_irq(chip->vendor.irq, chip);
+	devm_free_irq(chip->pdev, chip->vendor.irq, chip);
 	chip->vendor.irq = 0;
 }
 

[toc] | [prev] | [next] | [standalone]

#1608814 — [PATCH 4.4 24/30] scsi: lpfc: Add shutdown method for kexec

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

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

From: Anton Blanchard <anton@samba.org>

commit 85e8a23936ab3442de0c42da97d53b29f004ece1 upstream.

We see lpfc devices regularly fail during kexec. Fix this by adding a
shutdown method which mirrors the remove method.

Signed-off-by: Anton Blanchard <anton@samba.org>
Reviewed-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Tested-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/scsi/lpfc/lpfc_init.c |    1 +
 1 file changed, 1 insertion(+)

--- a/drivers/scsi/lpfc/lpfc_init.c
+++ b/drivers/scsi/lpfc/lpfc_init.c
@@ -11387,6 +11387,7 @@ static struct pci_driver lpfc_driver = {
 	.id_table	= lpfc_id_table,
 	.probe		= lpfc_pci_probe_one,
 	.remove		= lpfc_pci_remove_one,
+	.shutdown	= lpfc_pci_remove_one,
 	.suspend        = lpfc_pci_suspend_one,
 	.resume		= lpfc_pci_resume_one,
 	.err_handler    = &lpfc_err_handler,

[toc] | [prev] | [next] | [standalone]

#1608815 — [PATCH 4.4 20/30] cpufreq: Fix and clean up show_cpuinfo_cur_freq()

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

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

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

commit 9b4f603e7a9f4282aec451063ffbbb8bb410dcd9 upstream.

There is a missing newline in show_cpuinfo_cur_freq(), so add it,
but while at it clean that function up somewhat too.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/cpufreq/cpufreq.c |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -626,9 +626,11 @@ static ssize_t show_cpuinfo_cur_freq(str
 					char *buf)
 {
 	unsigned int cur_freq = __cpufreq_get(policy);
-	if (!cur_freq)
-		return sprintf(buf, "<unknown>");
-	return sprintf(buf, "%u\n", cur_freq);
+
+	if (cur_freq)
+		return sprintf(buf, "%u\n", cur_freq);
+
+	return sprintf(buf, "<unknown>\n");
 }
 
 /**

[toc] | [prev] | [next] | [standalone]

#1609035

On 03/24/2017 11:58 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.57 release.
> There are 30 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Mar 26 15:12:02 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
> 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.57-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

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

thanks,
-- Shuah

[toc] | [prev] | [next] | [standalone]

#1609085

On 03/24/2017 10:58 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.57 release.
> There are 30 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun Mar 26 15:12:02 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
	total: 149 pass: 149 fail: 0
Qemu test results:
	total: 115 pass: 115 fail: 0

Details are available at http://kerneltests.org/builders.

Guenter

[toc] | [prev] | [next] | [standalone]

#1609086

On 03/24/2017 05:10 PM, Kevin Hilman wrote:
> + at91 maintainers
>
> kernelci.org bot <bot@kernelci.org> writes:
>
>> stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
>> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
>>
>> Tree: stable-rc
>> Branch: local/linux-4.4.y
>> Git Describe: v4.4.56-31-gbcd1e808ead3
>> Git Commit: bcd1e808ead359a9af8476025d8b8a5349796dcd
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 97 unique boards, 23 SoC families, 31 builds out of 202
>>
>> Boot Regressions Detected:
>>
>> arm:
>>
>>     multi_v7_defconfig+CONFIG_LKDTM=y:
>>         at91-sama5d2_xplained:
>>             lab-free-electrons: new failure (last pass: v4.4.51-27-g2ffd736763bc)
>
> This one is definitely a new regression.  Hopefully the AT91 maintainers
> (now Cc'd) can have a closer look.
>

6b1d7b6f54c7 would be a candidate for a culprit.

Guenter

> [...]
>
>> Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
>>
>> arm:
>>
>>     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>>         at91-sama5d3_xplained:
>>             lab-baylibre-seattle: PASS
>>             lab-free-electrons: FAIL
>
> @Alexandre: Because it's passing in my lab and failing in yours, I'm
> guessing this is still the UART overflow issue we've discussed before?
>
> What's strange is that this defconfig in your lab seems to only be
> booting for stable/linux-4.4.y[1] but not mailine or newer stable trees,
> so I couldn't check if the problem still exists in mainline.
>
> Kevin
>
> [1] https://kernelci.org/boot/at91-sama5d3_xplained/?CONFIG_PROVE_LOCKING&lab-free-electrons
>

[toc] | [prev] | [next] | [standalone]

#1609137

On 24/03/2017 at 21:15:28 -0700, Guenter Roeck wrote:
> On 03/24/2017 05:10 PM, Kevin Hilman wrote:
> > + at91 maintainers
> > 

+ Richard, Ludovic

> > kernelci.org bot <bot@kernelci.org> writes:
> > 
> > > stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3)
> > > 
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
> > > 
> > > Tree: stable-rc
> > > Branch: local/linux-4.4.y
> > > Git Describe: v4.4.56-31-gbcd1e808ead3
> > > Git Commit: bcd1e808ead359a9af8476025d8b8a5349796dcd
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Tested: 97 unique boards, 23 SoC families, 31 builds out of 202
> > > 
> > > Boot Regressions Detected:
> > > 
> > > arm:
> > > 
> > >     multi_v7_defconfig+CONFIG_LKDTM=y:
> > >         at91-sama5d2_xplained:
> > >             lab-free-electrons: new failure (last pass: v4.4.51-27-g2ffd736763bc)
> > 
> > This one is definitely a new regression.  Hopefully the AT91 maintainers
> > (now Cc'd) can have a closer look.
> > 
> 
> 6b1d7b6f54c7 would be a candidate for a culprit.
> 

Possibly and it may exercise a part of the logic that is not quite
robust in atmel_set_ops(). Basically, atmel_rx_from_pdc() must not be
chosen on sama5d2 (it has no PDC).

For reference, bootlog here:
https://storage.kernelci.org/stable-rc/v4.4.56-31-gbcd1e808ead3/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-free-electrons/boot-at91-sama5d2_xplained.html

> > > Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
> > > 
> > > arm:
> > > 
> > >     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > >         at91-sama5d3_xplained:
> > >             lab-baylibre-seattle: PASS
> > >             lab-free-electrons: FAIL
> > 
> > @Alexandre: Because it's passing in my lab and failing in yours, I'm
> > guessing this is still the UART overflow issue we've discussed before?
> > 
> > What's strange is that this defconfig in your lab seems to only be
> > booting for stable/linux-4.4.y[1] but not mailine or newer stable trees,
> > so I couldn't check if the problem still exists in mainline.
> > 

It definitively exists but it is not solvable quickly. Either we run
without DMA and we'll see the issue because CONFIG_PROVE_LOCKING makes
the interrupt handling to slow and characters are dropped. Or, we add
DMA and then CONFIG_PROVE_LOCKING will find a deadlock (that's a real
deadlock, not a false positive) and the platform will not boot.

This only affects sama5d3 because it is the only SoC using the hdma
controller with the uart IP. Earlier SoCs have a PDC and later SoCs are
using the xdma controller.

This happens because atc_chain_complete() keeps the lock before calling
the callback.  And atmel_complete_tx_dma() will call dmaengine function
that will try to acquire the lock. No issue using the xdmac because
there is no lock.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [next] | [standalone]

#1609138

On 25/03/2017 at 12:27:05 +0100, Alexandre Belloni wrote:
> On 24/03/2017 at 21:15:28 -0700, Guenter Roeck wrote:
> > On 03/24/2017 05:10 PM, Kevin Hilman wrote:
> > > + at91 maintainers
> > > 
> 
> + Richard, Ludovic
> 
> > > kernelci.org bot <bot@kernelci.org> writes:
> > > 
> > > > stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3)
> > > > 
> > > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
> > > > Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
> > > > 
> > > > Tree: stable-rc
> > > > Branch: local/linux-4.4.y
> > > > Git Describe: v4.4.56-31-gbcd1e808ead3
> > > > Git Commit: bcd1e808ead359a9af8476025d8b8a5349796dcd
> > > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > Tested: 97 unique boards, 23 SoC families, 31 builds out of 202
> > > > 
> > > > Boot Regressions Detected:
> > > > 
> > > > arm:
> > > > 
> > > >     multi_v7_defconfig+CONFIG_LKDTM=y:
> > > >         at91-sama5d2_xplained:
> > > >             lab-free-electrons: new failure (last pass: v4.4.51-27-g2ffd736763bc)
> > > 
> > > This one is definitely a new regression.  Hopefully the AT91 maintainers
> > > (now Cc'd) can have a closer look.
> > > 
> > 
> > 6b1d7b6f54c7 would be a candidate for a culprit.
> > 
> 
> Possibly and it may exercise a part of the logic that is not quite
> robust in atmel_set_ops(). Basically, atmel_rx_from_pdc() must not be
> chosen on sama5d2 (it has no PDC).
> 

I confirm the issue, commit 6b1d7b6f54c7 enables dma but
uart1 node doesn't have a "dmas" property so the driver thinks it has to
use PDC which is not correct. I'll try backporting
b1708b72a0959a032cd2eebb77fa9086ea3e0c84 which seems the proper way
forward.

> For reference, bootlog here:
> https://storage.kernelci.org/stable-rc/v4.4.56-31-gbcd1e808ead3/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-free-electrons/boot-at91-sama5d2_xplained.html
> 
> > > > Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
> > > > 
> > > > arm:
> > > > 
> > > >     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > > >         at91-sama5d3_xplained:
> > > >             lab-baylibre-seattle: PASS
> > > >             lab-free-electrons: FAIL
> > > 
> > > @Alexandre: Because it's passing in my lab and failing in yours, I'm
> > > guessing this is still the UART overflow issue we've discussed before?
> > > 
> > > What's strange is that this defconfig in your lab seems to only be
> > > booting for stable/linux-4.4.y[1] but not mailine or newer stable trees,
> > > so I couldn't check if the problem still exists in mainline.
> > > 
> 
> It definitively exists but it is not solvable quickly. Either we run
> without DMA and we'll see the issue because CONFIG_PROVE_LOCKING makes
> the interrupt handling to slow and characters are dropped. Or, we add
> DMA and then CONFIG_PROVE_LOCKING will find a deadlock (that's a real
> deadlock, not a false positive) and the platform will not boot.
> 
> This only affects sama5d3 because it is the only SoC using the hdma
> controller with the uart IP. Earlier SoCs have a PDC and later SoCs are
> using the xdma controller.
> 
> This happens because atc_chain_complete() keeps the lock before calling
> the callback.  And atmel_complete_tx_dma() will call dmaengine function
> that will try to acquire the lock. No issue using the xdmac because
> there is no lock.
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web