4.4.134-stable review

Cc <[email protected]> # 3.13+

Patchwork: https://patchwork.linux-mips.org/patch/19273/

Signed-off-by James Hogan <[email protected]>

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

---
 arch/mips/kernel/ptrace.c |   18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

arch/mips/kernel/ptrace.c +16 -2

@@ -483,7 +483,7 @@ static int fpr_get_msa(struct task_struc
 /*
  * Copy the floating-point context to the supplied NT_PRFPREG buffer.
  * Choose the appropriate helper for general registers, and then copy
- * the FCSR register separately.
+ * the FCSR and FIR registers separately.
  */
 static int fpr_get(struct task_struct *target,
 		   const struct user_regset *regset,

@@ -491,6 +491,7 @@ static int fpr_get(struct task_struct *t
 		   void *kbuf, void __user *ubuf)
 {
 	const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+	const int fir_pos = fcr31_pos + sizeof(u32);
 	int err;
 
 	if (sizeof(target->thread.fpu.fpr[0]) == sizeof(elf_fpreg_t))

@@ -503,6 +504,12 @@ static int fpr_get(struct task_struct *t
 	err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
 				  &target->thread.fpu.fcr31,
 				  fcr31_pos, fcr31_pos + sizeof(u32));
+	if (err)
+		return err;
+
+	err = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
+				  &boot_cpu_data.fpu_id,
+				  fir_pos, fir_pos + sizeof(u32));
 
 	return err;
 }

@@ -551,7 +558,8 @@ static int fpr_set_msa(struct task_struc
 /*
  * Copy the supplied NT_PRFPREG buffer to the floating-point context.
  * Choose the appropriate helper for general registers, and then copy
- * the FCSR register separately.
+ * the FCSR register separately.  Ignore the incoming FIR register
+ * contents though, as the register is read-only.
  *
  * We optimize for the case where `count % sizeof(elf_fpreg_t) == 0',
  * which is supposed to have been guaranteed by the kernel before

@@ -565,6 +573,7 @@ static int fpr_set(struct task_struct *t
 		   const void *kbuf, const void __user *ubuf)
 {
 	const int fcr31_pos = NUM_FPU_REGS * sizeof(elf_fpreg_t);
+	const int fir_pos = fcr31_pos + sizeof(u32);
 	u32 fcr31;
 	int err;

@@ -592,6 +601,11 @@ static int fpr_set(struct task_struct *t
 		ptrace_setfcr31(target, fcr31);
 	}
 
+	if (count > 0)
+		err = user_regset_copyin_ignore(&pos, &count, &kbuf, &ubuf,
+						fir_pos,
+						fir_pos + sizeof(u32));
+
 	return err;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #2 lore raw

PATCH 2/268 MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs

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

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

From: Maciej W. Rozycki <[email protected]>

commit 9a3a92ccfe3620743d4ae57c987dc8e9c5f88996 upstream.

Check the TIF_32BIT_FPREGS task setting of the tracee rather than the tracer in determining the layout of floating-point general registers in the floating-point context, correcting access to odd-numbered registers for o32 tracees where the setting disagrees between the two processes.

Fixes 597ce1723e0f ("MIPS: Support for 64-bit FP with O32 binaries")

Signed-off-by Maciej W. Rozycki <[email protected]>

Cc Ralf Baechle <[email protected]>

Cc <[email protected]> # 3.14+

Signed-off-by James Hogan <[email protected]>

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

---
 arch/mips/kernel/ptrace.c   |    4 ++--
 arch/mips/kernel/ptrace32.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

arch/mips/kernel/ptrace.c +2 -2

@@ -830,7 +830,7 @@ long arch_ptrace(struct task_struct *chi
 			fregs = get_fpu_regs(child);
 
 #ifdef CONFIG_32BIT
-			if (test_thread_flag(TIF_32BIT_FPREGS)) {
+			if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
 				/*
 				 * The odd registers are actually the high
 				 * order bits of the values stored in the even

@@ -919,7 +919,7 @@ long arch_ptrace(struct task_struct *chi
 
 			init_fp_ctx(child);
 #ifdef CONFIG_32BIT
-			if (test_thread_flag(TIF_32BIT_FPREGS)) {
+			if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
 				/*
 				 * The odd registers are actually the high
 				 * order bits of the values stored in the even

arch/mips/kernel/ptrace32.c +2 -2

@@ -97,7 +97,7 @@ long compat_arch_ptrace(struct task_stru
 				break;
 			}
 			fregs = get_fpu_regs(child);
-			if (test_thread_flag(TIF_32BIT_FPREGS)) {
+			if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
 				/*
 				 * The odd registers are actually the high
 				 * order bits of the values stored in the even

@@ -203,7 +203,7 @@ long compat_arch_ptrace(struct task_stru
 				       sizeof(child->thread.fpu));
 				child->thread.fpu.fcr31 = 0;
 			}
-			if (test_thread_flag(TIF_32BIT_FPREGS)) {
+			if (test_tsk_thread_flag(child, TIF_32BIT_FPREGS)) {
 				/*
 				 * The odd registers are actually the high
 				 * order bits of the values stored in the even

Greg Kroah-Hartman

author maintainer

2018-05-28 09:59 UTC #3 lore raw

PATCH 3/268 KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable"

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

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

From: Colin Ian King <[email protected]>

commit ba3696e94d9d590d9a7e55f68e81c25dba515191 upstream.

Trivial fix to spelling mistake in debugfs_entries text.

Fixes 669e846e6c4e ("KVM/MIPS32: MIPS arch specific APIs for KVM")

Signed-off-by Colin Ian King <[email protected]>

Cc Ralf Baechle <[email protected]>

Cc <[email protected]> # 3.10+

Signed-off-by James Hogan <[email protected]>

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

---
 arch/mips/kvm/mips.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

arch/mips/kvm/mips.c +1 -1

@@ -40,7 +40,7 @@ struct kvm_stats_debugfs_item debugfs_en
 	{ "cache",	  VCPU_STAT(cache_exits),	 KVM_STAT_VCPU },
 	{ "signal",	  VCPU_STAT(signal_exits),	 KVM_STAT_VCPU },
 	{ "interrupt",	  VCPU_STAT(int_exits),		 KVM_STAT_VCPU },
-	{ "cop_unsuable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
+	{ "cop_unusable", VCPU_STAT(cop_unusable_exits), KVM_STAT_VCPU },
 	{ "tlbmod",	  VCPU_STAT(tlbmod_exits),	 KVM_STAT_VCPU },
 	{ "tlbmiss_ld",	  VCPU_STAT(tlbmiss_ld_exits),	 KVM_STAT_VCPU },
 	{ "tlbmiss_st",	  VCPU_STAT(tlbmiss_st_exits),	 KVM_STAT_VCPU },

Greg Kroah-Hartman

author maintainer

2018-05-28 09:59 UTC #4 lore raw

PATCH 4/268 affs_lookup(): close a race with affs_remove_link()

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

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

From: Al Viro <[email protected]>

commit 30da870ce4a4e007c901858a96e9e394a1daa74a upstream.

we unlock the directory hash too early - if we are looking at secondary link and primary (in another directory) gets removed just as we unlock, we could have the old primary moved in place of the secondary, leaving us to look into freed entry (and leaving our dentry with ->d_fsdata pointing to a freed entry).

Cc [email protected] # 2.4.4+

Acked-by David Sterba <[email protected]>

Signed-off-by Al Viro <[email protected]>

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

---
 fs/affs/namei.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

fs/affs/namei.c +7 -3

@@ -224,9 +224,10 @@ affs_lookup(struct inode *dir, struct de
 
 	affs_lock_dir(dir);
 	bh = affs_find_entry(dir, dentry);
-	affs_unlock_dir(dir);
-	if (IS_ERR(bh))
+	if (IS_ERR(bh)) {
+		affs_unlock_dir(dir);
 		return ERR_CAST(bh);
+	}
 	if (bh) {
 		u32 ino = bh->b_blocknr;

@@ -240,10 +241,13 @@ affs_lookup(struct inode *dir, struct de
 		}
 		affs_brelse(bh);
 		inode = affs_iget(sb, ino);
-		if (IS_ERR(inode))
+		if (IS_ERR(inode)) {
+			affs_unlock_dir(dir);
 			return ERR_CAST(inode);
+		}
 	}
 	d_add(dentry, inode);
+	affs_unlock_dir(dir);
 	return NULL;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 09:59 UTC #5 lore raw

PATCH 5/268 aio: fix io_destroy(2) vs. lookup_ioctx() race

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

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

From: Al Viro <[email protected]>

commit baf10564fbb66ea222cae66fbff11c444590ffd9 upstream.

kill_ioctx() used to have an explicit RCU delay between removing the reference from ->ioctx_table and percpu_ref_kill() dropping the refcount. At some point that delay had been removed, on the theory that percpu_ref_kill() itself contained an RCU delay. Unfortunately, that was the wrong kind of RCU delay and it didn't care about rcu_read_lock() used by lookup_ioctx(). As the result, we could get ctx freed right under lookup_ioctx(). Tejun has fixed that in a6d7cff472e ("fs/aio: Add explicit RCU grace period when freeing kioctx"); however, that fix is not enough.

Suppose io_destroy() from one thread races with e.g. io_setup() from another; CPU1 removes the reference from current->mm->ioctx_table[...] just as CPU2 has picked it (under rcu_read_lock()). Then CPU1 proceeds to drop the refcount, getting it to 0 and triggering a call of free_ioctx_users(), which proceeds to drop the secondary refcount and once that reaches zero calls free_ioctx_reqs(). That does

        INIT_RCU_WORK(&ctx->free_rwork, free_ioctx);
        queue_rcu_work(system_wq, &ctx->free_rwork);

and schedules freeing the whole thing after RCU delay.

In the meanwhile CPU2 has gotten around to percpu_ref_get(), bumping the refcount from 0 to 1 and returned the reference to io_setup().

Tejun's fix (that queue_rcu_work() in there) guarantees that ctx won't get freed until after percpu_ref_get(). Sure, we'd increment the counter before ctx can be freed. Now we are out of rcu_read_lock() and there's nothing to stop freeing of the whole thing. Unfortunately, CPU2 assumes that since it has grabbed the reference, ctx is *NOT* going away until it gets around to dropping that reference.

The fix is obvious - use percpu_ref_tryget_live() and treat failure as miss. It's not costlier than what we currently do in normal case, it's safe to call since freeing *is* delayed and it closes the race window - either lookup_ioctx() comes before percpu_ref_kill() (in which case ctx->users won't reach 0 until the caller of lookup_ioctx() drops it) or lookup_ioctx() fails, ctx->users is unaffected and caller of lookup_ioctx() doesn't see the object in question at all.

Fixes a6d7cff472e "fs/aio: Add explicit RCU grace period when freeing kioctx"

Signed-off-by Al Viro <[email protected]>

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

---
 fs/aio.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

fs/aio.c +2 -2

@@ -1066,8 +1066,8 @@ static struct kioctx *lookup_ioctx(unsig
 
 	ctx = rcu_dereference(table->table[id]);
 	if (ctx && ctx->user_id == ctx_id) {
-		percpu_ref_get(&ctx->users);
-		ret = ctx;
+		if (percpu_ref_tryget_live(&ctx->users))
+			ret = ctx;
 	}
 out:
 	rcu_read_unlock();

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #6 lore raw

PATCH 6/268 ALSA: timer: Fix pause event notification

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

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

From: Ben Hutchings <[email protected]>

commit 3ae180972564846e6d794e3615e1ab0a1e6c4ef9 upstream.

Commit f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock") combined the start/continue and stop/pause functions, and in doing so changed the event code for the pause case to SNDRV_TIMER_EVENT_CONTINUE. Change it back to SNDRV_TIMER_EVENT_PAUSE.

Fixes f65e0d299807 ("ALSA: timer: Call notifier in the same spinlock")

Signed-off-by Ben Hutchings <[email protected]>

Signed-off-by Takashi Iwai <[email protected]>

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

---
 sound/core/timer.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

sound/core/timer.c +2 -2

@@ -548,7 +548,7 @@ static int snd_timer_stop1(struct snd_ti
 	}
 	timeri->flags &= ~(SNDRV_TIMER_IFLG_RUNNING | SNDRV_TIMER_IFLG_START);
 	snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
-			  SNDRV_TIMER_EVENT_CONTINUE);
+			  SNDRV_TIMER_EVENT_PAUSE);
  unlock:
 	spin_unlock_irqrestore(&timer->lock, flags);
 	return result;

@@ -570,7 +570,7 @@ static int snd_timer_stop_slave(struct s
 		list_del_init(&timeri->ack_list);
 		list_del_init(&timeri->active_list);
 		snd_timer_notify1(timeri, stop ? SNDRV_TIMER_EVENT_STOP :
-				  SNDRV_TIMER_EVENT_CONTINUE);
+				  SNDRV_TIMER_EVENT_PAUSE);
 		spin_unlock(&timeri->timer->lock);
 	}
 	spin_unlock_irqrestore(&slave_active_lock, flags);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #7 lore raw

PATCH 7/268 mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register

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

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

From: Corneliu Doban <[email protected]>

commit 5f651b870485ee60f5abbbd85195a6852978894a upstream.

When the host controller accepts only 32bit writes, the value of the 16bit TRANSFER_MODE register, that has the same 32bit address as the 16bit COMMAND register, needs to be saved and it will be written in a 32bit write together with the command as this will trigger the host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and write it again resulting in wrong value to be written because the initial write value was saved in a shadow and the read-back returned a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are saved for a different reason, although a scenario that will cause the mentioned problem on this registers is not probable.

Fixes b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")

Signed-off-by Corneliu Doban <[email protected]>

Signed-off-by Scott Branden <[email protected]>

Cc [email protected] # v4.1+

Signed-off-by Ulf Hansson <[email protected]>

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

---
 drivers/mmc/host/sdhci-iproc.c |   30 +++++++++++++++++++++++++-----
 1 file changed, 25 insertions(+), 5 deletions(-)

drivers/mmc/host/sdhci-iproc.c +25 -5

@@ -32,6 +32,8 @@ struct sdhci_iproc_host {
 	const struct sdhci_iproc_data *data;
 	u32 shadow_cmd;
 	u32 shadow_blk;
+	bool is_cmd_shadowed;
+	bool is_blk_shadowed;
 };
 
 #define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)

@@ -47,8 +49,22 @@ static inline u32 sdhci_iproc_readl(stru
 
 static u16 sdhci_iproc_readw(struct sdhci_host *host, int reg)
 {
-	u32 val = sdhci_iproc_readl(host, (reg & ~3));
-	u16 word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
+	struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+	struct sdhci_iproc_host *iproc_host = sdhci_pltfm_priv(pltfm_host);
+	u32 val;
+	u16 word;
+
+	if ((reg == SDHCI_TRANSFER_MODE) && iproc_host->is_cmd_shadowed) {
+		/* Get the saved transfer mode */
+		val = iproc_host->shadow_cmd;
+	} else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+		   iproc_host->is_blk_shadowed) {
+		/* Get the saved block info */
+		val = iproc_host->shadow_blk;
+	} else {
+		val = sdhci_iproc_readl(host, (reg & ~3));
+	}
+	word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
 	return word;
 }

@@ -104,13 +120,15 @@ static void sdhci_iproc_writew(struct sd
 
 	if (reg == SDHCI_COMMAND) {
 		/* Write the block now as we are issuing a command */
-		if (iproc_host->shadow_blk != 0) {
+		if (iproc_host->is_blk_shadowed) {
 			sdhci_iproc_writel(host, iproc_host->shadow_blk,
 				SDHCI_BLOCK_SIZE);
-			iproc_host->shadow_blk = 0;
+			iproc_host->is_blk_shadowed = false;
 		}
 		oldval = iproc_host->shadow_cmd;
-	} else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
+		iproc_host->is_cmd_shadowed = false;
+	} else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
+		   iproc_host->is_blk_shadowed) {
 		/* Block size and count are stored in shadow reg */
 		oldval = iproc_host->shadow_blk;
 	} else {

@@ -122,9 +140,11 @@ static void sdhci_iproc_writew(struct sd
 	if (reg == SDHCI_TRANSFER_MODE) {
 		/* Save the transfer mode until the command is issued */
 		iproc_host->shadow_cmd = newval;
+		iproc_host->is_cmd_shadowed = true;
 	} else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
 		/* Save the block info until the command is issued */
 		iproc_host->shadow_blk = newval;
+		iproc_host->is_blk_shadowed = true;
 	} else {
 		/* Command or other regular 32-bit write */
 		sdhci_iproc_writel(host, newval, reg & ~3);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #8 lore raw

PATCH 8/268 libata: Blacklist some Sandisk SSDs for NCQ

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

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

From: Tejun Heo <[email protected]>

commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.

Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up regularly under sustained moderate load with NCQ enabled. Blacklist for now.

Signed-off-by Tejun Heo <[email protected]>

Reported-by Dave Jones <[email protected]>

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

---
 drivers/ata/libata-core.c |    4 ++++
 1 file changed, 4 insertions(+)

drivers/ata/libata-core.c +4 -0

@@ -4187,6 +4187,10 @@ static const struct ata_blacklist_entry
 	/* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */
 	{ "C300-CTFDDAC128MAG",	"0001",		ATA_HORKAGE_NONCQ, },
 
+	/* Some Sandisk SSDs lock up hard with NCQ enabled.  Reported on
+	   SD7SN6S256G and SD8SN8U256G */
+	{ "SanDisk SD[78]SN*G",	NULL,		ATA_HORKAGE_NONCQ, },
+
 	/* devices which puke on READ_NATIVE_MAX */
 	{ "HDS724040KLSA80",	"KFAOA20N",	ATA_HORKAGE_BROKEN_HPA, },
 	{ "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #9 lore raw

PATCH 9/268 libata: blacklist Micron 500IT SSD with MU01 firmware

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

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

From: Sudip Mukherjee <[email protected]>

commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.

While whitelisting Micron M500DC drives, the tweaked blacklist entry enabled queued TRIM from M500IT variants also. But these do not support queued TRIM. And while using those SSDs with the latest kernel we have seen errors and even the partition table getting corrupted.

Some part from the dmesg:

[    6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
[    6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[    6.741026] ata1.00: supports DRM functions and may not be fully accessible
[    6.759887] ata1.00: configured for UDMA/133
[    6.762256] scsi 0:0:0:0: Direct-Access     ATA      Micron_M500IT_MT MU01 PQ: 0 ANSI: 5

and then for the error:

[  120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen
[  120.860338] ata1.00: irq_stat 0x40000008
[  120.860342] ata1.00: failed command: SEND FPDMA QUEUED
[  120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out
         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
[  120.860353] ata1.00: status: { DRDY }
[  120.860543] ata1: hard resetting link
[  121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[  121.166376] ata1.00: supports DRM functions and may not be fully accessible
[  121.186238] ata1.00: supports DRM functions and may not be fully accessible
[  121.204445] ata1.00: configured for UDMA/133
[  121.204454] ata1.00: device reported invalid CHS sector 0
[  121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[  121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
[  121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
[  121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00
[  121.204559] print_req_error: I/O error, dev sda, sector 272512

After few reboots with these errors, and the SSD is corrupted. After blacklisting it, the errors are not seen and the SSD does not get corrupted any more.

Fixes 243918be6393 ("libata: Do not blacklist Micron M500DC")

Cc Martin K. Petersen <[email protected]>

Signed-off-by Sudip Mukherjee <[email protected]>

Signed-off-by Tejun Heo <[email protected]>

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

---
 drivers/ata/libata-core.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/ata/libata-core.c +2 -0

@@ -4251,6 +4251,8 @@ static const struct ata_blacklist_entry
 	{ "SanDisk SD7UB3Q*G1001",	NULL,	ATA_HORKAGE_NOLPM, },
 
 	/* devices that don't properly handle queued TRIM commands */
+	{ "Micron_M500IT_*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
+						ATA_HORKAGE_ZERO_AFTER_TRIM, },
 	{ "Micron_M500_*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
 						ATA_HORKAGE_ZERO_AFTER_TRIM, },
 	{ "Crucial_CT*M500*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #10 lore raw

PATCH 10/268 xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

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

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

From: Joe Jin <[email protected]>

commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.

When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will exchange memory with Xen to meet the requiment. Later drivers call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent() the check condition (dev_addr + size - 1 <= dma_mask) is always false, it prevents calling xen_destroy_contiguous_region() to return the memory to the Xen DMA heap.

This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing coherent alloc/dealloc check before swizzling the MFNs.".

Signed-off-by Joe Jin <[email protected]>

Tested-by John Sobecki <[email protected]>

Reviewed-by Rzeszutek Wilk <[email protected]>

Signed-off-by Konrad Rzeszutek Wilk <[email protected]>

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

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

drivers/xen/swiotlb-xen.c +1 -1

@@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
 	 * physical address */
 	phys = xen_bus_to_phys(dev_addr);
 
-	if (((dev_addr + size - 1 > dma_mask)) ||
+	if (((dev_addr + size - 1 <= dma_mask)) ||
 	    range_straddles_page_boundary(phys, size))
 		xen_destroy_contiguous_region(phys, order);

Ben Hutchings

2018-06-07 20:28 UTC #11 lore raw

Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

Quoted 8 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Jin <[email protected]>
commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.

Quoted 7 lines

When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will exchange memory with Xen to meet the requiment. Later drivers call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent() the check condition (dev_addr + size - 1 <= dma_mask) is always false,

I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e. the condition that is replaced by this commit. If that's always false, the new condition (the logical inverse) must always be true.

[...]

Quoted 11 lines

drivers/xen/swiotlb-xen.c +0 -0
@@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
  	 * physical address */
  	phys = xen_bus_to_phys(dev_addr);
drivers/xen/swiotlb-xen.c +1 -1
-	if (((dev_addr + size - 1 > dma_mask)) ||
+	if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size)) xen_destroy_contiguous_region(phys, order);

So now we will always call xen_destroy_contiguous_region(), whether or not xen_create_contiguous_region() was called during allocation. Is that really the intent? If so, the entire condition could be removed to make this clear.

Alternately, if the commit message is correct, the condition could be simplified to range_straddles_page_boundary(...).

But I'm not at all convinced that either of these is correct. It seems like you need to either find a way of distinguishing between memory allocated with or without the use of xen_create_contiguous_region(), or to use it unconditionally.

Ben.

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Joe Jin

2018-06-07 21:00 UTC #12 lore raw

Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

Quoted 17 lines · Ben Hutchings

Quoted 8 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Jin <[email protected]>
commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
Quoted 7 lines
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will exchange memory with Xen to meet the requiment. Later drivers call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent() the check condition (dev_addr + size - 1 <= dma_mask) is always false,

Quoted 1 line

I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.

Hi Ben,

Yes you are right, sorry I made the mistake, thanks for catch it. Is there any way to fix description from git repo?

Regards,
Joe

Quoted 31 lines

the condition that is replaced by this commit. If that's always false, the new condition (the logical inverse) must always be true.
[...]
Quoted 11 lines
drivers/xen/swiotlb-xen.c +0 -0
@@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
  	 * physical address */
  	phys = xen_bus_to_phys(dev_addr);
drivers/xen/swiotlb-xen.c +1 -1
-	if (((dev_addr + size - 1 > dma_mask)) ||
+	if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size)) xen_destroy_contiguous_region(phys, order);
So now we will always call xen_destroy_contiguous_region(), whether or not xen_create_contiguous_region() was called during allocation. Is that really the intent? If so, the entire condition could be removed to make this clear.
Alternately, if the commit message is correct, the condition could be simplified to range_straddles_page_boundary(...).
But I'm not at all convinced that either of these is correct. It seems like you need to either find a way of distinguishing between memory allocated with or without the use of xen_create_contiguous_region(), or to use it unconditionally.
Ben.

Signature · 4 lines

Oracle <http://www.oracle.com>
Joe Jin | IT Director 
ORACLE | Production Engineering and Operations
600 Oracle Parkway Redwood City, CA US 94065

Ben Hutchings

2018-06-08 12:24 UTC #13 lore raw

Re: [PATCH 4.4 010/268] xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent

Quoted 18 lines · Joe Jin

Quoted 17 lines · Ben Hutchings
Quoted 15 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Joe Jin <[email protected]>
commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
When run raidconfig from Dom0 we found that the Xen DMA heap is reduced, but Dom Heap is increased by the same size. Tracing raidconfig we found that the related ioctl() in megaraid_sas will call dma_alloc_coherent() to apply memory. If the memory allocated by Dom0 is not in the DMA area, it will exchange memory with Xen to meet the requiment. Later drivers call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent() the check condition (dev_addr + size - 1 <= dma_mask) is always false,

Quoted 6 lines

Quoted 1 line
I think this was meant to say (dev_addr + size - 1 > dma_mask), i.e.
Hi Ben,
Yes you are right, sorry I made the mistake, thanks for catch it. Is there any way to fix description from git repo?

No there isn't, but that wasn't my main point. Please address the rest of my message.

Ben.

Quoted 36 lines

Regards,
Joe
Quoted 31 lines
the condition that is replaced by this commit. If that's always false, the new condition (the logical inverse) must always be true.
[...]
Quoted 11 lines
drivers/xen/swiotlb-xen.c +0 -0
@@ -359,7 +359,7 @@ xen_swiotlb_free_coherent(struct device
  	 * physical address */
  	phys = xen_bus_to_phys(dev_addr);
drivers/xen/swiotlb-xen.c +1 -1
-	if (((dev_addr + size - 1 > dma_mask)) ||
+	if (((dev_addr + size - 1 <= dma_mask)) ||
range_straddles_page_boundary(phys, size)) xen_destroy_contiguous_region(phys, order);
So now we will always call xen_destroy_contiguous_region(), whether or not xen_create_contiguous_region() was called during allocation. Is that really the intent? If so, the entire condition could be removed to make this clear.
Alternately, if the commit message is correct, the condition could be simplified to range_straddles_page_boundary(...).
But I'm not at all convinced that either of these is correct. It seems like you need to either find a way of distinguishing between memory allocated with or without the use of xen_create_contiguous_region(), or to use it unconditionally.
Ben.

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #14 lore raw

PATCH 11/268 Revert "ipc/shm: Fix shmat mmap nil-page protection"

[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347

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

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

From: Davidlohr Bueso <[email protected]>

commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.

Patch series "ipc/shm: shmat() fixes around nil-page".

These patches fix two issues reported[1] a while back by Joe and Andrea around how shmat(2) behaves with nil-page.

The first reverts a commit that it was incorrectly thought that mapping nil-page (address=0) was a no no with MAP_FIXED. This is not the case, with the exception of SHM_REMAP; which is address in the second patch.

I chose two patches because it is easier to backport and it explicitly reverts bogus behaviour. Both patches ought to be in -stable and ltp testcases need updated (the added testcase around the cve can be modified to just test for SHM_RND|SHM_REMAP).

[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805

This patch (of 2):

Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection") worked on the idea that we should not be mapping as root addr=0 and MAP_FIXED. However, it was reported that this scenario is in fact valid, thus making the patch both bogus and breaks userspace as well.

For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem initialization[1].

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")

Signed-off-by Davidlohr Bueso <[email protected]>

Reported-by Joe Lawrence <[email protected]>

Reported-by Andrea Arcangeli <[email protected]>

Cc Manfred Spraul <[email protected]>

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

---
 ipc/shm.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

ipc/shm.c +2 -7

@@ -1113,13 +1113,8 @@ long do_shmat(int shmid, char __user *sh
 		goto out;
 	else if ((addr = (ulong)shmaddr)) {
 		if (addr & (shmlba - 1)) {
-			/*
-			 * Round down to the nearest multiple of shmlba.
-			 * For sane do_mmap_pgoff() parameters, avoid
-			 * round downs that trigger nil-page and MAP_FIXED.
-			 */
-			if ((shmflg & SHM_RND) && addr >= shmlba)
-				addr &= ~(shmlba - 1);
+			if (shmflg & SHM_RND)
+				addr &= ~(shmlba - 1);  /* round down */
 			else
 #ifndef __ARCH_FORCE_SHMLBA
 				if (addr & ~PAGE_MASK)

Daniel Sangorrin

2018-05-31 02:37 UTC #15 lore raw

RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

Quoted 11 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On 4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Davidlohr Bueso <[email protected]>
commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
Patch series "ipc/shm: shmat() fixes around nil-page".

Sorry for being a bit late (the pace is really fast here).

I have found a regression from 4.4.133-rc1 to 4.4.134-rc1 using Fuego LTP wrapper.

4.4.134-rc1
tst_test.c:982: INFO: Timeout per run is 0h 05m 00s cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page cve-2017-5669.c:74: INFO: Mapped shared memory to (nil) cve-2017-5669.c:78: FAIL: We have mapped a VM address within the first 64Kb cve-2017-5669.c:84: INFO: Touching shared memory to see if anything strange happens

4.4.133-rc1:

	tst_test.c:982: INFO: Timeout per run is 0h 05m 00s
	cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
	cve-2017-5669.c:67: PASS: shmat returned EINVAL

The culprits should be one or both of the two last commits to ipc/shm (one of them a revert).

- ipc/shm: fix shmat() nil address after round-down when remapping
- Revert "ipc/shm: Fix shmat mmap nil-page protection"

I need to investigate the concrete reason, but for now I just wanted to report it.

Thanks,
Daniel

Quoted 63 lines

These patches fix two issues reported[1] a while back by Joe and Andrea around how shmat(2) behaves with nil-page.
The first reverts a commit that it was incorrectly thought that mapping nil-page (address=0) was a no no with MAP_FIXED. This is not the case, with the exception of SHM_REMAP; which is address in the second patch.
I chose two patches because it is easier to backport and it explicitly reverts bogus behaviour. Both patches ought to be in -stable and ltp testcases need updated (the added testcase around the cve can be modified to just test for SHM_RND|SHM_REMAP).
[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
This patch (of 2):
Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection") worked on the idea that we should not be mapping as root addr=0 and MAP_FIXED. However, it was reported that this scenario is in fact valid, thus making the patch both bogus and breaks userspace as well.
For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem initialization[1].
[1]
https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int1
0/linux.c#n347
Link http://lkml.kernel.org/r/[email protected] open here
Fixes 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
Signed-off-by Davidlohr Bueso <[email protected]>
Reported-by Joe Lawrence <[email protected]>
Reported-by Andrea Arcangeli <[email protected]>
Cc Manfred Spraul <[email protected]>
Cc <[email protected]>
Signed-off-by Andrew Morton <[email protected]>
Signed-off-by Linus Torvalds <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
 ipc/shm.c |    9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)
ipc/shm.c +2 -7
@@ -1113,13 +1113,8 @@ long do_shmat(int shmid, char __user *sh
 		goto out;
 	else if ((addr = (ulong)shmaddr)) {
 		if (addr & (shmlba - 1)) {
-			/*
-			 * Round down to the nearest multiple of shmlba.
-			 * For sane do_mmap_pgoff() parameters, avoid
-			 * round downs that trigger nil-page and MAP_FIXED.
-			 */
-			if ((shmflg & SHM_RND) && addr >= shmlba)
-				addr &= ~(shmlba - 1);
+			if (shmflg & SHM_RND)
+				addr &= ~(shmlba - 1);  /* round down */
 			else
 #ifndef __ARCH_FORCE_SHMLBA
 				if (addr & ~PAGE_MASK)

'Greg Kroah-Hartman'

author maintainer

2018-05-31 06:34 UTC #16 lore raw

Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

Quoted 28 lines · Daniel Sangorrin

Quoted 11 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On 4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Davidlohr Bueso <[email protected]>
commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
Patch series "ipc/shm: shmat() fixes around nil-page".
Sorry for being a bit late (the pace is really fast here).
I have found a regression from 4.4.133-rc1 to 4.4.134-rc1 using Fuego LTP wrapper.
4.4.134-rc1
tst_test.c:982: INFO: Timeout per run is 0h 05m 00s cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page cve-2017-5669.c:74: INFO: Mapped shared memory to (nil) cve-2017-5669.c:78: FAIL: We have mapped a VM address within the first 64Kb cve-2017-5669.c:84: INFO: Touching shared memory to see if anything strange happens
4.4.133-rc1:
	tst_test.c:982: INFO: Timeout per run is 0h 05m 00s
	cve-2017-5669.c:62: INFO: Attempting to attach shared memory to null page
	cve-2017-5669.c:67: PASS: shmat returned EINVAL

Quoted 6 lines

The culprits should be one or both of the two last commits to ipc/shm (one of them a revert).
- ipc/shm: fix shmat() nil address after round-down when remapping
- Revert "ipc/shm: Fix shmat mmap nil-page protection"
I need to investigate the concrete reason, but for now I just wanted to report it.

Thanks for letting us know, but this was reported already. See the emails on lkml with the subject:

	Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
from Davidlohr Bueso
	Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>

where he discusses that the LTP test is incorrect and that the kernel change is correct and that LTP is going to be fixed because of this.

thanks,

greg k-h

Daniel Sangorrin

2018-05-31 07:36 UTC #17 lore raw

RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

Quoted 2 lines

-----Original Message-----
From: 'Greg Kroah-Hartman' [mailto:[email protected]]

Quoted 8 lines

Thanks for letting us know, but this was reported already. See the emails on lkml with the subject:
	Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
from Davidlohr Bueso
	Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
where he discusses that the LTP test is incorrect and that the kernel change is correct and that LTP is going to be fixed because of this.

OK, thank you for the information!

Regards,
Daniel

Naresh Kamboju

2018-05-31 15:55 UTC #18 lore raw

Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

Quoted 11 lines · Daniel Sangorrin

Quoted 2 lines
-----Original Message-----
From: 'Greg Kroah-Hartman' [mailto:[email protected]]
..
Quoted 8 lines
Thanks for letting us know, but this was reported already. See the emails on lkml with the subject:
      Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
from Davidlohr Bueso
      Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
where he discusses that the LTP test is incorrect and that the kernel change is correct and that LTP is going to be fixed because of this.

My two cents,
If you are referring to cve-2017-5669.c
LTP test case is been fixed few hours ago by Rafael Tinoco,

- shm_addr = shmat(shm_id, ((void *)1), SHM_RND);
+ shm_addr = shmat(shm_id, ((void *)1), SHM_RND | SHM_REMAP);

LTP patch pull request and it is been merged.
https://github.com/linux-test-project/ltp/pull/324

Quoted 3 lines

OK, thank you for the information!

- Naresh

Quoted 4 lines

Regards,
Daniel

Daniel Sangorrin

2018-06-04 00:37 UTC #19 lore raw

RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

Quoted 31 lines

-----Original Message-----
From: Naresh Kamboju [mailto:[email protected]]
Sent: Friday, June 1, 2018 12:55 AM
To: Daniel Sangorrin <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>; open list <[email protected]>; linux- stable <[email protected]>; Davidlohr Bueso <[email protected]>; Joe Lawrence <[email protected]>; Andrea Arcangeli <[email protected]>; Manfred Spraul <[email protected]>; Andrew Morton <[email protected]>; Linus Torvalds <[email protected]>
Subject: Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"
Quoted 11 lines · Daniel Sangorrin
Quoted 2 lines
-----Original Message-----
From: 'Greg Kroah-Hartman' [mailto:[email protected]]
..
Quoted 8 lines
Thanks for letting us know, but this was reported already. See the emails on lkml with the subject:
      Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
from Davidlohr Bueso
      Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
where he discusses that the LTP test is incorrect and that the kernel change is correct and that LTP is going to be fixed because of this.
My two cents,
If you are referring to cve-2017-5669.c
LTP test case is been fixed few hours ago by Rafael Tinoco,

Quoted 5 lines

- shm_addr = shmat(shm_id, ((void *)1), SHM_RND);
+ shm_addr = shmat(shm_id, ((void *)1), SHM_RND | SHM_REMAP);
LTP patch pull request and it is been merged.
https://github.com/linux-test-project/ltp/pull/324

Thanks a lot Naresh.
I confirmed that the latest LTP cve-2017-5669 now PASSes.

Thanks,
Daniel

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #20 lore raw

PATCH 12/268 ipc/shm: fix shmat() nil address after round-down when remapping

Link http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805 open here

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

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

From: Davidlohr Bueso <[email protected]>

commit 8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream.

shmat()'s SHM_REMAP option forbids passing a nil address for; this is in fact the very first thing we check for. Andrea reported that for SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check, but we need to check again if the address was rounded down to nil. As of this patch, such cases will return -EINVAL.

Signed-off-by Davidlohr Bueso <[email protected]>

Reported-by Andrea Arcangeli <[email protected]>

Cc Joe Lawrence <[email protected]>

Cc Manfred Spraul <[email protected]>

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

---
 ipc/shm.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

ipc/shm.c +10 -2

@@ -1113,9 +1113,17 @@ long do_shmat(int shmid, char __user *sh
 		goto out;
 	else if ((addr = (ulong)shmaddr)) {
 		if (addr & (shmlba - 1)) {
-			if (shmflg & SHM_RND)
+			if (shmflg & SHM_RND) {
 				addr &= ~(shmlba - 1);  /* round down */
-			else
+
+				/*
+				 * Ensure that the round-down is non-nil
+				 * when remapping. This can happen for
+				 * cases when addr < shmlba.
+				 */
+				if (!addr && (shmflg & SHM_REMAP))
+					goto out;
+			} else
 #ifndef __ARCH_FORCE_SHMLBA
 				if (addr & ~PAGE_MASK)
 #endif

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #21 lore raw

PATCH 13/268 kasan: fix memory hotplug during boot

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

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

From: David Hildenbrand <[email protected]>

commit 3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream.

Using module_init() is wrong. E.g. ACPI adds and onlines memory before our memory notifier gets registered.

This makes sure that ACPI memory detected during boot up will not result in a kernel crash.

Easily reproducible with QEMU, just specify a DIMM when starting up.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes 786a8959912e ("kasan: disable memory hotplug")

Signed-off-by David Hildenbrand <[email protected]>

Acked-by Andrey Ryabinin <[email protected]>

Cc Alexander Potapenko <[email protected]>

Cc Dmitry Vyukov <[email protected]>

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

---
 mm/kasan/kasan.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

mm/kasan/kasan.c +1 -1

@@ -548,5 +548,5 @@ static int __init kasan_memhotplug_init(
 	return 0;
 }
 
-module_init(kasan_memhotplug_init);
+core_initcall(kasan_memhotplug_init);
 #endif

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #22 lore raw

PATCH 14/268 kernel/sys.c: fix potential Spectre v1 issue

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

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

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

From: Gustavo A. R. Silva <[email protected]>

commit 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream.

`resource' can be controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap) kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)

Fix this by sanitizing *resource* before using it to index current->signal->rlim

Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1].

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Gustavo A. R. Silva <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Alexei Starovoitov <[email protected]>

Cc Dan Williams <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Peter Zijlstra <[email protected]>

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

---
 kernel/sys.c |    3 +++
 1 file changed, 3 insertions(+)

kernel/sys.c +3 -0

@@ -53,6 +53,8 @@
 #include <linux/uidgid.h>
 #include <linux/cred.h>
 
+#include <linux/nospec.h>
+
 #include <linux/kmsg_dump.h>
 /* Move somewhere else to avoid recompiling? */
 #include <generated/utsrelease.h>

@@ -1311,6 +1313,7 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned
 	if (resource >= RLIM_NLIMITS)
 		return -EINVAL;
 
+	resource = array_index_nospec(resource, RLIM_NLIMITS);
 	task_lock(current->group_leader);
 	x = current->signal->rlim[resource];
 	task_unlock(current->group_leader);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #23 lore raw

PATCH 15/268 kernel/signal.c: avoid undefined behaviour in kill_something_info

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

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

From: zhongjiang <[email protected]>

commit 4ea77014af0d6205b05503d1c7aac6eace11d473 upstream.

When running kill(72057458746458112, 0) in userspace I hit the following issue.

  UBSAN: Undefined behaviour in kernel/signal.c:1462:11
  negation of -2147483648 cannot be represented in type 'int':
  CPU: 226 PID: 9849 Comm: test Tainted: G    B          ---- -------   3.10.0-327.53.58.70.x86_64_ubsan+ #116
  Hardware name: Huawei Technologies Co., Ltd. RH8100 V3/BC61PBIA, BIOS BLHSV028 11/11/2014
  Call Trace:
    dump_stack+0x19/0x1b
    ubsan_epilogue+0xd/0x50
    __ubsan_handle_negate_overflow+0x109/0x14e
    SYSC_kill+0x43e/0x4d0
    SyS_kill+0xe/0x10
    system_call_fastpath+0x16/0x1b

Add code to avoid the UBSAN detection.

[[email protected]: tweak comment]

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by zhongjiang <[email protected]>

Cc Oleg Nesterov <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Vlastimil Babka <[email protected]>

Cc Xishi Qiu <[email protected]>

Cc Guenter Roeck <[email protected]>

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

---
 kernel/signal.c |    4 ++++
 1 file changed, 4 insertions(+)

kernel/signal.c +4 -0

@@ -1392,6 +1392,10 @@ static int kill_something_info(int sig,
 		return ret;
 	}
 
+	/* -INT_MIN is undefined.  Exclude this case to avoid a UBSAN warning */
+	if (pid == INT_MIN)
+		return -ESRCH;
+
 	read_lock(&tasklist_lock);
 	if (pid != -1) {
 		ret = __kill_pgrp_info(sig, info,

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #24 lore raw

PATCH 16/268 xfs: remove racy hasattr check from attr ops

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

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

From: Brian Foster <[email protected]>

commit 5a93790d4e2df73e30c965ec6e49be82fc3ccfce upstream.

xfs_attr_[get|remove]() have unlocked attribute fork checks to optimize away a lock cycle in cases where the fork does not exist or is otherwise empty. This check is not safe, however, because an attribute fork short form to extent format conversion includes a transient state that causes the xfs_inode_hasattr() check to fail. Specifically, xfs_attr_shortform_to_leaf() creates an empty extent format attribute fork and then adds the existing shortform attributes to it.

This means that lookup of an existing xattr can spuriously return -ENOATTR when racing against a setxattr that causes the associated format conversion. This was originally reproduced by an untar on a particularly configured glusterfs volume, but can also be reproduced on demand with properly crafted xattr requests.

The format conversion occurs under the exclusive ilock. xfs_attr_get() and xfs_attr_remove() already have the proper locking and checks further down in the functions to handle this situation correctly. Drop the unlocked checks to avoid the spurious failure and rely on the existing logic.

Signed-off-by Brian Foster <[email protected]>

Reviewed-by Christoph Hellwig <[email protected]>

Reviewed-by Darrick J. Wong <[email protected]>

Signed-off-by Darrick J. Wong <[email protected]>

Cc Daniel Sangorrin <[email protected]>

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

---
 fs/xfs/libxfs/xfs_attr.c |    6 ------
 1 file changed, 6 deletions(-)

fs/xfs/libxfs/xfs_attr.c +0 -6

@@ -130,9 +130,6 @@ xfs_attr_get(
 	if (XFS_FORCED_SHUTDOWN(ip->i_mount))
 		return -EIO;
 
-	if (!xfs_inode_hasattr(ip))
-		return -ENOATTR;
-
 	error = xfs_attr_args_init(&args, ip, name, flags);
 	if (error)
 		return error;

@@ -417,9 +414,6 @@ xfs_attr_remove(
 	if (XFS_FORCED_SHUTDOWN(dp->i_mount))
 		return -EIO;
 
-	if (!xfs_inode_hasattr(dp))
-		return -ENOATTR;
-
 	error = xfs_attr_args_init(&args, dp, name, flags);
 	if (error)
 		return error;

Greg Kroah-Hartman

author maintainer

2018-05-28 11:23 UTC #25 lore raw

PATCH 17/268 do d_instantiate/unlock_new_inode combinations safely

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

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

From: Al Viro <[email protected]>

commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.

For anything NFS-exported we do _not_ want to unlock new inode before it has grown an alias; original set of fixes got the ordering right, but missed the nasty complication in case of lockdep being enabled - unlock_new_inode() does
lockdep_annotate_inode_mutex_key(inode)
which can only be done before anyone gets a chance to touch ->i_mutex. Unfortunately, flipping the order and doing unlock_new_inode() before d_instantiate() opens a window when mkdir can race with open-by-fhandle on a guessed fhandle, leading to multiple aliases for a directory inode and all the breakage that follows from that.

Correct solution: a new primitive (d_instantiate_new())
combining these two in the right order - lockdep annotate, then d_instantiate(), then the rest of unlock_new_inode(). All combinations of d_instantiate() with unlock_new_inode() should be converted to that.

Cc [email protected] # 2.6.29 and later

Tested-by Mike Marshall <[email protected]>

Reviewed-by Andreas Dilger <[email protected]>

Signed-off-by Al Viro <[email protected]>

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

---
 fs/btrfs/inode.c       |   16 ++++------------
 fs/dcache.c            |   22 ++++++++++++++++++++++
 fs/ecryptfs/inode.c    |    3 +--
 fs/ext2/namei.c        |    6 ++----
 fs/ext4/namei.c        |    6 ++----
 fs/f2fs/namei.c        |   12 ++++--------
 fs/jffs2/dir.c         |   12 ++++--------
 fs/jfs/namei.c         |   12 ++++--------
 fs/nilfs2/namei.c      |    6 ++----
 fs/reiserfs/namei.c    |   12 ++++--------
 fs/udf/namei.c         |    6 ++----
 fs/ufs/namei.c         |    6 ++----
 include/linux/dcache.h |    1 +
 13 files changed, 54 insertions(+), 66 deletions(-)

fs/btrfs/inode.c +4 ~~-12~~

@@ -6413,8 +6413,7 @@ static int btrfs_mknod(struct inode *dir
 		goto out_unlock_inode;
 	} else {
 		btrfs_update_inode(trans, root, inode);
-		unlock_new_inode(inode);
-		d_instantiate(dentry, inode);
+		d_instantiate_new(dentry, inode);
 	}
 
 out_unlock:

@@ -6489,8 +6488,7 @@ static int btrfs_create(struct inode *di
 		goto out_unlock_inode;
 
 	BTRFS_I(inode)->io_tree.ops = &btrfs_extent_io_ops;
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 
 out_unlock:
 	btrfs_end_transaction(trans, root);

@@ -6633,12 +6631,7 @@ static int btrfs_mkdir(struct inode *dir
 	if (err)
 		goto out_fail_inode;
 
-	d_instantiate(dentry, inode);
-	/*
-	 * mkdir is special.  We're unlocking after we call d_instantiate
-	 * to avoid a race with nfsd calling d_instantiate.
-	 */
-	unlock_new_inode(inode);
+	d_instantiate_new(dentry, inode);
 	drop_on_err = 0;
 
 out_fail:

@@ -9789,8 +9782,7 @@ static int btrfs_symlink(struct inode *d
 		goto out_unlock_inode;
 	}
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 
 out_unlock:
 	btrfs_end_transaction(trans, root);

fs/dcache.c +22 -0

@@ -1897,6 +1897,28 @@ struct dentry *d_instantiate_unique(stru
 
 EXPORT_SYMBOL(d_instantiate_unique);
 
+/*
+ * This should be equivalent to d_instantiate() + unlock_new_inode(),
+ * with lockdep-related part of unlock_new_inode() done before
+ * anything else.  Use that instead of open-coding d_instantiate()/
+ * unlock_new_inode() combinations.
+ */
+void d_instantiate_new(struct dentry *entry, struct inode *inode)
+{
+	BUG_ON(!hlist_unhashed(&entry->d_u.d_alias));
+	BUG_ON(!inode);
+	lockdep_annotate_inode_mutex_key(inode);
+	security_d_instantiate(entry, inode);
+	spin_lock(&inode->i_lock);
+	__d_instantiate(entry, inode);
+	WARN_ON(!(inode->i_state & I_NEW));
+	inode->i_state &= ~I_NEW;
+	smp_mb();
+	wake_up_bit(&inode->i_state, __I_NEW);
+	spin_unlock(&inode->i_lock);
+}
+EXPORT_SYMBOL(d_instantiate_new);
+
 /**
  * d_instantiate_no_diralias - instantiate a non-aliased dentry
  * @entry: dentry to complete

fs/ecryptfs/inode.c +1 -2

@@ -287,8 +287,7 @@ ecryptfs_create(struct inode *directory_
 		iput(ecryptfs_inode);
 		goto out;
 	}
-	unlock_new_inode(ecryptfs_inode);
-	d_instantiate(ecryptfs_dentry, ecryptfs_inode);
+	d_instantiate_new(ecryptfs_dentry, ecryptfs_inode);
 out:
 	return rc;
 }

fs/ext2/namei.c +2 -4

@@ -40,8 +40,7 @@ static inline int ext2_add_nondir(struct
 {
 	int err = ext2_add_link(dentry, inode);
 	if (!err) {
-		unlock_new_inode(inode);
-		d_instantiate(dentry, inode);
+		d_instantiate_new(dentry, inode);
 		return 0;
 	}
 	inode_dec_link_count(inode);

@@ -267,8 +266,7 @@ static int ext2_mkdir(struct inode * dir
 	if (err)
 		goto out_fail;
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 out:
 	return err;

fs/ext4/namei.c +2 -4

@@ -2429,8 +2429,7 @@ static int ext4_add_nondir(handle_t *han
 	int err = ext4_add_entry(handle, dentry, inode);
 	if (!err) {
 		ext4_mark_inode_dirty(handle, inode);
-		unlock_new_inode(inode);
-		d_instantiate(dentry, inode);
+		d_instantiate_new(dentry, inode);
 		return 0;
 	}
 	drop_nlink(inode);

@@ -2669,8 +2668,7 @@ out_clear_inode:
 	err = ext4_mark_inode_dirty(handle, dir);
 	if (err)
 		goto out_clear_inode;
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	if (IS_DIRSYNC(dir))
 		ext4_handle_sync(handle);

fs/f2fs/namei.c +4 -8

@@ -150,8 +150,7 @@ static int f2fs_create(struct inode *dir
 
 	alloc_nid_done(sbi, ino);
 
-	d_instantiate(dentry, inode);
-	unlock_new_inode(inode);
+	d_instantiate_new(dentry, inode);
 
 	if (IS_DIRSYNC(dir))
 		f2fs_sync_fs(sbi->sb, 1);

@@ -399,8 +398,7 @@ static int f2fs_symlink(struct inode *di
 	err = page_symlink(inode, p_str, p_len);
 
 err_out:
-	d_instantiate(dentry, inode);
-	unlock_new_inode(inode);
+	d_instantiate_new(dentry, inode);
 
 	/*
 	 * Let's flush symlink data in order to avoid broken symlink as much as

@@ -454,8 +452,7 @@ static int f2fs_mkdir(struct inode *dir,
 
 	alloc_nid_done(sbi, inode->i_ino);
 
-	d_instantiate(dentry, inode);
-	unlock_new_inode(inode);
+	d_instantiate_new(dentry, inode);
 
 	if (IS_DIRSYNC(dir))
 		f2fs_sync_fs(sbi->sb, 1);

@@ -499,8 +496,7 @@ static int f2fs_mknod(struct inode *dir,
 
 	alloc_nid_done(sbi, inode->i_ino);
 
-	d_instantiate(dentry, inode);
-	unlock_new_inode(inode);
+	d_instantiate_new(dentry, inode);
 
 	if (IS_DIRSYNC(dir))
 		f2fs_sync_fs(sbi->sb, 1);

fs/jffs2/dir.c +4 -8

@@ -207,8 +207,7 @@ static int jffs2_create(struct inode *di
 		  __func__, inode->i_ino, inode->i_mode, inode->i_nlink,
 		  f->inocache->pino_nlink, inode->i_mapping->nrpages);
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	return 0;
 
  fail:

@@ -428,8 +427,7 @@ static int jffs2_symlink (struct inode *
 	mutex_unlock(&dir_f->sem);
 	jffs2_complete_reservation(c);
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	return 0;
 
  fail:

@@ -573,8 +571,7 @@ static int jffs2_mkdir (struct inode *di
 	mutex_unlock(&dir_f->sem);
 	jffs2_complete_reservation(c);
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	return 0;
 
  fail:

@@ -745,8 +742,7 @@ static int jffs2_mknod (struct inode *di
 	mutex_unlock(&dir_f->sem);
 	jffs2_complete_reservation(c);
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	return 0;
 
  fail:

fs/jfs/namei.c +4 -8

@@ -178,8 +178,7 @@ static int jfs_create(struct inode *dip,
 		unlock_new_inode(ip);
 		iput(ip);
 	} else {
-		unlock_new_inode(ip);
-		d_instantiate(dentry, ip);
+		d_instantiate_new(dentry, ip);
 	}
 
       out2:

@@ -313,8 +312,7 @@ static int jfs_mkdir(struct inode *dip,
 		unlock_new_inode(ip);
 		iput(ip);
 	} else {
-		unlock_new_inode(ip);
-		d_instantiate(dentry, ip);
+		d_instantiate_new(dentry, ip);
 	}
 
       out2:

@@ -1058,8 +1056,7 @@ static int jfs_symlink(struct inode *dip
 		unlock_new_inode(ip);
 		iput(ip);
 	} else {
-		unlock_new_inode(ip);
-		d_instantiate(dentry, ip);
+		d_instantiate_new(dentry, ip);
 	}
 
       out2:

@@ -1443,8 +1440,7 @@ static int jfs_mknod(struct inode *dir,
 		unlock_new_inode(ip);
 		iput(ip);
 	} else {
-		unlock_new_inode(ip);
-		d_instantiate(dentry, ip);
+		d_instantiate_new(dentry, ip);
 	}
 
       out1:

fs/nilfs2/namei.c +2 -4

@@ -50,8 +50,7 @@ static inline int nilfs_add_nondir(struc
 {
 	int err = nilfs_add_link(dentry, inode);
 	if (!err) {
-		d_instantiate(dentry, inode);
-		unlock_new_inode(inode);
+		d_instantiate_new(dentry, inode);
 		return 0;
 	}
 	inode_dec_link_count(inode);

@@ -246,8 +245,7 @@ static int nilfs_mkdir(struct inode *dir
 		goto out_fail;
 
 	nilfs_mark_inode_dirty(inode);
-	d_instantiate(dentry, inode);
-	unlock_new_inode(inode);
+	d_instantiate_new(dentry, inode);
 out:
 	if (!err)
 		err = nilfs_transaction_commit(dir->i_sb);

fs/reiserfs/namei.c +4 -8

@@ -687,8 +687,7 @@ static int reiserfs_create(struct inode
 	reiserfs_update_inode_transaction(inode);
 	reiserfs_update_inode_transaction(dir);
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	retval = journal_end(&th);
 
 out_failed:

@@ -771,8 +770,7 @@ static int reiserfs_mknod(struct inode *
 		goto out_failed;
 	}
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	retval = journal_end(&th);
 
 out_failed:

@@ -871,8 +869,7 @@ static int reiserfs_mkdir(struct inode *
 	/* the above add_entry did not update dir's stat data */
 	reiserfs_update_sd(&th, dir);
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	retval = journal_end(&th);
 out_failed:
 	reiserfs_write_unlock(dir->i_sb);

@@ -1186,8 +1183,7 @@ static int reiserfs_symlink(struct inode
 		goto out_failed;
 	}
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	retval = journal_end(&th);
 out_failed:
 	reiserfs_write_unlock(parent_dir->i_sb);

fs/udf/namei.c +2 -4

@@ -611,8 +611,7 @@ static int udf_add_nondir(struct dentry
 	if (fibh.sbh != fibh.ebh)
 		brelse(fibh.ebh);
 	brelse(fibh.sbh);
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 
 	return 0;
 }

@@ -722,8 +721,7 @@ static int udf_mkdir(struct inode *dir,
 	inc_nlink(dir);
 	dir->i_ctime = dir->i_mtime = current_fs_time(dir->i_sb);
 	mark_inode_dirty(dir);
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	if (fibh.sbh != fibh.ebh)
 		brelse(fibh.ebh);
 	brelse(fibh.sbh);

fs/ufs/namei.c +2 -4

@@ -38,8 +38,7 @@ static inline int ufs_add_nondir(struct
 {
 	int err = ufs_add_link(dentry, inode);
 	if (!err) {
-		unlock_new_inode(inode);
-		d_instantiate(dentry, inode);
+		d_instantiate_new(dentry, inode);
 		return 0;
 	}
 	inode_dec_link_count(inode);

@@ -191,8 +190,7 @@ static int ufs_mkdir(struct inode * dir,
 	if (err)
 		goto out_fail;
 
-	unlock_new_inode(inode);
-	d_instantiate(dentry, inode);
+	d_instantiate_new(dentry, inode);
 	return 0;
 
 out_fail:

include/linux/dcache.h +1 -0

@@ -236,6 +236,7 @@ extern seqlock_t rename_lock;
  * These are the low-level FS interfaces to the dcache..
  */
 extern void d_instantiate(struct dentry *, struct inode *);
+extern void d_instantiate_new(struct dentry *, struct inode *);
 extern struct dentry * d_instantiate_unique(struct dentry *, struct inode *);
 extern int d_instantiate_no_diralias(struct dentry *, struct inode *);
 extern void __d_drop(struct dentry *dentry);

Ben Hutchings

2018-06-08 13:17 UTC #26 lore raw

Re: [PATCH 4.4 017/268] do d_instantiate/unlock_new_inode combinations safely

Quoted 20 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Al Viro <[email protected]>
commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee upstream.
For anything NFS-exported we do _not_ want to unlock new inode before it has grown an alias; original set of fixes got the ordering right, but missed the nasty complication in case of lockdep being enabled - unlock_new_inode() does
lockdep_annotate_inode_mutex_key(inode)
which can only be done before anyone gets a chance to touch ->i_mutex. Unfortunately, flipping the order and doing unlock_new_inode() before d_instantiate() opens a window when mkdir can race with open-by-fhandle on a guessed fhandle, leading to multiple aliases for a directory inode and all the breakage that follows from that.

Quoted 5 lines

Correct solution: a new primitive (d_instantiate_new())
combining these two in the right order - lockdep annotate, then d_instantiate(), then the rest of unlock_new_inode(). All combinations of d_instantiate() with unlock_new_inode() should be converted to that.

[...]

I think you missed xfs, which has a wrapper around unlock_new_inode() called xfs_finish_inode_setup(). It looks like xfs_generic_create() and xfs_vn_symlink() still need this conversion.

Ben.

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #27 lore raw

PATCH 18/268 firewire-ohci: work around oversized DMA reads on JMicron controllers

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

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

From: Hector Martin <[email protected]>

[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]

At least some JMicron controllers issue buggy oversized DMA reads when fetching context descriptors, always fetching 0x20 bytes at once for descriptors which are only 0x10 bytes long. This is often harmless, but can cause page faults on modern systems with IOMMUs:

DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read

This works around the problem by always leaving 0x10 padding bytes at the end of descriptor buffer pages, which should be harmless to do unconditionally for controllers in case others have the same behavior.

Signed-off-by Hector Martin <[email protected]>

Reviewed-by Clemens Ladisch <[email protected]>

Signed-off-by Stefan Richter <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/firewire/ohci.c |    8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

drivers/firewire/ohci.c +7 -1

@@ -1130,7 +1130,13 @@ static int context_add_buffer(struct con
 		return -ENOMEM;
 
 	offset = (void *)&desc->buffer - (void *)desc;
-	desc->buffer_size = PAGE_SIZE - offset;
+	/*
+	 * Some controllers, like JMicron ones, always issue 0x20-byte DMA reads
+	 * for descriptors, even 0x10-byte ones. This can cause page faults when
+	 * an IOMMU is in use and the oversized read crosses a page boundary.
+	 * Work around this by always leaving at least 0x10 bytes of padding.
+	 */
+	desc->buffer_size = PAGE_SIZE - offset - 0x10;
 	desc->buffer_bus = bus_addr + offset;
 	desc->used = 0;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #28 lore raw

PATCH 19/268 NFSv4: always set NFS_LOCK_LOST when a lock is lost.

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

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

From: NeilBrown <[email protected]>

[ Upstream commit dce2630c7da73b0634686bca557cc8945cc450c8 ]

There are 2 comments in the NFSv4 code which suggest that SIGLOST should possibly be sent to a process. In these cases a lock has been lost.
The current practice is to set NFS_LOCK_LOST so that read/write returns EIO when a lock is lost.
So change these comments to code when sets NFS_LOCK_LOST.

One case is when lock recovery after apparent server restart fails with NFS4ERR_DENIED, NFS4ERR_RECLAIM_BAD, or NFS4ERRO_RECLAIM_CONFLICT. The other case is when a lock attempt as part of lease recovery fails with NFS4ERR_DENIED.

In an ideal world, these should not happen. However I have a packet trace showing an NFSv4.1 session getting NFS4ERR_BADSESSION after an extended network parition. The NFSv4.1 client treats this like server reboot until/unless it get NFS4ERR_NO_GRACE, in which case it switches over to "nograce" recovery mode. In this network trace, the client attempts to recover a lock and the server (incorrectly) reports NFS4ERR_DENIED rather than NFS4ERR_NO_GRACE. This leads to the ineffective comment and the client then continues to write using the OPEN stateid.

Signed-off-by NeilBrown <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/nfs/nfs4proc.c  |   12 ++++++++----
 fs/nfs/nfs4state.c |    5 ++++-
 2 files changed, 12 insertions(+), 5 deletions(-)

fs/nfs/nfs4proc.c +8 -4

@@ -1780,7 +1780,7 @@ static int nfs4_open_reclaim(struct nfs4
 	return ret;
 }
 
-static int nfs4_handle_delegation_recall_error(struct nfs_server *server, struct nfs4_state *state, const nfs4_stateid *stateid, int err)
+static int nfs4_handle_delegation_recall_error(struct nfs_server *server, struct nfs4_state *state, const nfs4_stateid *stateid, struct file_lock *fl, int err)
 {
 	switch (err) {
 		default:

@@ -1827,7 +1827,11 @@ static int nfs4_handle_delegation_recall
 			return -EAGAIN;
 		case -ENOMEM:
 		case -NFS4ERR_DENIED:
-			/* kill_proc(fl->fl_pid, SIGLOST, 1); */
+			if (fl) {
+				struct nfs4_lock_state *lsp = fl->fl_u.nfs4_fl.owner;
+				if (lsp)
+					set_bit(NFS_LOCK_LOST, &lsp->ls_flags);
+			}
 			return 0;
 	}
 	return err;

@@ -1863,7 +1867,7 @@ int nfs4_open_delegation_recall(struct n
 		err = nfs4_open_recover_helper(opendata, FMODE_READ);
 	}
 	nfs4_opendata_put(opendata);
-	return nfs4_handle_delegation_recall_error(server, state, stateid, err);
+	return nfs4_handle_delegation_recall_error(server, state, stateid, NULL, err);
 }
 
 static void nfs4_open_confirm_prepare(struct rpc_task *task, void *calldata)

@@ -6157,7 +6161,7 @@ int nfs4_lock_delegation_recall(struct f
 	if (err != 0)
 		return err;
 	err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
-	return nfs4_handle_delegation_recall_error(server, state, stateid, err);
+	return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
 }
 
 struct nfs_release_lockowner_data {

fs/nfs/nfs4state.c +4 -1

@@ -1386,6 +1386,7 @@ static int nfs4_reclaim_locks(struct nfs
 	struct inode *inode = state->inode;
 	struct nfs_inode *nfsi = NFS_I(inode);
 	struct file_lock *fl;
+	struct nfs4_lock_state *lsp;
 	int status = 0;
 	struct file_lock_context *flctx = inode->i_flctx;
 	struct list_head *list;

@@ -1426,7 +1427,9 @@ restart:
 		case -NFS4ERR_DENIED:
 		case -NFS4ERR_RECLAIM_BAD:
 		case -NFS4ERR_RECLAIM_CONFLICT:
-			/* kill_proc(fl->fl_pid, SIGLOST, 1); */
+			lsp = fl->fl_u.nfs4_fl.owner;
+			if (lsp)
+				set_bit(NFS_LOCK_LOST, &lsp->ls_flags);
 			status = 0;
 		}
 		spin_lock(&flctx->flc_lock);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #29 lore raw

PATCH 20/268 ALSA: hda - Use IS_REACHABLE() for dependency on input

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

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

From: Takashi Iwai <[email protected]>

[ Upstream commit c469652bb5e8fb715db7d152f46d33b3740c9b87 ]

The commit ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek HD-audio codec") introduced the reverse-selection of CONFIG_INPUT for Realtek codec in order to avoid the mess with dependency between built-in and modules. Later on, we obtained IS_REACHABLE() macro exactly for this kind of problems, and now we can remove th INPUT selection in Kconfig and put IS_REACHABLE(INPUT) to the appropriate places in the code, so that the driver doesn't need to select other subsystem forcibly.

Fixes ffcd28d88e4f ("ALSA: hda - Select INPUT for Realtek HD-audio codec")

Reported-by Randy Dunlap <[email protected]>

Acked-by Randy Dunlap <[email protected]> # and build-tested

Signed-off-by Takashi Iwai <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 sound/pci/hda/Kconfig         |    1 -
 sound/pci/hda/patch_realtek.c |    5 +++++
 2 files changed, 5 insertions(+), 1 deletion(-)

sound/pci/hda/Kconfig +0 -1

@@ -84,7 +84,6 @@ config SND_HDA_PATCH_LOADER
 config SND_HDA_CODEC_REALTEK
 	tristate "Build Realtek HD-audio codec support"
 	select SND_HDA_GENERIC
-	select INPUT
 	help
 	  Say Y or M here to include Realtek HD-audio codec support in
 	  snd-hda-intel driver, such as ALC880.

sound/pci/hda/patch_realtek.c +5 -0

@@ -3495,6 +3495,7 @@ static void alc280_fixup_hp_gpio4(struct
 	}
 }
 
+#if IS_REACHABLE(INPUT)
 static void gpio2_mic_hotkey_event(struct hda_codec *codec,
 				   struct hda_jack_callback *event)
 {

@@ -3627,6 +3628,10 @@ static void alc233_fixup_lenovo_line2_mi
 		spec->kb_dev = NULL;
 	}
 }
+#else /* INPUT */
+#define alc280_fixup_hp_gpio2_mic_hotkey	NULL
+#define alc233_fixup_lenovo_line2_mic_hotkey	NULL
+#endif /* INPUT */
 
 static void alc269_fixup_hp_line1_mic1_led(struct hda_codec *codec,
 				const struct hda_fixup *fix, int action)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #30 lore raw

PATCH 21/268 ASoC: au1x: Fix timeout tests in au1xac97c_ac97_read()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 123af9043e93cb6f235207d260d50f832cdb5439 ]

The loop timeout doesn't work because it's a post op and ends with "tmo" set to -1. I changed it from a post-op to a pre-op and I changed the initial the starting value from 5 to 6 so we still iterate 5 times. I left the other as it was because it's a large number.

Fixes b3c70c9ea62a ("ASoC: Alchemy AC97C/I2SC audio support")

Signed-off-by Mark Brown <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 sound/soc/au1x/ac97c.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

sound/soc/au1x/ac97c.c +3 -3

@@ -91,8 +91,8 @@ static unsigned short au1xac97c_ac97_rea
 	do {
 		mutex_lock(&ctx->lock);
 
-		tmo = 5;
-		while ((RD(ctx, AC97_STATUS) & STAT_CP) && tmo--)
+		tmo = 6;
+		while ((RD(ctx, AC97_STATUS) & STAT_CP) && --tmo)
 			udelay(21);	/* wait an ac97 frame time */
 		if (!tmo) {
 			pr_debug("ac97rd timeout #1\n");

@@ -105,7 +105,7 @@ static unsigned short au1xac97c_ac97_rea
 		 * poll, Forrest, poll...
 		 */
 		tmo = 0x10000;
-		while ((RD(ctx, AC97_STATUS) & STAT_CP) && tmo--)
+		while ((RD(ctx, AC97_STATUS) & STAT_CP) && --tmo)
 			asm volatile ("nop");
 		data = RD(ctx, AC97_CMDRESP);

Greg Kroah-Hartman

author maintainer

2018-05-28 09:59 UTC #31 lore raw

PATCH 22/268 kvm: x86: fix KVM_XEN_HVM_CONFIG ioctl

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

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

From: Paolo Bonzini <[email protected]>

[ Upstream commit 51776043afa415435c7e4636204fbe4f7edc4501 ]

This ioctl is obsolete (it was used by Xenner as far as I know) but still let's not break it gratuitously... Its handler is copying directly into struct kvm. Go through a bounce buffer instead, with the added benefit that we can actually do something useful with the flags argument---the previous code was exiting with -EINVAL but still doing the copy.

This technically is a userspace ABI breakage, but since no one should be using the ioctl, it's a good occasion to see if someone actually complains.

Cc Kees Cook <[email protected]>

Cc Radim Krčmář <[email protected]>

Signed-off-by Paolo Bonzini <[email protected]>

Signed-off-by Kees Cook <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/x86/kvm/x86.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

arch/x86/kvm/x86.c +4 -3

@@ -3973,13 +3973,14 @@ long kvm_arch_vm_ioctl(struct file *filp
 		mutex_unlock(&kvm->lock);
 		break;
 	case KVM_XEN_HVM_CONFIG: {
+		struct kvm_xen_hvm_config xhc;
 		r = -EFAULT;
-		if (copy_from_user(&kvm->arch.xen_hvm_config, argp,
-				   sizeof(struct kvm_xen_hvm_config)))
+		if (copy_from_user(&xhc, argp, sizeof(xhc)))
 			goto out;
 		r = -EINVAL;
-		if (kvm->arch.xen_hvm_config.flags)
+		if (xhc.flags)
 			goto out;
+		memcpy(&kvm->arch.xen_hvm_config, &xhc, sizeof(xhc));
 		r = 0;
 		break;
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:14 UTC #32 lore raw

PATCH 23/268 tracing/hrtimer: Fix tracing bugs by taking all clock bases and modes into account

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

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

From: Anna-Maria Gleixner <[email protected]>

[ Upstream commit 91633eed73a3ac37aaece5c8c1f93a18bae616a9 ]

So far only CLOCK_MONOTONIC and CLOCK_REALTIME were taken into account as well as HRTIMER_MODE_ABS/REL in the hrtimer_init tracepoint. The query for detecting the ABS or REL timer modes is not valid anymore, it got broken by the introduction of HRTIMER_MODE_PINNED.

HRTIMER_MODE_PINNED is not evaluated in the hrtimer_init() call, but for the sake of completeness print all given modes.

Signed-off-by Anna-Maria Gleixner <[email protected]>

Cc Christoph Hellwig <[email protected]>

Cc John Stultz <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 include/trace/events/timer.h |   20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

include/trace/events/timer.h +16 -4

@@ -125,6 +125,20 @@ DEFINE_EVENT(timer_class, timer_cancel,
 	TP_ARGS(timer)
 );
 
+#define decode_clockid(type)						\
+	__print_symbolic(type,						\
+		{ CLOCK_REALTIME,	"CLOCK_REALTIME"	},	\
+		{ CLOCK_MONOTONIC,	"CLOCK_MONOTONIC"	},	\
+		{ CLOCK_BOOTTIME,	"CLOCK_BOOTTIME"	},	\
+		{ CLOCK_TAI,		"CLOCK_TAI"		})
+
+#define decode_hrtimer_mode(mode)					\
+	__print_symbolic(mode,						\
+		{ HRTIMER_MODE_ABS,		"ABS"		},	\
+		{ HRTIMER_MODE_REL,		"REL"		},	\
+		{ HRTIMER_MODE_ABS_PINNED,	"ABS|PINNED"	},	\
+		{ HRTIMER_MODE_REL_PINNED,	"REL|PINNED"	})
+
 /**
  * hrtimer_init - called when the hrtimer is initialized
  * @hrtimer:	pointer to struct hrtimer

@@ -151,10 +165,8 @@ TRACE_EVENT(hrtimer_init,
 	),
 
 	TP_printk("hrtimer=%p clockid=%s mode=%s", __entry->hrtimer,
-		  __entry->clockid == CLOCK_REALTIME ?
-			"CLOCK_REALTIME" : "CLOCK_MONOTONIC",
-		  __entry->mode == HRTIMER_MODE_ABS ?
-			"HRTIMER_MODE_ABS" : "HRTIMER_MODE_REL")
+		  decode_clockid(__entry->clockid),
+		  decode_hrtimer_mode(__entry->mode))
 );
 
 /**

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #33 lore raw

PATCH 24/268 PCI: Add function 1 DMA alias quirk for Marvell 9128

Link https://bugzilla.kernel.org/show_bug.cgi?id=42679

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

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

From: Alex Williamson <[email protected]>

[ Upstream commit aa008206634363ef800fbd5f0262016c9ff81dea ]

The Marvell 9128 is the original device generating bug 42679, from which many other Marvell DMA alias quirks have been sourced, but we didn't have positive confirmation of the fix on 9128 until now.

Link https://www.spinics.net/lists/kvm/msg161459.html

Reported-by Binarus <[email protected]>

Tested-by Binarus <[email protected]>

Signed-off-by Alex Williamson <[email protected]>

Signed-off-by Bjorn Helgaas <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/pci/quirks.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/pci/quirks.c +2 -0

@@ -3614,6 +3614,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_M
 			 quirk_dma_func1_alias);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9123,
 			 quirk_dma_func1_alias);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9128,
+			 quirk_dma_func1_alias);
 /* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c14 */
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9130,
 			 quirk_dma_func1_alias);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #34 lore raw

PATCH 25/268 tools lib traceevent: Simplify pointer print logic and fix %pF

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

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

From: "Steven Rostedt (VMware)" <[email protected]>

[ Upstream commit 38d70b7ca1769f26c0b79f3c08ff2cc949712b59 ]

When processing %pX in pretty_print(), simplify the logic slightly by incrementing the ptr to the format string if isalnum(ptr[1]) is true. This follows the logic a bit more closely to what is in the kernel.

Also, this fixes a small bug where %pF was not giving the offset of the function.

Signed-off-by Steven Rostedt <[email protected]>

Acked-by Namhyung Kim <[email protected]>

Cc Andrew Morton <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 tools/lib/traceevent/event-parse.c |   17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

tools/lib/traceevent/event-parse.c +9 -8

@@ -4905,21 +4905,22 @@ static void pretty_print(struct trace_se
 				else
 					ls = 2;
 
-				if (*(ptr+1) == 'F' || *(ptr+1) == 'f' ||
-				    *(ptr+1) == 'S' || *(ptr+1) == 's') {
+				if (isalnum(ptr[1]))
 					ptr++;
+
+				if (*ptr == 'F' || *ptr == 'f' ||
+				    *ptr == 'S' || *ptr == 's') {
 					show_func = *ptr;
-				} else if (*(ptr+1) == 'M' || *(ptr+1) == 'm') {
-					print_mac_arg(s, *(ptr+1), data, size, event, arg);
-					ptr++;
+				} else if (*ptr == 'M' || *ptr == 'm') {
+					print_mac_arg(s, *ptr, data, size, event, arg);
 					arg = arg->next;
 					break;
-				} else if (*(ptr+1) == 'I' || *(ptr+1) == 'i') {
+				} else if (*ptr == 'I' || *ptr == 'i') {
 					int n;
 
-					n = print_ip_arg(s, ptr+1, data, size, event, arg);
+					n = print_ip_arg(s, ptr, data, size, event, arg);
 					if (n > 0) {
-						ptr += n;
+						ptr += n - 1;
 						arg = arg->next;
 						break;
 					}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #35 lore raw

PATCH 26/268 perf callchain: Fix attr.sample_max_stack setting

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

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

From: Arnaldo Carvalho de Melo <[email protected]>

[ Upstream commit 249d98e567e25dd03e015e2d31e1b7b9648f34df ]

When setting the "dwarf" unwinder for a specific event and not specifying the max-stack, the attr.sample_max_stack ended up using an uninitialized callchain_param.max_stack, fix it by using designated initializers for that callchain_param variable, zeroing all non explicitely initialized struct members.

Here is what happened:

  # perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
  callchain: type DWARF
  callchain: stack dump size 8192
  perf_event_attr:
    type                             2
    size                             112
    config                           0x730
    { sample_period, sample_freq }   1
    sample_type                      IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
    exclude_callchain_user           1
    { wakeup_events, wakeup_watermark } 1
    sample_regs_user                 0xff0fff
    sample_stack_user                8192
    sample_max_stack                 50656
  sys_perf_event_open failed, error -75
  Value too large for defined data type
  # perf trace -vv --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
  callchain: type DWARF
  callchain: stack dump size 8192
  perf_event_attr:
    type                             2
    size                             112
    config                           0x730
    sample_type                      IP|TID|TIME|ADDR|CALLCHAIN|CPU|PERIOD|RAW|REGS_USER|STACK_USER|DATA_SRC
    exclude_callchain_user           1
    sample_regs_user                 0xff0fff
    sample_stack_user                8192
    sample_max_stack                 30448
  sys_perf_event_open failed, error -75
  Value too large for defined data type
  #

Now the attr.sample_max_stack is set to zero and the above works as expected:

  # perf trace --no-syscalls --max-stack 4 -e probe_libc:inet_pton/call-graph=dwarf/ ping -6 -c 1 ::1
  PING ::1(::1) 56 data bytes
  64 bytes from ::1: icmp_seq=1 ttl=64 time=0.072 ms

--- ::1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.072/0.072/0.072/0.000 ms

       0.000 probe_libc:inet_pton:(7feb7a998350))
                                         __inet_pton (inlined)
                                         gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                         __GI_getaddrinfo (inlined)
                                         [0xffffaa39b6108f3f] (/usr/bin/ping)

Cc Adrian Hunter <[email protected]>

Cc David Ahern <[email protected]>

Cc Hendrick Brueckner <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Namhyung Kim <[email protected]>

Cc Thomas Richter <[email protected]>

Cc Wang Nan <[email protected]>

Link https://lkml.kernel.org/n/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 tools/perf/util/evsel.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

tools/perf/util/evsel.c +4 -4

@@ -624,13 +624,13 @@ static void apply_config_terms(struct pe
 	struct perf_evsel_config_term *term;
 	struct list_head *config_terms = &evsel->config_terms;
 	struct perf_event_attr *attr = &evsel->attr;
-	struct callchain_param param;
+	/* callgraph default */
+	struct callchain_param param = {
+		.record_mode = callchain_param.record_mode,
+	};
 	u32 dump_size = 0;
 	char *callgraph_buf = NULL;
 
-	/* callgraph default */
-	param.record_mode = callchain_param.record_mode;
-
 	list_for_each_entry(term, config_terms, list) {
 		switch (term->type) {
 		case PERF_EVSEL__CONFIG_TERM_PERIOD:

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #36 lore raw

PATCH 27/268 tools lib traceevent: Fix get_field_str() for dynamic strings

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

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

From: "Steven Rostedt (VMware)" <[email protected]>

[ Upstream commit d777f8de99b05d399c0e4e51cdce016f26bd971b ]

If a field is a dynamic string, get_field_str() returned just the offset/size value and not the string. Have it parse the offset/size correctly to return the actual string. Otherwise filtering fails when trying to filter fields that are dynamic strings.

Reported-by Gopanapalli Pradeep <[email protected]>

Signed-off-by Steven Rostedt <[email protected]>

Acked-by Namhyung Kim <[email protected]>

Cc Andrew Morton <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Arnaldo Carvalho de Melo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 tools/lib/traceevent/parse-filter.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

tools/lib/traceevent/parse-filter.c +9 -1

@@ -1867,17 +1867,25 @@ static const char *get_field_str(struct
 	struct pevent *pevent;
 	unsigned long long addr;
 	const char *val = NULL;
+	unsigned int size;
 	char hex[64];
 
 	/* If the field is not a string convert it */
 	if (arg->str.field->flags & FIELD_IS_STRING) {
 		val = record->data + arg->str.field->offset;
+		size = arg->str.field->size;
+
+		if (arg->str.field->flags & FIELD_IS_DYNAMIC) {
+			addr = *(unsigned int *)val;
+			val = record->data + (addr & 0xffff);
+			size = addr >> 16;
+		}
 
 		/*
 		 * We need to copy the data since we can't be sure the field
 		 * is null terminated.
 		 */
-		if (*(val + arg->str.field->size - 1)) {
+		if (*(val + size - 1)) {
 			/* copy it */
 			memcpy(arg->str.buffer, val, arg->str.field->size);
 			/* the buffer is already NULL terminated */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #37 lore raw

PATCH 28/268 dm thin: fix documentation relative to low water mark threshold

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

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

From: mulhern <[email protected]>

[ Upstream commit 9b28a1102efc75d81298198166ead87d643a29ce ]

Fixes:
1. The use of "exceeds" when the opposite of exceeds, falls below, was meant.
2. Properly speaking, a table can not exceed a threshold.

It emphasizes the important point, which is that it is the userspace daemon's responsibility to check for low free space when a device is resumed, since it won't get a special event indicating low free space in that situation.

Signed-off-by mulhern <[email protected]>

Signed-off-by Mike Snitzer <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 Documentation/device-mapper/thin-provisioning.txt |    8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

Documentation/device-mapper/thin-provisioning.txt +5 -3

@@ -112,9 +112,11 @@ $low_water_mark is expressed in blocks o
 free space on the data device drops below this level then a dm event
 will be triggered which a userspace daemon should catch allowing it to
 extend the pool device.  Only one such event will be sent.
-Resuming a device with a new table itself triggers an event so the
-userspace daemon can use this to detect a situation where a new table
-already exceeds the threshold.
+
+No special event is triggered if a just resumed device's free space is below
+the low water mark. However, resuming a device always triggers an
+event; a userspace daemon should verify that free space exceeds the low
+water mark when handling this event.
 
 A low water mark for the metadata device is maintained in the kernel and
 will trigger a dm event if free space on the metadata device drops below

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #38 lore raw

PATCH 29/268 nfs: Do not convert nfs_idmap_cache_timeout to jiffies

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

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

From: Jan Chochol <[email protected]>

[ Upstream commit cbebc6ef4fc830f4040d4140bf53484812d5d5d9 ]

Since commit 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring") nfs_idmap_cache_timeout changed units from jiffies to seconds. Unfortunately sysctl interface was not updated accordingly.

As a effect updating /proc/sys/fs/nfs/idmap_cache_timeout with some value will incorrectly multiply this value by HZ.
Also reading /proc/sys/fs/nfs/idmap_cache_timeout will show real value divided by HZ.

Fixes 57e62324e469 ("NFS: Store the legacy idmapper result in the keyring")

Signed-off-by Jan Chochol <[email protected]>

Signed-off-by Trond Myklebust <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/nfs/nfs4sysctl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

fs/nfs/nfs4sysctl.c +1 -1

@@ -31,7 +31,7 @@ static struct ctl_table nfs4_cb_sysctls[
 		.data = &nfs_idmap_cache_timeout,
 		.maxlen = sizeof(int),
 		.mode = 0644,
-		.proc_handler = proc_dointvec_jiffies,
+		.proc_handler = proc_dointvec,
 	},
 	{ }
 };

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #39 lore raw

PATCH 31/268 kconfig: Dont leak main menus during parsing

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit 0724a7c32a54e3e50d28e19e30c59014f61d4e2c ]

If a 'mainmenu' entry appeared in the Kconfig files, two things would leak:

- The 'struct property' allocated for the default "Linux Kernel Configuration" prompt.

- The string for the T_WORD/T_WORD_QUOTE prompt after the T_MAINMENU token, allocated on the heap in zconf.l.

To fix it, introduce a new 'no_mainmenu_stmt' nonterminal that matches if there's no 'mainmenu' and adds the default prompt. That means the prompt only gets allocated once regardless of whether there's a 'mainmenu' statement or not, and managing it becomes simple.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 344,568 bytes in 14,352 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 344,440 bytes in 14,350 blocks
	   ...

Signed-off-by Masahiro Yamada <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 scripts/kconfig/zconf.y |   33 ++++++++++++++++++++++++---------
 1 file changed, 24 insertions(+), 9 deletions(-)

scripts/kconfig/zconf.y +24 -9

@@ -107,7 +107,27 @@ static struct menu *current_menu, *curre
 %%
 input: nl start | start;
 
-start: mainmenu_stmt stmt_list | stmt_list;
+start: mainmenu_stmt stmt_list | no_mainmenu_stmt stmt_list;
+
+/* mainmenu entry */
+
+mainmenu_stmt: T_MAINMENU prompt nl
+{
+	menu_add_prompt(P_MENU, $2, NULL);
+};
+
+/* Default main menu, if there's no mainmenu entry */
+
+no_mainmenu_stmt: /* empty */
+{
+	/*
+	 * Hack: Keep the main menu title on the heap so we can safely free it
+	 * later regardless of whether it comes from the 'prompt' in
+	 * mainmenu_stmt or here
+	 */
+	menu_add_prompt(P_MENU, strdup("Linux Kernel Configuration"), NULL);
+};
+
 
 stmt_list:
 	  /* empty */

@@ -344,13 +364,6 @@ if_block:
 	| if_block choice_stmt
 ;
 
-/* mainmenu entry */
-
-mainmenu_stmt: T_MAINMENU prompt nl
-{
-	menu_add_prompt(P_MENU, $2, NULL);
-};
-
 /* menu entry */
 
 menu: T_MENU prompt T_EOL

@@ -495,6 +508,7 @@ word_opt: /* empty */			{ $$ = NULL; }
 
 void conf_parse(const char *name)
 {
+	const char *tmp;
 	struct symbol *sym;
 	int i;

@@ -502,7 +516,6 @@ void conf_parse(const char *name)
 
 	sym_init();
 	_menu_init();
-	rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
 
 	if (getenv("ZCONF_DEBUG"))
 		zconfdebug = 1;

@@ -512,8 +525,10 @@ void conf_parse(const char *name)
 	if (!modules_sym)
 		modules_sym = sym_find( "n" );
 
+	tmp = rootmenu.prompt->text;
 	rootmenu.prompt->text = _(rootmenu.prompt->text);
 	rootmenu.prompt->text = sym_expand_string_value(rootmenu.prompt->text);
+	free((char*)tmp);
 
 	menu_finalize(&rootmenu);
 	for_all_symbols(i, sym) {

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #40 lore raw

PATCH 32/268 kconfig: Fix automatic menu creation mem leak

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit ae7440ef0c8013d68c00dad6900e7cce5311bb1c ]

expr_trans_compare() always allocates and returns a new expression, giving the following leak outline:

	...
	*Allocate*
	basedep = expr_trans_compare(basedep, E_UNEQUAL, &symbol_no);
	...
	for (menu = parent->next; menu; menu = menu->next) {
		...
		*Copy*
		dep2 = expr_copy(basedep);
		...
		*Free copy*
		expr_free(dep2);
	}
	*basedep lost!*

Fix by freeing 'basedep' after the loop.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 344,376 bytes in 14,349 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 44,448 bytes in 1,852 blocks
	   ...

Signed-off-by Masahiro Yamada <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 scripts/kconfig/menu.c |    1 +
 1 file changed, 1 insertion(+)

scripts/kconfig/menu.c +1 -0

@@ -364,6 +364,7 @@ void menu_finalize(struct menu *parent)
 			menu->parent = parent;
 			last_menu = menu;
 		}
+		expr_free(basedep);
 		if (last_menu) {
 			parent->list = parent->next;
 			parent->next = last_menu->next;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #41 lore raw

PATCH 33/268 kconfig: Fix expr_free() E_NOT leak

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit 5b1374b3b3c2fc4f63a398adfa446fb8eff791a4 ]

Only the E_NOT operand and not the E_NOT node itself was freed, due to accidentally returning too early in expr_free(). Outline of leak:

	switch (e->type) {
	...
	case E_NOT:
		expr_free(e->left.expr);
		return;
	...
	}
	*Never reached, 'e' leaked*
	free(e);

Fix by changing the 'return' to a 'break'.

Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix:

	LEAK SUMMARY:
	   definitely lost: 44,448 bytes in 1,852 blocks
	   ...

Summary after the fix:

	LEAK SUMMARY:
	   definitely lost: 1,608 bytes in 67 blocks
	   ...

Signed-off-by Masahiro Yamada <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 scripts/kconfig/expr.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

scripts/kconfig/expr.c +1 -1

@@ -113,7 +113,7 @@ void expr_free(struct expr *e)
 		break;
 	case E_NOT:
 		expr_free(e->left.expr);
-		return;
+		break;
 	case E_EQUAL:
 	case E_GEQ:
 	case E_GTH:

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #42 lore raw

PATCH 34/268 mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()

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

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

From: "weiyongjun (A)" <[email protected]>

[ Upstream commit 0ddcff49b672239dda94d70d0fcf50317a9f4b51 ]

'hwname' is malloced in hwsim_new_radio_nl() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak.

Fixes ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")

Signed-off-by Wei Yongjun <[email protected]>

Reviewed-by Ben Hutchings <[email protected]>

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/wireless/mac80211_hwsim.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/net/wireless/mac80211_hwsim.c +3 -1

@@ -2925,8 +2925,10 @@ static int hwsim_new_radio_nl(struct sk_
 	if (info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]) {
 		u32 idx = nla_get_u32(info->attrs[HWSIM_ATTR_REG_CUSTOM_REG]);
 
-		if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom))
+		if (idx >= ARRAY_SIZE(hwsim_world_regdom_custom)) {
+			kfree(hwname);
 			return -EINVAL;
+		}
 		param.regd = hwsim_world_regdom_custom[idx];
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #43 lore raw

PATCH 35/268 ipmi/powernv: Fix error return code in ipmi_powernv_probe()

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

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

From: Wei Yongjun <[email protected]>

[ Upstream commit e749d328b0b450aa78d562fa26a0cd8872325dd9 ]

Fix to return a negative error code from the request_irq() error handling case instead of 0, as done elsewhere in this function.

Fixes dce143c3381c ("ipmi/powernv: Convert to irq event interface")

Signed-off-by Wei Yongjun <[email protected]>

Reviewed-by Alexey Kardashevskiy <[email protected]>

Signed-off-by Corey Minyard <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/char/ipmi/ipmi_powernv.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/char/ipmi/ipmi_powernv.c +3 -2

@@ -251,8 +251,9 @@ static int ipmi_powernv_probe(struct pla
 		ipmi->irq = opal_event_request(prop);
 	}
 
-	if (request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
-				"opal-ipmi", ipmi)) {
+	rc = request_irq(ipmi->irq, ipmi_opal_event, IRQ_TYPE_LEVEL_HIGH,
+			 "opal-ipmi", ipmi);
+	if (rc) {
 		dev_warn(dev, "Unable to request irq\n");
 		goto err_dispose;
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #44 lore raw

PATCH 36/268 Btrfs: set plug for fsync

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

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

From: Liu Bo <[email protected]>

[ Upstream commit 343e4fc1c60971b0734de26dbbd475d433950982 ]

Setting plug can merge adjacent IOs before dispatching IOs to the disk driver.

Without plug, it'd not be a problem for single disk usecases, but for multiple disks using raid profile, a large IO can be split to several IOs of stripe length, and plug can be helpful to bring them together for each disk so that we can save several disk access.

Moreover, fsync issues synchronous writes, so plug can really take effect.

Signed-off-by Liu Bo <[email protected]>

Reviewed-by David Sterba <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/btrfs/file.c |    9 +++++++++
 1 file changed, 9 insertions(+)

fs/btrfs/file.c +9 -0

@@ -1861,10 +1861,19 @@ int btrfs_release_file(struct inode *ino
 static int start_ordered_ops(struct inode *inode, loff_t start, loff_t end)
 {
 	int ret;
+	struct blk_plug plug;
 
+	/*
+	 * This is only called in fsync, which would do synchronous writes, so
+	 * a plug can merge adjacent IOs as much as possible.  Esp. in case of
+	 * multiple disks using raid profile, a large IO can be split to
+	 * several segments of stripe length (currently 64K).
+	 */
+	blk_start_plug(&plug);
 	atomic_inc(&BTRFS_I(inode)->sync_writers);
 	ret = btrfs_fdatawrite_range(inode, start, end);
 	atomic_dec(&BTRFS_I(inode)->sync_writers);
+	blk_finish_plug(&plug);
 
 	return ret;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #45 lore raw

PATCH 37/268 btrfs: Fix out of bounds access in btrfs_search_slot

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

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

From: Nikolay Borisov <[email protected]>

[ Upstream commit 9ea2c7c9da13c9073e371c046cbbc45481ecb459 ]

When modifying a tree where the root is at BTRFS_MAX_LEVEL - 1 then the level variable is going to be 7 (this is the max height of the tree). On the other hand btrfs_cow_block is always called with "level + 1" as an index into the nodes and slots arrays. This leads to an out of bounds access. Admittdely this will be benign since an OOB access of the nodes array will likely read the 0th element from the slots array, which in this case is going to be 0 (since we start CoW at the top of the tree). The OOB access into the slots array in turn will read the 0th and 1st values of the locks array, which would both be 0 at the time. However, this benign behavior relies on the fact that the path being passed hasn't been initialised, if it has already been used to query a btree then it could potentially have populated the nodes/slots arrays.

Fix it by explicitly checking if we are at level 7 (the maximum allowed index in nodes/slots arrays) and explicitly call the CoW routine with NULL for parent's node/slot.

Signed-off-by Nikolay Borisov <[email protected]>

Fixes-coverity-id: 711515

Reviewed-by David Sterba <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/btrfs/ctree.c |   12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

fs/btrfs/ctree.c +9 -3

@@ -2769,6 +2769,8 @@ again:
 		 * contention with the cow code
 		 */
 		if (cow) {
+			bool last_level = (level == (BTRFS_MAX_LEVEL - 1));
+
 			/*
 			 * if we don't really need to cow this block
 			 * then we don't want to set the path blocking,

@@ -2793,9 +2795,13 @@ again:
 			}
 
 			btrfs_set_path_blocking(p);
-			err = btrfs_cow_block(trans, root, b,
-					      p->nodes[level + 1],
-					      p->slots[level + 1], &b);
+			if (last_level)
+				err = btrfs_cow_block(trans, root, b, NULL, 0,
+						      &b);
+			else
+				err = btrfs_cow_block(trans, root, b,
+						      p->nodes[level + 1],
+						      p->slots[level + 1], &b);
 			if (err) {
 				ret = err;
 				goto done;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #46 lore raw

PATCH 38/268 Btrfs: fix scrub to repair raid6 corruption

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

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

From: Liu Bo <[email protected]>

[ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]

The raid6 corruption is that,
suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice,

- the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild,
- if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild,

however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content.

We've fixed normal reads to rebuild raid6 correctly with more retries in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix scrub to do the exactly same rebuild process.

[1]: https://patchwork.kernel.org/patch/10091755/

Signed-off-by Liu Bo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/btrfs/raid56.c  |   18 ++++++++++++++----
 fs/btrfs/volumes.c |    9 ++++++++-
 2 files changed, 22 insertions(+), 5 deletions(-)

fs/btrfs/raid56.c +14 -4

@@ -2160,11 +2160,21 @@ int raid56_parity_recover(struct btrfs_r
 	}
 
 	/*
-	 * reconstruct from the q stripe if they are
-	 * asking for mirror 3
+	 * Loop retry:
+	 * for 'mirror == 2', reconstruct from all other stripes.
+	 * for 'mirror_num > 2', select a stripe to fail on every retry.
 	 */
-	if (mirror_num == 3)
-		rbio->failb = rbio->real_stripes - 2;
+	if (mirror_num > 2) {
+		/*
+		 * 'mirror == 3' is to fail the p stripe and
+		 * reconstruct from the q stripe.  'mirror > 3' is to
+		 * fail a data stripe and reconstruct from p+q stripe.
+		 */
+		rbio->failb = rbio->real_stripes - (mirror_num - 1);
+		ASSERT(rbio->failb > 0);
+		if (rbio->failb <= rbio->faila)
+			rbio->failb--;
+	}
 
 	ret = lock_stripe_add(rbio);

fs/btrfs/volumes.c +8 -1

@@ -5056,7 +5056,14 @@ int btrfs_num_copies(struct btrfs_fs_inf
 	else if (map->type & BTRFS_BLOCK_GROUP_RAID5)
 		ret = 2;
 	else if (map->type & BTRFS_BLOCK_GROUP_RAID6)
-		ret = 3;
+		/*
+		 * There could be two corrupted data stripes, we need
+		 * to loop retry in order to rebuild the correct data.
+		 *
+		 * Fail a stripe at a time on every retry except the
+		 * stripe under reconstruction.
+		 */
+		ret = map->num_stripes;
 	else
 		ret = 1;
 	free_extent_map(em);

Ben Hutchings

2018-06-08 18:42 UTC #47 lore raw

Re: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

Quoted 7 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>
[ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]

The diff here is actually from commit 8810f7517a3b ("Btrfs: make raid6 rebuild retry more", mentioned in this commit message). (Sasha, please try to work out why commit messages and descriptions are getting mixed up in your auto-selections.)

Maybe stable branches should get the real commit 762221f095e3 as well?

Ben.

Quoted 75 lines

The raid6 corruption is that,
suppose that all disks can be read without problems and if the content that was read out doesn't match its checksum, currently for raid6 btrfs at most retries twice,
- the 1st retry is to rebuild with all other stripes, it'll eventually be a raid5 xor rebuild,
- if the 1st fails, the 2nd retry will deliberately fail parity p so that it will do raid6 style rebuild,
however, the chances are that another non-parity stripe content also has something corrupted, so that the above retries are not able to return correct content.
We've fixed normal reads to rebuild raid6 correctly with more retries in Patch "Btrfs: make raid6 rebuild retry more"[1], this is to fix scrub to do the exactly same rebuild process.
[1]: https://patchwork.kernel.org/patch/10091755/
Signed-off-by Liu Bo <[email protected]>
Signed-off-by David Sterba <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
fs/btrfs/raid56.c | 18 ++++++++++++++----
fs/btrfs/volumes.c | 9 ++++++++-
 2 files changed, 22 insertions(+), 5 deletions(-)
fs/btrfs/raid56.c +0 -0
@@ -2160,11 +2160,21 @@ int raid56_parity_recover(struct btrfs_r
  	}
/*
fs/btrfs/raid56.c +3 -2
-	 * reconstruct from the q stripe if they are
-	 * asking for mirror 3
+	 * Loop retry:
+	 * for 'mirror == 2', reconstruct from all other stripes.
+	 * for 'mirror_num > 2', select a stripe to fail on every retry.
*/
fs/btrfs/raid56.c +11 -2
-	if (mirror_num == 3)
-		rbio->failb = rbio->real_stripes - 2;
+	if (mirror_num > 2) {
+		/*
+		 * 'mirror == 3' is to fail the p stripe and
+		 * reconstruct from the q stripe.  'mirror > 3' is to
+		 * fail a data stripe and reconstruct from p+q stripe.
+		 */
+		rbio->failb = rbio->real_stripes - (mirror_num - 1);
+		ASSERT(rbio->failb > 0);
+		if (rbio->failb <= rbio->faila)
+			rbio->failb--;
+	}
ret = lock_stripe_add(rbio);
fs/btrfs/volumes.c +8 -1
@@ -5056,7 +5056,14 @@ int btrfs_num_copies(struct btrfs_fs_inf
  	else if (map->type & BTRFS_BLOCK_GROUP_RAID5)
  		ret = 2;
  	else if (map->type & BTRFS_BLOCK_GROUP_RAID6)
-		ret = 3;
+		/*
+		 * There could be two corrupted data stripes, we need
+		 * to loop retry in order to rebuild the correct data.
+		 *
+		 * Fail a stripe at a time on every retry except the
+		 * stripe under reconstruction.
+		 */
+		ret = map->num_stripes;
else
ret = 1;
free_extent_map(em);

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Greg Kroah-Hartman

author maintainer

2018-06-14 08:19 UTC #48 lore raw

Re: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

Quoted 7 lines · Ben Hutchings

Quoted 6 lines · Greg Kroah-Hartman
4.4-stable review patch.ï¿½ï¿½If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>

Quoted 8 lines

Quoted 1 line
[ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]
The diff here is actually from commit 8810f7517a3b ("Btrfs: make raid6 rebuild retry more", mentioned in this commit message). (Sasha, please try to work out why commit messages and descriptions are getting mixed up in your auto-selections.)
Maybe stable branches should get the real commit 762221f095e3 as well?

Ugh, not good. Sasha, can you fix this up and send me patches for it, separate from your pull requests?

thanks,

greg k-h

Sasha Levin

2018-06-14 23:01 UTC #49 lore raw

Re: [PATCH 4.4 038/268] Btrfs: fix scrub to repair raid6 corruption

Quoted 15 lines · Greg Kroah-Hartman

Quoted 14 lines · Ben Hutchings
Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Bo <[email protected]>
[ Upstream commit 762221f095e3932669093466aaf4b85ed9ad2ac1 ]
The diff here is actually from commit 8810f7517a3b ("Btrfs: make raid6 rebuild retry more", mentioned in this commit message). (Sasha, please try to work out why commit messages and descriptions are getting mixed up in your auto-selections.)

Quoted 4 lines

Quoted 1 line
Maybe stable branches should get the real commit 762221f095e3 as well?
Ugh, not good. Sasha, can you fix this up and send me patches for it, separate from your pull requests?

Crap, I see what's wrong. I'll send fixes later tonight.

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #50 lore raw

PATCH 39/268 scsi: fas216: fix sense buffer initialization

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 96d5eaa9bb74d299508d811d865c2c41b38b0301 ]

While testing with the ARM specific memset() macro removed, I ran into a compiler warning that shows an old bug:

drivers/scsi/arm/fas216.c: In function 'fas216_rq_sns_done':
drivers/scsi/arm/fas216.c:2014:40: error: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess]

It turns out that the definition of the scsi_cmd structure changed back in linux-2.6.25, so now we clear only four bytes (sizeof(pointer)) instead of 96 (SCSI_SENSE_BUFFERSIZE). I did not check whether we actually need to initialize the buffer here, but it's clear that if we do it, we should use the correct size.

Fixes de25deb18016 ("[SCSI] use dynamically allocated sense buffer")

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/arm/fas216.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/arm/fas216.c +1 -1

@@ -2009,7 +2009,7 @@ static void fas216_rq_sns_done(FAS216_In
 		 * have valid data in the sense buffer that could
 		 * confuse the higher levels.
 		 */
-		memset(SCpnt->sense_buffer, 0, sizeof(SCpnt->sense_buffer));
+		memset(SCpnt->sense_buffer, 0, SCSI_SENSE_BUFFERSIZE);
 //printk("scsi%d.%c: sense buffer: ", info->host->host_no, '0' + SCpnt->device->id);
 //{ int i; for (i = 0; i < 32; i++) printk("%02x ", SCpnt->sense_buffer[i]); printk("\n"); }
 	/*

Greg Kroah-Hartman

author maintainer

2018-05-28 10:15 UTC #51 lore raw

PATCH 40/268 HID: roccat: prevent an out of bounds read in kovaplus_profile_activated()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit 7ad81482cad67cbe1ec808490d1ddfc420c42008 ]

We get the "new_profile_index" value from the mouse device when we're handling raw events. Smatch taints it as untrusted data and complains that we need a bounds check. This seems like a reasonable warning otherwise there is a small read beyond the end of the array.

Fixes 0e70f97f257e ("HID: roccat: Add support for Kova[+] mouse")

Acked-by Silvan Jegen <[email protected]>

Signed-off-by Jiri Kosina <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/hid/hid-roccat-kovaplus.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/hid/hid-roccat-kovaplus.c +2 -0

@@ -37,6 +37,8 @@ static uint kovaplus_convert_event_cpi(u
 static void kovaplus_profile_activated(struct kovaplus_device *kovaplus,
 		uint new_profile_index)
 {
+	if (new_profile_index >= ARRAY_SIZE(kovaplus->profile_settings))
+		return;
 	kovaplus->actual_profile = new_profile_index;
 	kovaplus->actual_cpi = kovaplus->profile_settings[new_profile_index].cpi_startup_level;
 	kovaplus->actual_x_sensitivity = kovaplus->profile_settings[new_profile_index].sensitivity_x;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #52 lore raw

PATCH 41/268 jffs2: Fix use-after-free bug in jffs2_iget()s error handling path

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

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

From: Jake Daryll Obina <[email protected]>

[ Upstream commit 5bdd0c6f89fba430e18d636493398389dadc3b17 ]

If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode() can get called twice in the error handling path, the first call in jffs2_iget() itself and the second through iget_failed(). This can result to a use-after-free error in the second jffs2_do_clear_inode() call, such as shown by the oops below wherein the second jffs2_do_clear_inode() call was trying to free node fragments that were already freed in the first jffs2_do_clear_inode() call.

[   78.178860] jffs2: error: (1904) jffs2_do_read_inode_internal: CRC failed for read_inode of inode 24 at physical location 0x1fc00c
[   78.178914] Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b7b
[   78.185871] pgd = ffffffc03a567000
[   78.188794] [6b6b6b6b6b6b6b7b] *pgd=0000000000000000, *pud=0000000000000000
[   78.194968] Internal error: Oops: 96000004 [#1] PREEMPT SMP
...
[   78.513147] PC is at rb_first_postorder+0xc/0x28
[   78.516503] LR is at jffs2_kill_fragtree+0x28/0x90 [jffs2]
[   78.520672] pc : [<ffffff8008323d28>] lr : [<ffffff8000eb1cc8>] pstate: 60000105
[   78.526757] sp : ffffff800cea38f0
[   78.528753] x29: ffffff800cea38f0 x28: ffffffc01f3f8e80
[   78.532754] x27: 0000000000000000 x26: ffffff800cea3c70
[   78.536756] x25: 00000000dc67c8ae x24: ffffffc033d6945d
[   78.540759] x23: ffffffc036811740 x22: ffffff800891a5b8
[   78.544760] x21: 0000000000000000 x20: 0000000000000000
[   78.548762] x19: ffffffc037d48910 x18: ffffff800891a588
[   78.552764] x17: 0000000000000800 x16: 0000000000000c00
[   78.556766] x15: 0000000000000010 x14: 6f2065646f6e695f
[   78.560767] x13: 6461657220726f66 x12: 2064656c69616620
[   78.564769] x11: 435243203a6c616e x10: 7265746e695f6564
[   78.568771] x9 : 6f6e695f64616572 x8 : ffffffc037974038
[   78.572774] x7 : bbbbbbbbbbbbbbbb x6 : 0000000000000008
[   78.576775] x5 : 002f91d85bd44a2f x4 : 0000000000000000
[   78.580777] x3 : 0000000000000000 x2 : 000000403755e000
[   78.584779] x1 : 6b6b6b6b6b6b6b6b x0 : 6b6b6b6b6b6b6b6b
...
[   79.038551] [<ffffff8008323d28>] rb_first_postorder+0xc/0x28
[   79.042962] [<ffffff8000eb5578>] jffs2_do_clear_inode+0x88/0x100 [jffs2]
[   79.048395] [<ffffff8000eb9ddc>] jffs2_evict_inode+0x3c/0x48 [jffs2]
[   79.053443] [<ffffff8008201ca8>] evict+0xb0/0x168
[   79.056835] [<ffffff8008202650>] iput+0x1c0/0x200
[   79.060228] [<ffffff800820408c>] iget_failed+0x30/0x3c
[   79.064097] [<ffffff8000eba0c0>] jffs2_iget+0x2d8/0x360 [jffs2]
[   79.068740] [<ffffff8000eb0a60>] jffs2_lookup+0xe8/0x130 [jffs2]
[   79.073434] [<ffffff80081f1a28>] lookup_slow+0x118/0x190
[   79.077435] [<ffffff80081f4708>] walk_component+0xfc/0x28c
[   79.081610] [<ffffff80081f4dd0>] path_lookupat+0x84/0x108
[   79.085699] [<ffffff80081f5578>] filename_lookup+0x88/0x100
[   79.089960] [<ffffff80081f572c>] user_path_at_empty+0x58/0x6c
[   79.094396] [<ffffff80081ebe14>] vfs_statx+0xa4/0x114
[   79.098138] [<ffffff80081ec44c>] SyS_newfstatat+0x58/0x98
[   79.102227] [<ffffff800808354c>] __sys_trace_return+0x0/0x4
[   79.106489] Code: d65f03c0 f9400001 b40000e1 aa0103e0 (f9400821)

The jffs2_do_clear_inode() call in jffs2_iget() is unnecessary since iget_failed() will eventually call jffs2_do_clear_inode() if needed, so just remove it.

Fixes 5451f79f5f81 ("iget: stop JFFS2 from using iget() and read_inode()")

Reviewed-by Richard Weinberger <[email protected]>

Signed-off-by Jake Daryll Obina <[email protected]>

Signed-off-by Al Viro <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/jffs2/fs.c |    1 -
 1 file changed, 1 deletion(-)

fs/jffs2/fs.c +0 -1

@@ -361,7 +361,6 @@ error_io:
 	ret = -EIO;
 error:
 	mutex_unlock(&f->sem);
-	jffs2_do_clear_inode(c, f);
 	iget_failed(inode);
 	return ERR_PTR(ret);
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #53 lore raw

PATCH 42/268 powerpc/numa: Use ibm,max-associativity-domains to discover possible nodes

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

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

From: Michael Bringmann <[email protected]>

[ Upstream commit a346137e9142b039fd13af2e59696e3d40c487ef ]

On powerpc systems which allow 'hot-add' of CPU or memory resources, it may occur that the new resources are to be inserted into nodes that were not used for these resources at bootup. In the kernel, any node that is used must be defined and initialized. These empty nodes may occur when,

* Dedicated vs. shared resources. Shared resources require information such as the VPHN hcall for CPU assignment to nodes. Associativity decisions made based on dedicated resource rules, such as associativity properties in the device tree, may vary from decisions made using the values returned by the VPHN hcall.

* memoryless nodes at boot. Nodes need to be defined as 'possible' at boot for operation with other code modules. Previously, the powerpc code would limit the set of possible nodes to those which have memory assigned at boot, and were thus online. Subsequent add/remove of CPUs or memory would only work with this subset of possible nodes.

* memoryless nodes with CPUs at boot. Due to the previous restriction on nodes, nodes that had CPUs but no memory were being collapsed into other nodes that did have memory at boot. In practice this meant that the node assignment presented by the runtime kernel differed from the affinity and associativity attributes presented by the device tree or VPHN hcalls. Nodes that might be known to the pHyp were not 'possible' in the runtime kernel because they did not have memory at boot.

This patch ensures that sufficient nodes are defined to support configuration requirements after boot, as well as at boot. This patch set fixes a couple of problems.

* Nodes known to powerpc to be memoryless at boot, but to have CPUs in them are allowed to be 'possible' and 'online'. Memory allocations for those nodes are taken from another node that does have memory until and if memory is hot-added to the node. * Nodes which have no resources assigned at boot, but which may still be referenced subsequently by affinity or associativity attributes, are kept in the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs to the system can reference these nodes and bring them online instead of redirecting to one of the set of nodes that were known to have memory at boot.

This patch extracts the value of the lowest domain level (number of allocable resources) from the device tree property "ibm,max-associativity-domains" to use as the maximum number of nodes to setup as possibly available in the system. This new setting will override the instruction:

    nodes_and(node_possible_map, node_possible_map, node_online_map);

presently seen in the function arch/powerpc/mm/numa.c:initmem_init().

If the "ibm,max-associativity-domains" property is not present at boot, no operation will be performed to define or enable additional nodes, or enable the above 'nodes_and()'.

Signed-off-by Michael Bringmann <[email protected]>

Reviewed-by Nathan Fontenot <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/powerpc/mm/numa.c |   37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

arch/powerpc/mm/numa.c +34 -3

@@ -951,6 +951,34 @@ static void __init setup_node_data(int n
 	NODE_DATA(nid)->node_spanned_pages = spanned_pages;
 }
 
+static void __init find_possible_nodes(void)
+{
+	struct device_node *rtas;
+	u32 numnodes, i;
+
+	if (min_common_depth <= 0)
+		return;
+
+	rtas = of_find_node_by_path("/rtas");
+	if (!rtas)
+		return;
+
+	if (of_property_read_u32_index(rtas,
+				"ibm,max-associativity-domains",
+				min_common_depth, &numnodes))
+		goto out;
+
+	for (i = 0; i < numnodes; i++) {
+		if (!node_possible(i)) {
+			setup_node_data(i, 0, 0);
+			node_set(i, node_possible_map);
+		}
+	}
+
+out:
+	of_node_put(rtas);
+}
+
 void __init initmem_init(void)
 {
 	int nid, cpu;

@@ -966,12 +994,15 @@ void __init initmem_init(void)
 	memblock_dump_all();
 
 	/*
-	 * Reduce the possible NUMA nodes to the online NUMA nodes,
-	 * since we do not support node hotplug. This ensures that  we
-	 * lower the maximum NUMA node ID to what is actually present.
+	 * Modify the set of possible NUMA nodes to reflect information
+	 * available about the set of online nodes, and the set of nodes
+	 * that we expect to make use of for this platform's affinity
+	 * calculations.
 	 */
 	nodes_and(node_possible_map, node_possible_map, node_online_map);
 
+	find_possible_nodes();
+
 	for_each_online_node(nid) {
 		unsigned long start_pfn, end_pfn;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #54 lore raw

PATCH 43/268 powerpc/numa: Ensure nodes initialized for hotplug

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

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

From: Michael Bringmann <[email protected]>

[ Upstream commit ea05ba7c559c8e5a5946c3a94a2a266e9a6680a6 ]

This patch fixes some problems encountered at runtime with configurations that support memory-less nodes, or that hot-add CPUs into nodes that are memoryless during system execution after boot. The problems of interest include:

* Nodes which have no resources assigned at boot, but which may still be referenced subsequently by affinity or associativity attributes, are kept in the list of 'possible' nodes for powerpc. Hot-add of memory or CPUs to the system can reference these nodes and bring them online instead of redirecting the references to one of the set of nodes known to have memory at boot.

Note that this software operates under the context of CPU hotplug. We are not doing memory hotplug in this code, but rather updating the kernel's CPU topology (i.e. arch_update_cpu_topology / numa_update_cpu_topology). We are initializing a node that may be used by CPUs or memory before it can be referenced as invalid by a CPU hotplug operation. CPU hotplug operations are protected by a range of APIs including cpu_maps_update_begin/cpu_maps_update_done, cpus_read/write_lock / cpus_read/write_unlock, device locks, and more. Memory hotplug operations, including try_online_node, are protected by mem_hotplug_begin/mem_hotplug_done, device locks, and more. In the case of CPUs being hot-added to a previously memoryless node, the try_online_node operation occurs wholly within the CPU locks with no overlap. Using HMC hot-add/hot-remove operations, we have been able to add and remove CPUs to any possible node without failures. HMC operations involve a degree self-serialization, though.

Signed-off-by Michael Bringmann <[email protected]>

Reviewed-by Nathan Fontenot <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/powerpc/mm/numa.c |   47 +++++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 10 deletions(-)

arch/powerpc/mm/numa.c +37 ~~-10~~

@@ -551,7 +551,7 @@ static int numa_setup_cpu(unsigned long
 	nid = of_node_to_nid_single(cpu);
 
 out_present:
-	if (nid < 0 || !node_online(nid))
+	if (nid < 0 || !node_possible(nid))
 		nid = first_online_node;
 
 	map_cpu_to_node(lcpu, nid);

@@ -969,10 +969,8 @@ static void __init find_possible_nodes(v
 		goto out;
 
 	for (i = 0; i < numnodes; i++) {
-		if (!node_possible(i)) {
-			setup_node_data(i, 0, 0);
+		if (!node_possible(i))
 			node_set(i, node_possible_map);
-		}
 	}
 
 out:

@@ -1335,6 +1333,40 @@ static long vphn_get_associativity(unsig
 	return rc;
 }
 
+static inline int find_and_online_cpu_nid(int cpu)
+{
+	__be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
+	int new_nid;
+
+	/* Use associativity from first thread for all siblings */
+	vphn_get_associativity(cpu, associativity);
+	new_nid = associativity_to_nid(associativity);
+	if (new_nid < 0 || !node_possible(new_nid))
+		new_nid = first_online_node;
+
+	if (NODE_DATA(new_nid) == NULL) {
+#ifdef CONFIG_MEMORY_HOTPLUG
+		/*
+		 * Need to ensure that NODE_DATA is initialized for a node from
+		 * available memory (see memblock_alloc_try_nid). If unable to
+		 * init the node, then default to nearest node that has memory
+		 * installed.
+		 */
+		if (try_online_node(new_nid))
+			new_nid = first_online_node;
+#else
+		/*
+		 * Default to using the nearest node that has memory installed.
+		 * Otherwise, it would be necessary to patch the kernel MM code
+		 * to deal with more memoryless-node error conditions.
+		 */
+		new_nid = first_online_node;
+#endif
+	}
+
+	return new_nid;
+}
+
 /*
  * Update the CPU maps and sysfs entries for a single CPU when its NUMA
  * characteristics change. This function doesn't perform any locking and is

@@ -1400,7 +1432,6 @@ int arch_update_cpu_topology(void)
 {
 	unsigned int cpu, sibling, changed = 0;
 	struct topology_update_data *updates, *ud;
-	__be32 associativity[VPHN_ASSOC_BUFSIZE] = {0};
 	cpumask_t updated_cpus;
 	struct device *dev;
 	int weight, new_nid, i = 0;

@@ -1435,11 +1466,7 @@ int arch_update_cpu_topology(void)
 			continue;
 		}
 
-		/* Use associativity from first thread for all siblings */
-		vphn_get_associativity(cpu, associativity);
-		new_nid = associativity_to_nid(associativity);
-		if (new_nid < 0 || !node_online(new_nid))
-			new_nid = first_online_node;
+		new_nid = find_and_online_cpu_nid(cpu);
 
 		if (new_nid == numa_cpu_lookup_table[cpu]) {
 			cpumask_andnot(&cpu_associativity_changes_mask,

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #55 lore raw

PATCH 44/268 RDMA/mlx5: Avoid memory leak in case of XRCD dealloc failure

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

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

From: Leon Romanovsky <[email protected]>

[ Upstream commit b081808a66345ba725b77ecd8d759bee874cd937 ]

Failure in XRCD FW deallocation command leaves memory leaked and returns error to the user which he can't do anything about it.

This patch changes behavior to always free memory and always return success to the user.

Fixes e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")

Reviewed-by Majd Dibbiny <[email protected]>

Signed-off-by Leon Romanovsky <[email protected]>

Reviewed-by Yuval Shaia <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/infiniband/hw/mlx5/qp.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

drivers/infiniband/hw/mlx5/qp.c +1 -4

@@ -3161,12 +3161,9 @@ int mlx5_ib_dealloc_xrcd(struct ib_xrcd
 	int err;
 
 	err = mlx5_core_xrcd_dealloc(dev->mdev, xrcdn);
-	if (err) {
+	if (err)
 		mlx5_ib_warn(dev, "failed to dealloc xrcdn 0x%x\n", xrcdn);
-		return err;
-	}
 
 	kfree(xrcd);
-
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #56 lore raw

PATCH 45/268 ntb_transport: Fix bug with max_mw_size parameter

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

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

From: Logan Gunthorpe <[email protected]>

[ Upstream commit cbd27448faff4843ac4b66cc71445a10623ff48d ]

When using the max_mw_size parameter of ntb_transport to limit the size of the Memory windows, communication cannot be established and the queues freeze.

This is because the mw_size that's reported to the peer is correctly limited but the size used locally is not. So the MW is initialized with a buffer smaller than the window but the TX side is using the full window. This means the TX side will be writing to a region of the window that points nowhere.

This is easily fixed by applying the same limit to tx_size in ntb_transport_init_queue().

Fixes e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers")

Signed-off-by Logan Gunthorpe <[email protected]>

Acked-by Allen Hubbe <[email protected]>

Cc Dave Jiang <[email protected]>

Signed-off-by Jon Mason <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/ntb/ntb_transport.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/ntb/ntb_transport.c +3 -0

@@ -955,6 +955,9 @@ static int ntb_transport_init_queue(stru
 	mw_base = nt->mw_vec[mw_num].phys_addr;
 	mw_size = nt->mw_vec[mw_num].phys_size;
 
+	if (max_mw_size && mw_size > max_mw_size)
+		mw_size = max_mw_size;
+
 	tx_size = (unsigned int)mw_size / num_qps_mw;
 	qp_offset = tx_size * (qp_num / mw_count);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #57 lore raw

PATCH 46/268 ocfs2: return -EROFS to mount.ocfs2 if inode block is invalid

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

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

From: piaojun <[email protected]>

[ Upstream commit 025bcbde3634b2c9b316f227fed13ad6ad6817fb ]

If metadata is corrupted such as 'invalid inode block', we will get failed by calling 'mount()' and then set filesystem readonly as below:

ocfs2_mount

    ocfs2_initialize_super
      ocfs2_init_global_system_inodes
        ocfs2_iget
          ocfs2_read_locked_inode
            ocfs2_validate_inode_block
	      ocfs2_error
	        ocfs2_handle_error
	          ocfs2_set_ro_flag(osb, 0);  // set readonly

In this situation we need return -EROFS to 'mount.ocfs2', so that user can fix it by fsck. And then mount again. In addition, 'mount.ocfs2' should be updated correspondingly as it only return 1 for all errno. And I will post a patch for 'mount.ocfs2' too.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Jun Piao <[email protected]>

Reviewed-by Alex Chen <[email protected]>

Reviewed-by Joseph Qi <[email protected]>

Reviewed-by Changwei Ge <[email protected]>

Reviewed-by Gang He <[email protected]>

Cc Mark Fasheh <[email protected]>

Cc Joel Becker <[email protected]>

Cc Junxiao Bi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/ocfs2/super.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

fs/ocfs2/super.c +2 -3

@@ -477,9 +477,8 @@ static int ocfs2_init_global_system_inod
 		new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
 		if (!new) {
 			ocfs2_release_system_inodes(osb);
-			status = -EINVAL;
+			status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
 			mlog_errno(status);
-			/* FIXME: Should ERROR_RO_FS */
 			mlog(ML_ERROR, "Unable to load system inode %d, "
 			     "possibly corrupt fs?", i);
 			goto bail;

@@ -508,7 +507,7 @@ static int ocfs2_init_local_system_inode
 		new = ocfs2_get_system_file_inode(osb, i, osb->slot_num);
 		if (!new) {
 			ocfs2_release_system_inodes(osb);
-			status = -EINVAL;
+			status = ocfs2_is_soft_readonly(osb) ? -EROFS : -EINVAL;
 			mlog(ML_ERROR, "status=%d, sysfile=%d, slot=%d\n",
 			     status, i, osb->slot_num);
 			goto bail;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #58 lore raw

PATCH 47/268 ocfs2/acl: use ip_xattr_sem to protect getting extended attribute

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

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

From: piaojun <[email protected]>

[ Upstream commit 16c8d569f5704a84164f30ff01b29879f3438065 ]

The race between *set_acl and *get_acl will cause getting incomplete xattr data as below:

processA processB

ocfs2_set_acl
ocfs2_xattr_set
__ocfs2_xattr_set_handle

ocfs2_get_acl_nolock
ocfs2_xattr_get_nolock:

processB may get incomplete xattr data if processA hasn't set_acl done.

So we should use 'ip_xattr_sem' to protect getting extended attribute in ocfs2_get_acl_nolock(), as other processes could be changing it concurrently.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Jun Piao <[email protected]>

Reviewed-by Alex Chen <[email protected]>

Cc Mark Fasheh <[email protected]>

Cc Joel Becker <[email protected]>

Cc Junxiao Bi <[email protected]>

Cc Joseph Qi <[email protected]>

Cc Changwei Ge <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/ocfs2/acl.c   |    6 ++++++
 fs/ocfs2/xattr.c |    2 ++
 2 files changed, 8 insertions(+)

fs/ocfs2/acl.c +6 -0

@@ -314,7 +314,9 @@ struct posix_acl *ocfs2_iop_get_acl(stru
 		return ERR_PTR(ret);
 	}
 
+	down_read(&OCFS2_I(inode)->ip_xattr_sem);
 	acl = ocfs2_get_acl_nolock(inode, type, di_bh);
+	up_read(&OCFS2_I(inode)->ip_xattr_sem);
 
 	ocfs2_inode_unlock(inode, 0);
 	brelse(di_bh);

@@ -333,7 +335,9 @@ int ocfs2_acl_chmod(struct inode *inode,
 	if (!(osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL))
 		return 0;
 
+	down_read(&OCFS2_I(inode)->ip_xattr_sem);
 	acl = ocfs2_get_acl_nolock(inode, ACL_TYPE_ACCESS, bh);
+	up_read(&OCFS2_I(inode)->ip_xattr_sem);
 	if (IS_ERR(acl) || !acl)
 		return PTR_ERR(acl);
 	ret = __posix_acl_chmod(&acl, GFP_KERNEL, inode->i_mode);

@@ -364,8 +368,10 @@ int ocfs2_init_acl(handle_t *handle,
 
 	if (!S_ISLNK(inode->i_mode)) {
 		if (osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL) {
+			down_read(&OCFS2_I(dir)->ip_xattr_sem);
 			acl = ocfs2_get_acl_nolock(dir, ACL_TYPE_DEFAULT,
 						   dir_bh);
+			up_read(&OCFS2_I(dir)->ip_xattr_sem);
 			if (IS_ERR(acl))
 				return PTR_ERR(acl);
 		}

fs/ocfs2/xattr.c +2 -0

@@ -639,9 +639,11 @@ int ocfs2_calc_xattr_init(struct inode *
 						     si->value_len);
 
 	if (osb->s_mount_opt & OCFS2_MOUNT_POSIX_ACL) {
+		down_read(&OCFS2_I(dir)->ip_xattr_sem);
 		acl_len = ocfs2_xattr_get_nolock(dir, dir_bh,
 					OCFS2_XATTR_INDEX_POSIX_ACL_DEFAULT,
 					"", NULL, 0);
+		up_read(&OCFS2_I(dir)->ip_xattr_sem);
 		if (acl_len > 0) {
 			a_size = ocfs2_xattr_entry_real_size(0, acl_len);
 			if (S_ISDIR(mode))

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #59 lore raw

PATCH 48/268 ocfs2: return error when we attempt to access a dirty bh in jbd2

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

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

From: piaojun <[email protected]>

[ Upstream commit d984187e3a1ad7d12447a7ab2c43ce3717a2b5b3 ]

We should not reuse the dirty bh in jbd2 directly due to the following situation:

1. When removing extent rec, we will dirty the bhs of extent rec and truncate log at the same time, and hand them over to jbd2.

2. The bhs are submitted to jbd2 area successfully.

3. The write-back thread of device help flush the bhs to disk but encounter write error due to abnormal storage link.

4. After a while the storage link become normal. Truncate log flush worker triggered by the next space reclaiming found the dirty bh of truncate log and clear its 'BH_Write_EIO' and then set it uptodate in __ocfs2_journal_access():

ocfs2_truncate_log_worker
ocfs2_flush_truncate_log
__ocfs2_flush_truncate_log
ocfs2_replay_truncate_records
ocfs2_journal_access_di
__ocfs2_journal_access // here we clear io_error and set 'tl_bh' uptodata.

5. Then jbd2 will flush the bh of truncate log to disk, but the bh of extent rec is still in error state, and unfortunately nobody will take care of it.

6. At last the space of extent rec was not reduced, but truncate log flush worker have given it back to globalalloc. That will cause duplicate cluster problem which could be identified by fsck.ocfs2.

Sadly we can hardly revert this but set fs read-only in case of ruining atomicity and consistency of space reclaim.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes acf8fdbe6afb ("ocfs2: do not BUG if buffer not uptodate in __ocfs2_journal_access")

Signed-off-by Jun Piao <[email protected]>

Reviewed-by Yiwen Jiang <[email protected]>

Reviewed-by Changwei Ge <[email protected]>

Cc Mark Fasheh <[email protected]>

Cc Joel Becker <[email protected]>

Cc Junxiao Bi <[email protected]>

Cc Joseph Qi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/ocfs2/journal.c |   23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

fs/ocfs2/journal.c +12 ~~-11~~

@@ -666,23 +666,24 @@ static int __ocfs2_journal_access(handle
 	/* we can safely remove this assertion after testing. */
 	if (!buffer_uptodate(bh)) {
 		mlog(ML_ERROR, "giving me a buffer that's not uptodate!\n");
-		mlog(ML_ERROR, "b_blocknr=%llu\n",
-		     (unsigned long long)bh->b_blocknr);
+		mlog(ML_ERROR, "b_blocknr=%llu, b_state=0x%lx\n",
+		     (unsigned long long)bh->b_blocknr, bh->b_state);
 
 		lock_buffer(bh);
 		/*
-		 * A previous attempt to write this buffer head failed.
-		 * Nothing we can do but to retry the write and hope for
-		 * the best.
+		 * A previous transaction with a couple of buffer heads fail
+		 * to checkpoint, so all the bhs are marked as BH_Write_EIO.
+		 * For current transaction, the bh is just among those error
+		 * bhs which previous transaction handle. We can't just clear
+		 * its BH_Write_EIO and reuse directly, since other bhs are
+		 * not written to disk yet and that will cause metadata
+		 * inconsistency. So we should set fs read-only to avoid
+		 * further damage.
 		 */
 		if (buffer_write_io_error(bh) && !buffer_uptodate(bh)) {
-			clear_buffer_write_io_error(bh);
-			set_buffer_uptodate(bh);
-		}
-
-		if (!buffer_uptodate(bh)) {
 			unlock_buffer(bh);
-			return -EIO;
+			return ocfs2_error(osb->sb, "A previous attempt to "
+					"write this buffer head failed\n");
 		}
 		unlock_buffer(bh);
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:00 UTC #60 lore raw

PATCH 49/268 mm/mempolicy: fix the check of nodemask from user

[1] http://man7.org/linux/man-pages/man2/set_mempolicy.2.html
[2] http://man7.org/linux/man-pages/man2/mbind.2.html
[3] http://man7.org/linux/man-pages/man2/migrate_pages.2.html

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

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

From: Yisheng Xie <[email protected]>

[ Upstream commit 56521e7a02b7b84a5e72691a1fb15570e6055545 ]

As Xiaojun reported the ltp of migrate_pages01 will fail on arm64 system which has 4 nodes[0...3], all have memory and CONFIG_NODES_SHIFT=2:

  migrate_pages01    0  TINFO  :  test_invalid_nodes
  migrate_pages01   14  TFAIL  :  migrate_pages_common.c:45: unexpected failure - returned value = 0, expected: -1
  migrate_pages01   15  TFAIL  :  migrate_pages_common.c:55: call succeeded unexpectedly

In this case the test_invalid_nodes of migrate_pages01 will call:
SYSC_migrate_pages as:

migrate_pages(0, , {0x0000000000000001}, 64, , {0x0000000000000010}, 64) = 0

The new nodes specifies one or more node IDs that are greater than the maximum supported node ID, however, the errno is not set to EINVAL as expected.

As man pages of set_mempolicy[1], mbind[2], and migrate_pages[3] mentioned, when nodemask specifies one or more node IDs that are greater than the maximum supported node ID, the errno should set to EINVAL. However, get_nodes only check whether the part of bits [BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES), maxnode) is zero or not, and remain [MAX_NUMNODES, BITS_PER_LONG*BITS_TO_LONGS(MAX_NUMNODES) unchecked.

This patch is to check the bits of [MAX_NUMNODES, maxnode) in get_nodes to let migrate_pages set the errno to EINVAL when nodemask specifies one or more node IDs that are greater than the maximum supported node ID, which follows the manpage's guide.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Yisheng Xie <[email protected]>

Reported-by Tan Xiaojun <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

Cc Andi Kleen <[email protected]>

Cc Chris Salls <[email protected]>

Cc Christopher Lameter <[email protected]>

Cc David Rientjes <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Naoya Horiguchi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 mm/mempolicy.c |   23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

mm/mempolicy.c +20 -3

@@ -1232,6 +1232,7 @@ static int get_nodes(nodemask_t *nodes,
 		     unsigned long maxnode)
 {
 	unsigned long k;
+	unsigned long t;
 	unsigned long nlongs;
 	unsigned long endmask;

@@ -1248,13 +1249,19 @@ static int get_nodes(nodemask_t *nodes,
 	else
 		endmask = (1UL << (maxnode % BITS_PER_LONG)) - 1;
 
-	/* When the user specified more nodes than supported just check
-	   if the non supported part is all zero. */
+	/*
+	 * When the user specified more nodes than supported just check
+	 * if the non supported part is all zero.
+	 *
+	 * If maxnode have more longs than MAX_NUMNODES, check
+	 * the bits in that area first. And then go through to
+	 * check the rest bits which equal or bigger than MAX_NUMNODES.
+	 * Otherwise, just check bits [MAX_NUMNODES, maxnode).
+	 */
 	if (nlongs > BITS_TO_LONGS(MAX_NUMNODES)) {
 		if (nlongs > PAGE_SIZE/sizeof(long))
 			return -EINVAL;
 		for (k = BITS_TO_LONGS(MAX_NUMNODES); k < nlongs; k++) {
-			unsigned long t;
 			if (get_user(t, nmask + k))
 				return -EFAULT;
 			if (k == nlongs - 1) {

@@ -1267,6 +1274,16 @@ static int get_nodes(nodemask_t *nodes,
 		endmask = ~0UL;
 	}
 
+	if (maxnode > MAX_NUMNODES && MAX_NUMNODES % BITS_PER_LONG != 0) {
+		unsigned long valid_mask = endmask;
+
+		valid_mask &= ~((1UL << (MAX_NUMNODES % BITS_PER_LONG)) - 1);
+		if (get_user(t, nmask + nlongs - 1))
+			return -EFAULT;
+		if (t & valid_mask)
+			return -EINVAL;
+	}
+
 	if (copy_from_user(nodes_addr(*nodes), nmask, nlongs*sizeof(unsigned long)))
 		return -EFAULT;
 	nodes_addr(*nodes)[nlongs-1] &= endmask;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #61 lore raw

PATCH 50/268 mm/mempolicy: add nodes_empty check in SYSC_migrate_pages

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

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

From: Yisheng Xie <[email protected]>

[ Upstream commit 0486a38bcc4749808edbc848f1bcf232042770fc ]

As in manpage of migrate_pages, the errno should be set to EINVAL when none of the node IDs specified by new_nodes are on-line and allowed by the process's current cpuset context, or none of the specified nodes contain memory. However, when test by following case:

	new_nodes = 0;
	old_nodes = 0xf;
	ret = migrate_pages(pid, old_nodes, new_nodes, MAX);

The ret will be 0 and no errno is set. As the new_nodes is empty, we should expect EINVAL as documented.

To fix the case like above, this patch check whether target nodes AND current task_nodes is empty, and then check whether AND node_states[N_MEMORY] is empty.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Yisheng Xie <[email protected]>

Acked-by Vlastimil Babka <[email protected]>

Cc Andi Kleen <[email protected]>

Cc Chris Salls <[email protected]>

Cc Christopher Lameter <[email protected]>

Cc David Rientjes <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Naoya Horiguchi <[email protected]>

Cc Tan Xiaojun <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 mm/mempolicy.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

mm/mempolicy.c +7 -3

@@ -1410,10 +1410,14 @@ SYSCALL_DEFINE4(migrate_pages, pid_t, pi
 		goto out_put;
 	}
 
-	if (!nodes_subset(*new, node_states[N_MEMORY])) {
-		err = -EINVAL;
+	task_nodes = cpuset_mems_allowed(current);
+	nodes_and(*new, *new, task_nodes);
+	if (nodes_empty(*new))
+		goto out_put;
+
+	nodes_and(*new, *new, node_states[N_MEMORY]);
+	if (nodes_empty(*new))
 		goto out_put;
-	}
 
 	err = security_task_movememory(task);
 	if (err)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #62 lore raw

PATCH 51/268 asm-generic: provide generic_pmdp_establish()

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

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

From: "Kirill A. Shutemov" <[email protected]>

[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]

Patch series "Do not lose dirty bit on THP pages", v4.

Vlastimil noted that pmdp_invalidate() is not atomic and we can lose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at().

The bug can lead to data loss, but the race window is tiny and I haven't seen any reports that suggested that it happens in reality. So I don't think it worth sending it to stable.

Unfortunately, there's no way to address the issue in a generic way. We need to fix all architectures that support THP one-by-one.

All architectures that have THP supported have to provide atomic pmdp_invalidate() that returns previous value.

If generic implementation of pmdp_invalidate() is used, architecture needs to provide atomic pmdp_estabish().

pmdp_estabish() is not used out-side generic implementation of pmdp_invalidate() so far, but I think this can change in the future.

This patch (of 12):

This is an implementation of pmdp_establish() that is only suitable for an architecture that doesn't have hardware dirty/accessed bits. In this case we can't race with CPU which sets these bits and non-atomic approach is fine.

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Kirill A. Shutemov <[email protected]>

Cc Vlastimil Babka <[email protected]>

Cc Andrea Arcangeli <[email protected]>

Cc Michal Hocko <[email protected]>

Cc Aneesh Kumar K.V <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc David Daney <[email protected]>

Cc David Miller <[email protected]>

Cc H. Peter Anvin <[email protected]>

Cc Hugh Dickins <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Martin Schwidefsky <[email protected]>

Cc Nitin Gupta <[email protected]>

Cc Ralf Baechle <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Vineet Gupta <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 include/asm-generic/pgtable.h |   15 +++++++++++++++
 1 file changed, 15 insertions(+)

include/asm-generic/pgtable.h +15 -0

@@ -237,6 +237,21 @@ extern void pgtable_trans_huge_deposit(s
 extern pgtable_t pgtable_trans_huge_withdraw(struct mm_struct *mm, pmd_t *pmdp);
 #endif
 
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+/*
+ * This is an implementation of pmdp_establish() that is only suitable for an
+ * architecture that doesn't have hardware dirty/accessed bits. In this case we
+ * can't race with CPU which sets these bits and non-atomic aproach is fine.
+ */
+static inline pmd_t generic_pmdp_establish(struct vm_area_struct *vma,
+		unsigned long address, pmd_t *pmdp, pmd_t pmd)
+{
+	pmd_t old_pmd = *pmdp;
+	set_pmd_at(vma->vm_mm, address, pmdp, pmd);
+	return old_pmd;
+}
+#endif
+
 #ifndef __HAVE_ARCH_PMDP_INVALIDATE
 extern void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
 			    pmd_t *pmdp);

Ben Hutchings

2018-06-11 12:55 UTC #63 lore raw

Re: [PATCH 4.4 051/268] asm-generic: provide generic_pmdp_establish()

Quoted 17 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Kirill A. Shutemov" <[email protected]>
[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]
Patch series "Do not lose dirty bit on THP pages", v4.
Vlastimil noted that pmdp_invalidate() is not atomic and we can lose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at().
The bug can lead to data loss, but the race window is tiny and I haven't seen any reports that suggested that it happens in reality. So I don't think it worth sending it to stable.

[...]

Quoted 6 lines

This patch (of 12):
This is an implementation of pmdp_establish() that is only suitable for an architecture that doesn't have hardware dirty/accessed bits. In this case we can't race with CPU which sets these bits and non-atomic approach is fine.

[...]

There's no point in applying just this patch, since it adds a new function that nothing will call.

I tend to think that since this is fixing a potential data loss, the whole series should be backported. But the commit message here says it shouldn't.

Ben.

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Greg Kroah-Hartman

author maintainer

2018-06-12 18:49 UTC #64 lore raw

Re: [PATCH 4.4 051/268] asm-generic: provide generic_pmdp_establish()

Quoted 25 lines · Ben Hutchings

Quoted 17 lines · Greg Kroah-Hartman
4.4-stable review patch.ï¿½ï¿½If anyone has any objections, please let me know.
------------------
From: "Kirill A. Shutemov" <[email protected]>
[ Upstream commit c58f0bb77ed8bf93dfdde762b01cb67eebbdfc29 ]
Patch series "Do not lose dirty bit on THP pages", v4.
Vlastimil noted that pmdp_invalidate() is not atomic and we can lose dirty and access bits if CPU sets them after pmdp dereference, but before set_pmd_at().
The bug can lead to data loss, but the race window is tiny and I haven't seen any reports that suggested that it happens in reality.ï¿½ï¿½So I don't think it worth sending it to stable.
[...]
Quoted 6 lines
This patch (of 12):
This is an implementation of pmdp_establish() that is only suitable for an architecture that doesn't have hardware dirty/accessed bits.ï¿½ï¿½In this case we can't race with CPU which sets these bits and non-atomic approach is fine.

Quoted 8 lines

[...]
There's no point in applying just this patch, since it adds a new function that nothing will call.
I tend to think that since this is fixing a potential data loss, the whole series should be backported. But the commit message here says it shouldn't.

Hm, I thought there was some reason for this patch, as I thought it came up before. Sasha do you remember? Should I just revert it?

thanks,

greg k-h

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #65 lore raw

PATCH 52/268 mm: pin address_space before dereferencing it while isolating an LRU page

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

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

From: Mel Gorman <[email protected]>

[ Upstream commit 69d763fc6d3aee787a3e8c8c35092b4f4960fa5d ]

Minchan Kim asked the following question -- what locks protects address_space destroying when race happens between inode trauncation and __isolate_lru_page? Jan Kara clarified by describing the race as follows

CPU1 CPU2

truncate(inode) __isolate_lru_page()
...

  truncate_inode_page(mapping, page);
    delete_from_page_cache(page)
      spin_lock_irqsave(&mapping->tree_lock, flags);
        __delete_from_page_cache(page, NULL)
          page_cache_tree_delete(..)
            ...                                   mapping = page_mapping(page);
            page->mapping = NULL;
            ...
      spin_unlock_irqrestore(&mapping->tree_lock, flags);
      page_cache_free_page(mapping, page)
        put_page(page)
          if (put_page_testzero(page)) -> false

- inode now has no pages and can be freed including embedded address_space

                                                  if (mapping && !mapping->a_ops->migratepage)

- we've dereferenced mapping which is potentially already free.

The race is theoretically possible but unlikely. Before the delete_from_page_cache, truncate_cleanup_page is called so the page is likely to be !PageDirty or PageWriteback which gets skipped by the only caller that checks the mappping in __isolate_lru_page. Even if the race occurs, a substantial amount of work has to happen during a tiny window with no preemption but it could potentially be done using a virtual machine to artifically slow one CPU or halt it during the critical window.

This patch should eliminate the race with truncation by try-locking the page before derefencing mapping and aborting if the lock was not acquired. There was a suggestion from Huang Ying to use RCU as a side-effect to prevent mapping being freed. However, I do not like the solution as it's an unconventional means of preserving a mapping and it's not a context where rcu_read_lock is obviously protecting rcu data.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware again")

Signed-off-by Mel Gorman <[email protected]>

Acked-by Minchan Kim <[email protected]>

Cc "Huang, Ying" <[email protected]>

Cc Jan Kara <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 mm/vmscan.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

mm/vmscan.c +12 -2

@@ -1312,6 +1312,7 @@ int __isolate_lru_page(struct page *page
 
 		if (PageDirty(page)) {
 			struct address_space *mapping;
+			bool migrate_dirty;
 
 			/* ISOLATE_CLEAN means only clean pages */
 			if (mode & ISOLATE_CLEAN)

@@ -1320,10 +1321,19 @@ int __isolate_lru_page(struct page *page
 			/*
 			 * Only pages without mappings or that have a
 			 * ->migratepage callback are possible to migrate
-			 * without blocking
+			 * without blocking. However, we can be racing with
+			 * truncation so it's necessary to lock the page
+			 * to stabilise the mapping as truncation holds
+			 * the page lock until after the page is removed
+			 * from the page cache.
 			 */
+			if (!trylock_page(page))
+				return ret;
+
 			mapping = page_mapping(page);
-			if (mapping && !mapping->a_ops->migratepage)
+			migrate_dirty = mapping && mapping->a_ops->migratepage;
+			unlock_page(page);
+			if (!migrate_dirty)
 				return ret;
 		}
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #66 lore raw

PATCH 53/268 IB/ipoib: Fix for potential no-carrier state

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

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

From: Alex Estrin <[email protected]>

[ Upstream commit 1029361084d18cc270f64dfd39529fafa10cfe01 ]

On reboot SM can program port pkey table before ipoib registered its event handler, which could result in missing pkey event and leave root interface with initial pkey value from index 0.

Since OPA port starts with invalid pkey in index 0, root interface will fail to initialize and stay down with no-carrier flag.

For IB ipoib interface may end up with pkey different from value opensm put in pkey table idx 0, resulting in connectivity issues (different mcast groups, for example).

Close the window by calling event handler after registration to make sure ipoib pkey is in sync with port pkey table.

Reviewed-by Mike Marciniszyn <[email protected]>

Reviewed-by Ira Weiny <[email protected]>

Signed-off-by Alex Estrin <[email protected]>

Signed-off-by Dennis Dalessandro <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/infiniband/ulp/ipoib/ipoib_main.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/infiniband/ulp/ipoib/ipoib_main.c +3 -0

@@ -1953,6 +1953,9 @@ static struct net_device *ipoib_add_port
 		goto event_failed;
 	}
 
+	/* call event handler to ensure pkey in sync */
+	queue_work(ipoib_workqueue, &priv->flush_heavy);
+
 	result = register_netdev(priv->dev);
 	if (result) {
 		printk(KERN_WARNING "%s: couldn't register ipoib port %d; error %d\n",

Greg Kroah-Hartman

author maintainer

2018-05-28 10:00 UTC #67 lore raw

PATCH 54/268 x86/power: Fix swsusp_arch_resume prototype

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 328008a72d38b5bde6491e463405c34a81a65d3e ]

The declaration for swsusp_arch_resume marks it as 'asmlinkage', but the definition in x86-32 does not, and it fails to include the header with the declaration. This leads to a warning when building with link-time-optimizations:

kernel/power/power.h:108:23: error: type of 'swsusp_arch_resume' does not match original declaration [-Werror=lto-type-mismatch]

 extern asmlinkage int swsusp_arch_resume(void);
                       ^

arch/x86/power/hibernate_32.c:148:0: note: 'swsusp_arch_resume' was previously declared here
int swsusp_arch_resume(void)

This moves the declaration into a globally visible header file and fixes up both x86 definitions to match it.

Signed-off-by Thomas Gleixner <[email protected]>

Cc Len Brown <[email protected]>

Cc Andi Kleen <[email protected]>

Cc Nicolas Pitre <[email protected]>

Cc "Rafael J. Wysocki" <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Bart Van Assche <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/x86/power/hibernate_32.c |    2 +-
 arch/x86/power/hibernate_64.c |    2 +-
 include/linux/suspend.h       |    2 ++
 kernel/power/power.h          |    3 ---
 4 files changed, 4 insertions(+), 5 deletions(-)

arch/x86/power/hibernate_32.c +1 -1

@@ -142,7 +142,7 @@ static inline void resume_init_first_lev
 #endif
 }
 
-int swsusp_arch_resume(void)
+asmlinkage int swsusp_arch_resume(void)
 {
 	int error;

arch/x86/power/hibernate_64.c +1 -1

@@ -78,7 +78,7 @@ static int set_up_temporary_mappings(voi
 	return 0;
 }
 
-int swsusp_arch_resume(void)
+asmlinkage int swsusp_arch_resume(void)
 {
 	int error;

include/linux/suspend.h +2 -0

@@ -377,6 +377,8 @@ extern int swsusp_page_is_forbidden(stru
 extern void swsusp_set_page_free(struct page *);
 extern void swsusp_unset_page_free(struct page *);
 extern unsigned long get_safe_page(gfp_t gfp_mask);
+extern asmlinkage int swsusp_arch_suspend(void);
+extern asmlinkage int swsusp_arch_resume(void);
 
 extern void hibernation_set_ops(const struct platform_hibernation_ops *ops);
 extern int hibernate(void);

kernel/power/power.h +0 -3

@@ -85,9 +85,6 @@ extern int in_suspend;
 extern dev_t swsusp_resume_device;
 extern sector_t swsusp_resume_block;
 
-extern asmlinkage int swsusp_arch_suspend(void);
-extern asmlinkage int swsusp_arch_resume(void);
-
 extern int create_basic_memory_bitmaps(void);
 extern void free_basic_memory_bitmaps(void);
 extern int hibernate_preallocate_memory(void);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #68 lore raw

PATCH 55/268 firmware: dmi_scan: Fix handling of empty DMI strings

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

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

From: Jean Delvare <[email protected]>

[ Upstream commit a7770ae194569e96a93c48aceb304edded9cc648 ]

The handling of empty DMI strings looks quite broken to me:
* Strings from 1 to 7 spaces are not considered empty.
* True empty DMI strings (string index set to 0) are not considered empty, and result in allocating a 0-char string.
* Strings with invalid index also result in allocating a 0-char string.
* Strings starting with 8 spaces are all considered empty, even if non-space characters follow (sounds like a weird thing to do, but I have actually seen occurrences of this in DMI tables before.)
* Strings which are considered empty are reported as 8 spaces, instead of being actually empty.

Some of these issues are the result of an off-by-one error in memcmp, the rest is incorrect by design.

So let's get it square: missing strings and strings made of only spaces, regardless of their length, should be treated as empty and no memory should be allocated for them. All other strings are non-empty and should be allocated.

Signed-off-by Jean Delvare <[email protected]>

Fixes 79da4721117f ("x86: fix DMI out of memory problems")

Cc Parag Warudkar <[email protected]>

Cc Ingo Molnar <[email protected]>

Cc Thomas Gleixner <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/firmware/dmi_scan.c |   22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

drivers/firmware/dmi_scan.c +9 ~~-13~~

@@ -18,7 +18,7 @@ EXPORT_SYMBOL_GPL(dmi_kobj);
  * of and an antecedent to, SMBIOS, which stands for System
  * Management BIOS.  See further: http://www.dmtf.org/standards
  */
-static const char dmi_empty_string[] = "        ";
+static const char dmi_empty_string[] = "";
 
 static u32 dmi_ver __initdata;
 static u32 dmi_len;

@@ -44,25 +44,21 @@ static int dmi_memdev_nr;
 static const char * __init dmi_string_nosave(const struct dmi_header *dm, u8 s)
 {
 	const u8 *bp = ((u8 *) dm) + dm->length;
+	const u8 *nsp;
 
 	if (s) {
-		s--;
-		while (s > 0 && *bp) {
+		while (--s > 0 && *bp)
 			bp += strlen(bp) + 1;
-			s--;
-		}
 
-		if (*bp != 0) {
-			size_t len = strlen(bp)+1;
-			size_t cmp_len = len > 8 ? 8 : len;
-
-			if (!memcmp(bp, dmi_empty_string, cmp_len))
-				return dmi_empty_string;
+		/* Strings containing only spaces are considered empty */
+		nsp = bp;
+		while (*nsp == ' ')
+			nsp++;
+		if (*nsp != '\0')
 			return bp;
-		}
 	}
 
-	return "";
+	return dmi_empty_string;
 }
 
 static const char * __init dmi_string(const struct dmi_header *dm, u8 s)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #69 lore raw

PATCH 56/268 ACPI: processor_perflib: Do not send _PPC change notification if not ready

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

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

From: Chen Yu <[email protected]>

[ Upstream commit ba1edb9a5125a617d612f98eead14b9b84e75c3a ]

The following warning was triggered after resumed from S3 - if all the nonboot CPUs were put offline before suspend:

[ 1840.329515] unchecked MSR access error: RDMSR from 0x771 at rIP: 0xffffffff86061e3a (native_read_msr+0xa/0x30)
[ 1840.329516] Call Trace:
[ 1840.329521]  __rdmsr_on_cpu+0x33/0x50
[ 1840.329525]  generic_exec_single+0x81/0xb0
[ 1840.329527]  smp_call_function_single+0xd2/0x100
[ 1840.329530]  ? acpi_ds_result_pop+0xdd/0xf2
[ 1840.329532]  ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329534]  rdmsrl_on_cpu+0x57/0x80
[ 1840.329536]  ? cpumask_next+0x1b/0x20
[ 1840.329538]  ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329541]  intel_pstate_update_perf_limits+0xf3/0x220
[ 1840.329544]  ? notifier_call_chain+0x4a/0x70
[ 1840.329546]  intel_pstate_set_policy+0x4e/0x150
[ 1840.329548]  cpufreq_set_policy+0xcd/0x2f0
[ 1840.329550]  cpufreq_update_policy+0xb2/0x130
[ 1840.329552]  ? cpufreq_update_policy+0x130/0x130
[ 1840.329556]  acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329558]  acpi_processor_notify+0x80/0x100
[ 1840.329561]  acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329563]  acpi_os_execute_deferred+0x14/0x20
[ 1840.329565]  process_one_work+0x193/0x3c0
[ 1840.329567]  worker_thread+0x35/0x3b0
[ 1840.329569]  kthread+0x125/0x140
[ 1840.329571]  ? process_one_work+0x3c0/0x3c0
[ 1840.329572]  ? kthread_park+0x60/0x60
[ 1840.329575]  ? do_syscall_64+0x67/0x180
[ 1840.329577]  ret_from_fork+0x25/0x30
[ 1840.329585] unchecked MSR access error: WRMSR to 0x774 (tried to write 0x0000000000000000) at rIP: 0xffffffff86061f78 (native_write_msr+0x8/0x30)
[ 1840.329586] Call Trace:
[ 1840.329587]  __wrmsr_on_cpu+0x37/0x40
[ 1840.329589]  generic_exec_single+0x81/0xb0
[ 1840.329592]  smp_call_function_single+0xd2/0x100
[ 1840.329594]  ? acpi_ds_create_operand+0x215/0x23c
[ 1840.329595]  ? cpumask_next+0x1b/0x20
[ 1840.329597]  wrmsrl_on_cpu+0x57/0x70
[ 1840.329598]  ? rdmsrl_on_cpu+0x57/0x80
[ 1840.329599]  ? wrmsrl_on_cpu+0x57/0x70
[ 1840.329602]  intel_pstate_hwp_set+0xd3/0x150
[ 1840.329604]  intel_pstate_set_policy+0x119/0x150
[ 1840.329606]  cpufreq_set_policy+0xcd/0x2f0
[ 1840.329607]  cpufreq_update_policy+0xb2/0x130
[ 1840.329610]  ? cpufreq_update_policy+0x130/0x130
[ 1840.329613]  acpi_processor_ppc_has_changed+0x65/0x80
[ 1840.329615]  acpi_processor_notify+0x80/0x100
[ 1840.329617]  acpi_ev_notify_dispatch+0x44/0x5c
[ 1840.329619]  acpi_os_execute_deferred+0x14/0x20
[ 1840.329620]  process_one_work+0x193/0x3c0
[ 1840.329622]  worker_thread+0x35/0x3b0
[ 1840.329624]  kthread+0x125/0x140
[ 1840.329625]  ? process_one_work+0x3c0/0x3c0
[ 1840.329626]  ? kthread_park+0x60/0x60
[ 1840.329628]  ? do_syscall_64+0x67/0x180
[ 1840.329631]  ret_from_fork+0x25/0x30

This is because if there's only one online CPU, the MSR_PM_ENABLE (package wide)can not be enabled after resumed, due to intel_pstate_hwp_enable() will only be invoked on AP's online process after resumed - if there's no AP online, the HWP remains disabled after resumed (BIOS has disabled it in S3). Then if there comes a _PPC change notification which touches HWP register during this stage, the warning is triggered.

Since we don't call acpi_processor_register_performance() when HWP is enabled, the pr->performance will be NULL. When this is NULL we don't need to do _PPC change notification.

Reported-by Doug Smythies <[email protected]>

Signed-off-by Yu Chen <[email protected]>

Signed-off-by Rafael J. Wysocki <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

drivers/acpi/processor_perflib.c +1 -1

@@ -161,7 +161,7 @@ int acpi_processor_ppc_has_changed(struc
 {
 	int ret;
 
-	if (ignore_ppc) {
+	if (ignore_ppc || !pr->performance) {
 		/*
 		 * Only when it is notification event, the _OST object
 		 * will be evaluated. Otherwise it is skipped.

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #70 lore raw

PATCH 57/268 bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y

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

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

From: Yonghong Song <[email protected]>

[ Upstream commit 09584b406742413ac4c8d7e030374d4daa045b69 ]

With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file, tools/testing/selftests/bpf/test_kmod.sh failed like below:
[root@localhost bpf]# ./test_kmod.sh
sysctl: setting key "net.core.bpf_jit_enable": Invalid argument [ JIT enabled:0 hardened:0 ]

  [  132.175681] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
  [  132.458834] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
  [ JIT enabled:1 hardened:0 ]
  [  133.456025] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
  [  133.730935] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
  [ JIT enabled:1 hardened:1 ]
  [  134.769730] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
  [  135.050864] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
  [ JIT enabled:1 hardened:2 ]
  [  136.442882] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096
  [  136.821810] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed]
  [root@localhost bpf]#

The test_kmod.sh load/remove test_bpf.ko multiple times with different settings for sysctl net.core.bpf_jit_{enable,harden}. The failed test #297 of test_bpf.ko is designed such that JIT always fails.

Commit 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config) introduced the following tightening logic:

    ...
        if (!bpf_prog_is_dev_bound(fp->aux)) {
                fp = bpf_int_jit_compile(fp);
    #ifdef CONFIG_BPF_JIT_ALWAYS_ON
                if (!fp->jited) {
                        *err = -ENOTSUPP;
                        return fp;
                }
    #endif
    ...

With this logic, Test #297 always gets return value -ENOTSUPP when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure.

This patch fixed the failure by marking Test #297 as expected failure when CONFIG_BPF_JIT_ALWAYS_ON is defined.

Fixes 290af86629b2 (bpf: introduce BPF_JIT_ALWAYS_ON config)

Signed-off-by Yonghong Song <[email protected]>

Signed-off-by Daniel Borkmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 lib/test_bpf.c |   31 ++++++++++++++++++++++++++-----
 1 file changed, 26 insertions(+), 5 deletions(-)

lib/test_bpf.c +26 -5

@@ -83,6 +83,7 @@ struct bpf_test {
 		__u32 result;
 	} test[MAX_SUBTESTS];
 	int (*fill_helper)(struct bpf_test *self);
+	int expected_errcode; /* used when FLAG_EXPECTED_FAIL is set in the aux */
 	__u8 frag_data[MAX_DATA];
 };

@@ -1780,7 +1781,9 @@ static struct bpf_test tests[] = {
 		},
 		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
 		{ },
-		{ }
+		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{
 		"check: div_k_0",

@@ -1790,7 +1793,9 @@ static struct bpf_test tests[] = {
 		},
 		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
 		{ },
-		{ }
+		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{
 		"check: unknown insn",

@@ -1801,7 +1806,9 @@ static struct bpf_test tests[] = {
 		},
 		CLASSIC | FLAG_EXPECTED_FAIL,
 		{ },
-		{ }
+		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{
 		"check: out of range spill/fill",

@@ -1811,7 +1818,9 @@ static struct bpf_test tests[] = {
 		},
 		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
 		{ },
-		{ }
+		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{
 		"JUMPS + HOLES",

@@ -1903,6 +1912,8 @@ static struct bpf_test tests[] = {
 		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
 		{ },
 		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{
 		"check: LDX + RET X",

@@ -1913,6 +1924,8 @@ static struct bpf_test tests[] = {
 		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
 		{ },
 		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{	/* Mainly checking JIT here. */
 		"M[]: alt STX + LDX",

@@ -2087,6 +2100,8 @@ static struct bpf_test tests[] = {
 		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
 		{ },
 		{ },
+		.fill_helper = NULL,
+		.expected_errcode = -EINVAL,
 	},
 	{	/* Passes checker but fails during runtime. */
 		"LD [SKF_AD_OFF-1]",

@@ -4462,6 +4477,7 @@ static struct bpf_test tests[] = {
 		{ },
 		{ },
 		.fill_helper = bpf_fill_maxinsns4,
+		.expected_errcode = -EINVAL,
 	},
 	{	/* Mainly checking JIT here. */
 		"BPF_MAXINSNS: Very long jump",

@@ -4517,10 +4533,15 @@ static struct bpf_test tests[] = {
 	{
 		"BPF_MAXINSNS: Jump, gap, jump, ...",
 		{ },
+#ifdef CONFIG_BPF_JIT_ALWAYS_ON
+		CLASSIC | FLAG_NO_DATA | FLAG_EXPECTED_FAIL,
+#else
 		CLASSIC | FLAG_NO_DATA,
+#endif
 		{ },
 		{ { 0, 0xababcbac } },
 		.fill_helper = bpf_fill_maxinsns11,
+		.expected_errcode = -ENOTSUPP,
 	},
 	{
 		"BPF_MAXINSNS: ld_abs+get_processor_id",

@@ -5290,7 +5311,7 @@ static struct bpf_prog *generate_filter(
 
 		*err = bpf_prog_create(&fp, &fprog);
 		if (tests[which].aux & FLAG_EXPECTED_FAIL) {
-			if (*err == -EINVAL) {
+			if (*err == tests[which].expected_errcode) {
 				pr_cont("PASS\n");
 				/* Verifier rejected filter as expected. */
 				*err = 0;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #71 lore raw

PATCH 58/268 MIPS: TXx9: use IS_BUILTIN() for CONFIG_LEDS_CLASS

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

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

From: Matt Redfearn <[email protected]>

[ Upstream commit 0cde5b44a30f1daaef1c34e08191239dc63271c4 ]

When commit b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support") added board support for the RBTX4939, it added a call to led_classdev_register even if the LED class is built as a module. Built-in arch code cannot call module code directly like this. Commit b33b44073734 ("MIPS: TXX9: use IS_ENABLED() macro") subsequently changed the inclusion of this code to a single check that CONFIG_LEDS_CLASS is either builtin or a module, but the same issue remains.

This leads to MIPS allmodconfig builds failing when CONFIG_MACH_TX49XX=y is set:

arch/mips/txx9/rbtx4939/setup.o: In function `rbtx4939_led_probe':
setup.c:(.init.text+0xc0): undefined reference to `of_led_classdev_register'
make: *** [Makefile:999: vmlinux] Error 1

Fix this by using the IS_BUILTIN() macro instead.

Fixes b27311e1cace ("MIPS: TXx9: Add RBTX4939 board support")

Signed-off-by Matt Redfearn <[email protected]>

Reviewed-by James Hogan <[email protected]>

Cc Ralf Baechle <[email protected]>

Patchwork: https://patchwork.linux-mips.org/patch/18544/

Signed-off-by James Hogan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/mips/txx9/rbtx4939/setup.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/mips/txx9/rbtx4939/setup.c +2 -2

@@ -186,7 +186,7 @@ static void __init rbtx4939_update_ioc_p
 
 #define RBTX4939_MAX_7SEGLEDS	8
 
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
 static u8 led_val[RBTX4939_MAX_7SEGLEDS];
 struct rbtx4939_led_data {
 	struct led_classdev cdev;

@@ -261,7 +261,7 @@ static inline void rbtx4939_led_setup(vo
 
 static void __rbtx4939_7segled_putc(unsigned int pos, unsigned char val)
 {
-#if IS_ENABLED(CONFIG_LEDS_CLASS)
+#if IS_BUILTIN(CONFIG_LEDS_CLASS)
 	unsigned long flags;
 	local_irq_save(flags);
 	/* bit7: reserved for LED class */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #72 lore raw

PATCH 59/268 xen-netfront: Fix race between device setup and open

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

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

From: Ross Lagerwall <[email protected]>

[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]

When a netfront device is set up it registers a netdev fairly early on, before it has set up the queues and is actually usable. A userspace tool like NetworkManager will immediately try to open it and access its state as soon as it appears. The bug can be reproduced by hotplugging VIFs until the VM runs out of grant refs. It registers the netdev but fails to set up any queues (since there are no more grant refs). In the meantime, NetworkManager opens the device and the kernel crashes trying to access the queues (of which there are none).

Fix this in two ways:
* For initial setup, register the netdev much later, after the queues are setup. This avoids the race entirely.
* During a suspend/resume cycle, the frontend reconnects to the backend and the queues are recreated. It is possible (though highly unlikely) to race with something opening the device and accessing the queues after they have been destroyed but before they have been recreated. Extend the region covered by the rtnl semaphore to protect against this race. There is a possibility that we fail to recreate the queues so check for this in the open function.

Signed-off-by Ross Lagerwall <[email protected]>

Reviewed-by Boris Ostrovsky <[email protected]>

Signed-off-by Juergen Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/xen-netfront.c |   46 +++++++++++++++++++++++----------------------
 1 file changed, 24 insertions(+), 22 deletions(-)

drivers/net/xen-netfront.c +24 ~~-22~~

@@ -342,6 +342,9 @@ static int xennet_open(struct net_device
 	unsigned int i = 0;
 	struct netfront_queue *queue = NULL;
 
+	if (!np->queues)
+		return -ENODEV;
+
 	for (i = 0; i < num_queues; ++i) {
 		queue = &np->queues[i];
 		napi_enable(&queue->napi);

@@ -1363,18 +1366,8 @@ static int netfront_probe(struct xenbus_
 #ifdef CONFIG_SYSFS
 	info->netdev->sysfs_groups[0] = &xennet_dev_group;
 #endif
-	err = register_netdev(info->netdev);
-	if (err) {
-		pr_warn("%s: register_netdev err=%d\n", __func__, err);
-		goto fail;
-	}
 
 	return 0;
-
- fail:
-	xennet_free_netdev(netdev);
-	dev_set_drvdata(&dev->dev, NULL);
-	return err;
 }
 
 static void xennet_end_access(int ref, void *page)

@@ -1743,8 +1736,6 @@ static void xennet_destroy_queues(struct
 {
 	unsigned int i;
 
-	rtnl_lock();
-
 	for (i = 0; i < info->netdev->real_num_tx_queues; i++) {
 		struct netfront_queue *queue = &info->queues[i];

@@ -1753,8 +1744,6 @@ static void xennet_destroy_queues(struct
 		netif_napi_del(&queue->napi);
 	}
 
-	rtnl_unlock();
-
 	kfree(info->queues);
 	info->queues = NULL;
 }

@@ -1770,8 +1759,6 @@ static int xennet_create_queues(struct n
 	if (!info->queues)
 		return -ENOMEM;
 
-	rtnl_lock();
-
 	for (i = 0; i < *num_queues; i++) {
 		struct netfront_queue *queue = &info->queues[i];

@@ -1780,7 +1767,7 @@ static int xennet_create_queues(struct n
 
 		ret = xennet_init_queue(queue);
 		if (ret < 0) {
-			dev_warn(&info->netdev->dev,
+			dev_warn(&info->xbdev->dev,
 				 "only created %d queues\n", i);
 			*num_queues = i;
 			break;

@@ -1794,10 +1781,8 @@ static int xennet_create_queues(struct n
 
 	netif_set_real_num_tx_queues(info->netdev, *num_queues);
 
-	rtnl_unlock();
-
 	if (*num_queues == 0) {
-		dev_err(&info->netdev->dev, "no queues\n");
+		dev_err(&info->xbdev->dev, "no queues\n");
 		return -EINVAL;
 	}
 	return 0;

@@ -1839,6 +1824,7 @@ static int talk_to_netback(struct xenbus
 		goto out;
 	}
 
+	rtnl_lock();
 	if (info->queues)
 		xennet_destroy_queues(info);

@@ -1849,6 +1835,7 @@ static int talk_to_netback(struct xenbus
 		info->queues = NULL;
 		goto out;
 	}
+	rtnl_unlock();
 
 	/* Create shared ring, alloc event channel -- for each queue */
 	for (i = 0; i < num_queues; ++i) {

@@ -1945,8 +1932,10 @@ abort_transaction_no_dev_fatal:
 	xenbus_transaction_end(xbt, 1);
  destroy_ring:
 	xennet_disconnect_backend(info);
+	rtnl_lock();
 	xennet_destroy_queues(info);
  out:
+	rtnl_unlock();
 	device_unregister(&dev->dev);
 	return err;
 }

@@ -1982,6 +1971,15 @@ static int xennet_connect(struct net_dev
 	netdev_update_features(dev);
 	rtnl_unlock();
 
+	if (dev->reg_state == NETREG_UNINITIALIZED) {
+		err = register_netdev(dev);
+		if (err) {
+			pr_warn("%s: register_netdev err=%d\n", __func__, err);
+			device_unregister(&np->xbdev->dev);
+			return err;
+		}
+	}
+
 	/*
 	 * All public and private state should now be sane.  Get
 	 * ready to start sending and receiving packets and give the driver

@@ -2172,10 +2170,14 @@ static int xennet_remove(struct xenbus_d
 
 	xennet_disconnect_backend(info);
 
-	unregister_netdev(info->netdev);
+	if (info->netdev->reg_state == NETREG_REGISTERED)
+		unregister_netdev(info->netdev);
 
-	if (info->queues)
+	if (info->queues) {
+		rtnl_lock();
 		xennet_destroy_queues(info);
+		rtnl_unlock();
+	}
 	xennet_free_netdev(info->netdev);
 
 	return 0;

Ben Hutchings

2018-06-11 14:29 UTC #73 lore raw

Re: [PATCH 4.4 059/268] xen-netfront: Fix race between device setup and open

Quoted 7 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ross Lagerwall <[email protected]>
[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]

[...]

Quoted 2 lines

drivers/net/xen-netfront.c +0 -0

[...]

drivers/net/xen-netfront.c static int talk_to_netback(struct xenbus · line 1824

Quoted 2 lines

drivers/net/xen-netfront.c +0 -0

@@ -1839,6 +1824,7 @@ static int talk_to_netback(struct xenbus
  		goto out;

This "goto out" is outside the locked section...

Quoted 21 lines

drivers/net/xen-netfront.c +0 -0
  	}
drivers/net/xen-netfront.c +1 -0
+	rtnl_lock();
if (info->queues)
xennet_destroy_queues(info);
drivers/net/xen-netfront.c +1 -0
@@ -1849,6 +1835,7 @@ static int talk_to_netback(struct xenbus
  		info->queues = NULL;
  		goto out;
  	}
+	rtnl_unlock();
/* Create shared ring, alloc event channel -- for each queue */ for (i = 0; i < num_queues; ++i) {
drivers/net/xen-netfront.c +0 -0
@@ -1945,8 +1932,10 @@ abort_transaction_no_dev_fatal:
  	xenbus_transaction_end(xbt, 1);
destroy_ring:
xennet_disconnect_backend(info);
drivers/net/xen-netfront.c +1 -0
+	rtnl_lock();
xennet_destroy_queues(info);
out:

drivers/net/xen-netfront.c

Quoted 1 line

drivers/net/xen-netfront.c +1 -0
+	rtnl_unlock();

...so this will be an unmatched unlock.

You need to add another label below the rtnl_unlock().

Ben.

Quoted 3 lines

device_unregister(&dev->dev);
return err;
}

[...]

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Ross Lagerwall

2018-06-21 13:06 UTC #74 lore raw

Re: [PATCH 4.4 059/268] xen-netfront: Fix race between device setup and open

Quoted 42 lines · Ben Hutchings

Quoted 7 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ross Lagerwall <[email protected]>
[ Upstream commit f599c64fdf7d9c108e8717fb04bc41c680120da4 ]
[...]
Quoted 2 lines
drivers/net/xen-netfront.c +0 -0
[...]
drivers/net/xen-netfront.c static int talk_to_netback(struct xenbus · line 1824
Quoted 2 lines
drivers/net/xen-netfront.c +0 -0
@@ -1839,6 +1824,7 @@ static int talk_to_netback(struct xenbus
  		goto out;
This "goto out" is outside the locked section...
Quoted 15 lines
drivers/net/xen-netfront.c +2 -0
  	}
 
+	rtnl_lock();
  	if (info->queues)
  		xennet_destroy_queues(info);
 
@@ -1849,6 +1835,7 @@ static int talk_to_netback(struct xenbus
  		info->queues = NULL;
  		goto out;
  	}
+	rtnl_unlock();
 
  	/* Create shared ring, alloc event channel -- for each queue */
  	for (i = 0; i < num_queues; ++i) {
drivers/net/xen-netfront.c abort_transaction_no_dev_fatal: · line 1938
Quoted 7 lines
drivers/net/xen-netfront.c +2 -0
@@ -1945,8 +1932,10 @@ abort_transaction_no_dev_fatal:
  	xenbus_transaction_end(xbt, 1);
   destroy_ring:
  	xennet_disconnect_backend(info);
+	rtnl_lock();
  	xennet_destroy_queues(info);
   out:
+	rtnl_unlock();
...so this will be an unmatched unlock.

Quoted 2 lines

You need to add another label below the rtnl_unlock().

Thanks for spotting this. I've sent patches to the list to fix this and another issue with the original patch.

Regards,

Signature · 1 line

Ross Lagerwall

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #75 lore raw

PATCH 60/268 xen/grant-table: Use put_page instead of free_page

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

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

From: Ross Lagerwall <[email protected]>

[ Upstream commit 3ac7292a25db1c607a50752055a18aba32ac2176 ]

The page given to gnttab_end_foreign_access() to free could be a compound page so use put_page() instead of free_page() since it can handle both compound and single pages correctly.

This bug was discovered when migrating a Xen VM with several VIFs and CONFIG_DEBUG_VM enabled. It hits a BUG usually after fewer than 10 iterations. All netfront devices disconnect from the backend during a suspend/resume and this will call gnttab_end_foreign_access() if a netfront queue has an outstanding skb. The mismatch between calling get_page() and free_page() on a compound page causes a reference counting error which is detected when DEBUG_VM is enabled.

Signed-off-by Ross Lagerwall <[email protected]>

Reviewed-by Boris Ostrovsky <[email protected]>

Signed-off-by Juergen Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/xen/grant-table.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/xen/grant-table.c +2 -2

@@ -328,7 +328,7 @@ static void gnttab_handle_deferred(unsig
 			if (entry->page) {
 				pr_debug("freeing g.e. %#x (pfn %#lx)\n",
 					 entry->ref, page_to_pfn(entry->page));
-				__free_page(entry->page);
+				put_page(entry->page);
 			} else
 				pr_info("freeing g.e. %#x\n", entry->ref);
 			kfree(entry);

@@ -384,7 +384,7 @@ void gnttab_end_foreign_access(grant_ref
 	if (gnttab_end_foreign_access_ref(ref, readonly)) {
 		put_free_entry(ref);
 		if (page != 0)
-			free_page(page);
+			put_page(virt_to_page(page));
 	} else
 		gnttab_add_deferred(ref, readonly,
 				    page ? virt_to_page(page) : NULL);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #76 lore raw

PATCH 61/268 RDS: IB: Fix null pointer issue

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

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

From: Guanglei Li <[email protected]>

[ Upstream commit 2c0aa08631b86a4678dbc93b9caa5248014b4458 ]

Scenario:
1. Port down and do fail over
2. Ap do rds_bind syscall

PID: 47039 TASK: ffff89887e2fe640 CPU: 47 COMMAND: "kworker/u:6"
#0 [ffff898e35f159f0] machine_kexec at ffffffff8103abf9 #1 [ffff898e35f15a60] crash_kexec at ffffffff810b96e3 #2 [ffff898e35f15b30] oops_end at ffffffff8150f518
#3 [ffff898e35f15b60] no_context at ffffffff8104854c
#4 [ffff898e35f15ba0] __bad_area_nosemaphore at ffffffff81048675 #5 [ffff898e35f15bf0] bad_area_nosemaphore at ffffffff810487d3 #6 [ffff898e35f15c00] do_page_fault at ffffffff815120b8 #7 [ffff898e35f15d10] page_fault at ffffffff8150ea95

    [exception RIP: unknown or invalid address]
    RIP: 0000000000000000  RSP: ffff898e35f15dc8  RFLAGS: 00010282
    RAX: 00000000fffffffe  RBX: ffff889b77f6fc00  RCX:ffffffff81c99d88
    RDX: 0000000000000000  RSI: ffff896019ee08e8  RDI:ffff889b77f6fc00
    RBP: ffff898e35f15df0   R8: ffff896019ee08c8  R9:0000000000000000
    R10: 0000000000000400  R11: 0000000000000000  R12:ffff896019ee08c0
    R13: ffff889b77f6fe68  R14: ffffffff81c99d80  R15: ffffffffa022a1e0
    ORIG_RAX: ffffffffffffffff  CS: 0010 SS: 0018

#8 [ffff898e35f15dc8] cma_ndev_work_handler at ffffffffa022a228 [rdma_cm] #9 [ffff898e35f15df8] process_one_work at ffffffff8108a7c6 #10 [ffff898e35f15e58] worker_thread at ffffffff8108bda0
#11 [ffff898e35f15ee8] kthread at ffffffff81090fe6

PID: 45659 TASK: ffff880d313d2500 CPU: 31 COMMAND: "oracle_45659_ap"
#0 [ffff881024ccfc98] __schedule at ffffffff8150bac4
#1 [ffff881024ccfd40] schedule at ffffffff8150c2cf
#2 [ffff881024ccfd50] __mutex_lock_slowpath at ffffffff8150cee7 #3 [ffff881024ccfdc0] mutex_lock at ffffffff8150cdeb
#4 [ffff881024ccfde0] rdma_destroy_id at ffffffffa022a027 [rdma_cm] #5 [ffff881024ccfe10] rds_ib_laddr_check at ffffffffa0357857 [rds_rdma] #6 [ffff881024ccfe50] rds_trans_get_preferred at ffffffffa0324c2a [rds] #7 [ffff881024ccfe80] rds_bind at ffffffffa031d690 [rds]
#8 [ffff881024ccfeb0] sys_bind at ffffffff8142a670

PID: 45659 PID: 47039
rds_ib_laddr_check
/* create id_priv with a null event_handler */ rdma_create_id
rdma_bind_addr

    cma_acquire_dev
      /* add id_priv to cma_dev->id_list */
      cma_attach_to_dev
                                    cma_ndev_work_handler
                                      /* event_hanlder is null */
                                      id_priv->id.event_handler

Signed-off-by Guanglei Li <[email protected]>

Signed-off-by Honglei Wang <[email protected]>

Reviewed-by Junxiao Bi <[email protected]>

Reviewed-by Yanjun Zhu <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Acked-by Santosh Shilimkar <[email protected]>

Acked-by Doug Ledford <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/rds/ib.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/rds/ib.c +2 -1

@@ -336,7 +336,8 @@ static int rds_ib_laddr_check(struct net
 	/* Create a CMA ID and try to bind it. This catches both
 	 * IB and iWARP capable NICs.
 	 */
-	cm_id = rdma_create_id(&init_net, NULL, NULL, RDMA_PS_TCP, IB_QPT_RC);
+	cm_id = rdma_create_id(&init_net, rds_rdma_cm_event_handler,
+			       NULL, RDMA_PS_TCP, IB_QPT_RC);
 	if (IS_ERR(cm_id))
 		return PTR_ERR(cm_id);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #77 lore raw

PATCH 62/268 arm64: spinlock: Fix theoretical trylock() A-B-A with LSE atomics

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

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

From: Will Deacon <[email protected]>

[ Upstream commit 202fb4ef81e3ec765c23bd1e6746a5c25b797d0e ]

If the spinlock "next" ticket wraps around between the initial LDR and the cmpxchg in the LSE version of spin_trylock, then we can erroneously think that we have successfuly acquired the lock because we only check whether the next ticket return by the cmpxchg is equal to the owner ticket in our updated lock word.

This patch fixes the issue by performing a full 32-bit check of the lock word when trying to determine whether or not the CASA instruction updated memory.

Reported-by Catalin Marinas <[email protected]>

Signed-off-by Will Deacon <[email protected]>

Signed-off-by Catalin Marinas <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/arm64/include/asm/spinlock.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm64/include/asm/spinlock.h +2 -2

@@ -94,8 +94,8 @@ static inline int arch_spin_trylock(arch
 	"	cbnz	%w1, 1f\n"
 	"	add	%w1, %w0, %3\n"
 	"	casa	%w0, %w1, %2\n"
-	"	and	%w1, %w1, #0xffff\n"
-	"	eor	%w1, %w1, %w0, lsr #16\n"
+	"	sub	%w1, %w1, %3\n"
+	"	eor	%w1, %w1, %w0\n"
 	"1:")
 	: "=&r" (lockval), "=&r" (tmp), "+Q" (*lock)
 	: "I" (1 << TICKET_SHIFT)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #78 lore raw

PATCH 63/268 proc: fix /proc/*/map_files lookup

Link http://lkml.kernel.org/r/20171120212706.GA14325@avx2 open here

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

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

From: Alexey Dobriyan <[email protected]>

[ Upstream commit ac7f1061c2c11bb8936b1b6a94cdb48de732f7a4 ]

Current code does:

	if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2)

However sscanf() is broken garbage.

It silently accepts whitespace between format specifiers (did you know that?).

It silently accepts valid strings which result in integer overflow.

Do not use sscanf() for any even remotely reliable parsing code.

	OK
	# readlink '/proc/1/map_files/55a23af39000-55a23b05b000'
	/lib/systemd/systemd

	broken
	# readlink '/proc/1/map_files/               55a23af39000-55a23b05b000'
	/lib/systemd/systemd

	broken
	# readlink '/proc/1/map_files/55a23af39000-55a23b05b000    '
	/lib/systemd/systemd

	very broken
	# readlink '/proc/1/map_files/1000000000000000055a23af39000-55a23b05b000'
	/lib/systemd/systemd

Andrei said:

: This patch breaks criu. It was a bug in criu. And this bug is on a minor : path, which works when memfd_create() isn't available. It is a reason why : I ask to not backport this patch to stable kernels.
:
: In CRIU this bug can be triggered, only if this patch will be backported : to a kernel which version is lower than v3.16.

Signed-off-by Alexey Dobriyan <[email protected]>

Cc Pavel Emelyanov <[email protected]>

Cc Andrei Vagin <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/proc/base.c |   29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

fs/proc/base.c +28 -1

@@ -94,6 +94,8 @@
 #include "internal.h"
 #include "fd.h"
 
+#include "../../lib/kstrtox.h"
+
 /* NOTE:
  *	Implementing inode permission operations in /proc is almost
  *	certainly an error.  Permission checks need to happen during

@@ -1836,8 +1838,33 @@ end_instantiate:
 static int dname_to_vma_addr(struct dentry *dentry,
 			     unsigned long *start, unsigned long *end)
 {
-	if (sscanf(dentry->d_name.name, "%lx-%lx", start, end) != 2)
+	const char *str = dentry->d_name.name;
+	unsigned long long sval, eval;
+	unsigned int len;
+
+	len = _parse_integer(str, 16, &sval);
+	if (len & KSTRTOX_OVERFLOW)
+		return -EINVAL;
+	if (sval != (unsigned long)sval)
 		return -EINVAL;
+	str += len;
+
+	if (*str != '-')
+		return -EINVAL;
+	str++;
+
+	len = _parse_integer(str, 16, &eval);
+	if (len & KSTRTOX_OVERFLOW)
+		return -EINVAL;
+	if (eval != (unsigned long)eval)
+		return -EINVAL;
+	str += len;
+
+	if (*str != '\0')
+		return -EINVAL;
+
+	*start = sval;
+	*end = eval;
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #79 lore raw

PATCH 64/268 cifs: silence compiler warnings showing up with gcc-8.0.0

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit ade7db991b47ab3016a414468164f4966bd08202 ]

This bug was fixed before, but came up again with the latest compiler in another function:

fs/cifs/cifssmb.c: In function 'CIFSSMBSetEA':
fs/cifs/cifssmb.c:6362:3: error: 'strncpy' offset 8 is out of the bounds [0, 4] [-Werror=array-bounds]
strncpy(parm_data->list[0].name, ea_name, name_len);

Let's apply the same fix that was used for the other instances.

Fixes b2a3ad9ca502 ("cifs: silence compiler warnings showing up with gcc-4.7.0")

Signed-off-by Steve French <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/cifs/cifssmb.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

fs/cifs/cifssmb.c +1 -3

@@ -6421,9 +6421,7 @@ SetEARetry:
 	pSMB->InformationLevel =
 		cpu_to_le16(SMB_SET_FILE_EA);
 
-	parm_data =
-		(struct fealist *) (((char *) &pSMB->hdr.Protocol) +
-				       offset);
+	parm_data = (void *)pSMB + offsetof(struct smb_hdr, Protocol) + offset;
 	pSMB->ParameterOffset = cpu_to_le16(param_offset);
 	pSMB->DataOffset = cpu_to_le16(offset);
 	pSMB->SetupCount = 1;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:16 UTC #80 lore raw

PATCH 65/268 bcache: properly set task state in bch_writeback_thread()

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

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

From: Coly Li <[email protected]>

[ Upstream commit 99361bbf26337186f02561109c17a4c4b1a7536a ]

Kernel thread routine bch_writeback_thread() has the following code block,

447 down_write(&dc->writeback_lock);
448~450 if (check conditions) {
451 up_write(&dc->writeback_lock);
452 set_current_state(TASK_INTERRUPTIBLE);
453
454 if (kthread_should_stop())
455 return 0;
456
457 schedule();
458 continue;
459 }

If condition check is true, its task state is set to TASK_INTERRUPTIBLE and call schedule() to wait for others to wake up it.

There are 2 issues in current code,
1, Task state is set to TASK_INTERRUPTIBLE after the condition checks, if
another process changes the condition and call wake_up_process(dc-> writeback_thread), then at line 452 task state is set back to TASK_INTERRUPTIBLE, the writeback kernel thread will lose a chance to be waken up.
2, At line 454 if kthread_should_stop() is true, writeback kernel thread
will return to kernel/kthread.c:kthread() with TASK_INTERRUPTIBLE and call do_exit(). It is not good to enter do_exit() with task state TASK_INTERRUPTIBLE, in following code path might_sleep() is called and a warning message is reported by __might_sleep(): "WARNING: do not call blocking ops when !TASK_RUNNING; state=1 set at [xxxx]".

For the first issue, task state should be set before condition checks. Ineed because dc->writeback_lock is required when modifying all the conditions, calling set_current_state() inside code block where dc-> writeback_lock is hold is safe. But this is quite implicit, so I still move set_current_state() before all the condition checks.

For the second issue, frankley speaking it does not hurt when kernel thread exits with TASK_INTERRUPTIBLE state, but this warning message scares users, makes them feel there might be something risky with bcache and hurt their data. Setting task state to TASK_RUNNING before returning fixes this problem.

In alloc.c:allocator_wait(), there is also a similar issue, and is also fixed in this patch.

Changelog:
v3: merge two similar fixes into one patch
v2: fix the race issue in v1 patch.
v1: initial buggy fix.

Signed-off-by Coly Li <[email protected]>

Reviewed-by Hannes Reinecke <[email protected]>

Cc Michael Lyle <[email protected]>

Cc Junhui Tang <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/md/bcache/alloc.c     |    4 +++-
 drivers/md/bcache/writeback.c |    7 +++++--
 2 files changed, 8 insertions(+), 3 deletions(-)

drivers/md/bcache/alloc.c +3 -1

@@ -285,8 +285,10 @@ do {									\
 			break;						\
 									\
 		mutex_unlock(&(ca)->set->bucket_lock);			\
-		if (kthread_should_stop())				\
+		if (kthread_should_stop()) {				\
+			set_current_state(TASK_RUNNING);		\
 			return 0;					\
+		}							\
 									\
 		try_to_freeze();					\
 		schedule();						\

drivers/md/bcache/writeback.c +5 -2

@@ -425,19 +425,22 @@ static int bch_writeback_thread(void *ar
 
 	while (!kthread_should_stop()) {
 		down_write(&dc->writeback_lock);
+		set_current_state(TASK_INTERRUPTIBLE);
 		if (!atomic_read(&dc->has_dirty) ||
 		    (!test_bit(BCACHE_DEV_DETACHING, &dc->disk.flags) &&
 		     !dc->writeback_running)) {
 			up_write(&dc->writeback_lock);
-			set_current_state(TASK_INTERRUPTIBLE);
 
-			if (kthread_should_stop())
+			if (kthread_should_stop()) {
+				set_current_state(TASK_RUNNING);
 				return 0;
+			}
 
 			try_to_freeze();
 			schedule();
 			continue;
 		}
+		set_current_state(TASK_RUNNING);
 
 		searched_full_index = refill_dirty(dc);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #81 lore raw

PATCH 67/268 bcache: fix for data collapse after re-attaching an attached device

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

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

From: Tang Junhui <[email protected]>

[ Upstream commit 73ac105be390c1de42a2f21643c9778a5e002930 ]

back-end device sdm has already attached a cache_set with ID f67ebe1f-f8bc-4d73-bfe5-9dc88607f119, then try to attach with another cache set, and it returns with an error:
[root]# cd /sys/block/sdm/bcache
[root]# echo 5ccd0a63-148e-48b8-afa2-aca9cbd6279f > attach -bash: echo: write error: Invalid argument

After that, execute a command to modify the label of bcache device:
[root]# echo data_disk1 > label

Then we reboot the system, when the system power on, the back-end device can not attach to cache_set, a messages show in the log:

Feb  5 12:05:52 ceph152 kernel: [922385.508498] bcache:

bch_cached_dev_attach() couldn't find uuid for sdm in set

In sysfs_attach(), dc->sb.set_uuid was assigned to the value which input through sysfs, no matter whether it is success or not in bch_cached_dev_attach(). For example, If the back-end device has already attached to an cache set, bch_cached_dev_attach() would fail, but dc->sb.set_uuid was changed. Then modify the label of bcache device, it will call bch_write_bdev_super(), which would write the dc->sb.set_uuid to the super block, so we record a wrong cache set ID in the super block, after the system reboot, the cache set couldn't find the uuid of the back-end device, so the bcache device couldn't exist and use any more.

In this patch, we don't assigned cache set ID to dc->sb.set_uuid in sysfs_attach() directly, but input it into bch_cached_dev_attach(), and assigned dc->sb.set_uuid to the cache set ID after the back-end device attached to the cache set successful.

Signed-off-by Tang Junhui <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/md/bcache/bcache.h |    2 +-
 drivers/md/bcache/super.c  |   10 ++++++----
 drivers/md/bcache/sysfs.c  |    6 ++++--
 3 files changed, 11 insertions(+), 7 deletions(-)

drivers/md/bcache/bcache.h +1 -1

@@ -904,7 +904,7 @@ void bcache_write_super(struct cache_set
 
 int bch_flash_dev_create(struct cache_set *c, uint64_t size);
 
-int bch_cached_dev_attach(struct cached_dev *, struct cache_set *);
+int bch_cached_dev_attach(struct cached_dev *, struct cache_set *, uint8_t *);
 void bch_cached_dev_detach(struct cached_dev *);
 void bch_cached_dev_run(struct cached_dev *);
 void bcache_device_stop(struct bcache_device *);

drivers/md/bcache/super.c +6 -4

@@ -936,7 +936,8 @@ void bch_cached_dev_detach(struct cached
 	cached_dev_put(dc);
 }
 
-int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c)
+int bch_cached_dev_attach(struct cached_dev *dc, struct cache_set *c,
+			  uint8_t *set_uuid)
 {
 	uint32_t rtime = cpu_to_le32(get_seconds());
 	struct uuid_entry *u;

@@ -945,7 +946,8 @@ int bch_cached_dev_attach(struct cached_
 
 	bdevname(dc->bdev, buf);
 
-	if (memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16))
+	if ((set_uuid && memcmp(set_uuid, c->sb.set_uuid, 16)) ||
+	    (!set_uuid && memcmp(dc->sb.set_uuid, c->sb.set_uuid, 16)))
 		return -ENOENT;
 
 	if (dc->disk.c) {

@@ -1189,7 +1191,7 @@ static void register_bdev(struct cache_s
 
 	list_add(&dc->list, &uncached_devices);
 	list_for_each_entry(c, &bch_cache_sets, list)
-		bch_cached_dev_attach(dc, c);
+		bch_cached_dev_attach(dc, c, NULL);
 
 	if (BDEV_STATE(&dc->sb) == BDEV_STATE_NONE ||
 	    BDEV_STATE(&dc->sb) == BDEV_STATE_STALE)

@@ -1711,7 +1713,7 @@ static void run_cache_set(struct cache_s
 	bcache_write_super(c);
 
 	list_for_each_entry_safe(dc, t, &uncached_devices, list)
-		bch_cached_dev_attach(dc, c);
+		bch_cached_dev_attach(dc, c, NULL);
 
 	flash_devs_run(c);

drivers/md/bcache/sysfs.c +4 -2

@@ -263,11 +263,13 @@ STORE(__cached_dev)
 	}
 
 	if (attr == &sysfs_attach) {
-		if (bch_parse_uuid(buf, dc->sb.set_uuid) < 16)
+		uint8_t		set_uuid[16];
+
+		if (bch_parse_uuid(buf, set_uuid) < 16)
 			return -EINVAL;
 
 		list_for_each_entry(c, &bch_cache_sets, list) {
-			v = bch_cached_dev_attach(dc, c);
+			v = bch_cached_dev_attach(dc, c, set_uuid);
 			if (!v)
 				return size;
 		}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #82 lore raw

PATCH 68/268 bcache: return attach error when no cache set exist

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

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

From: Tang Junhui <[email protected]>

[ Upstream commit 7f4fc93d4713394ee8f1cd44c238e046e11b4f15 ]

I attach a back-end device to a cache set, and the cache set is not registered yet, this back-end device did not attach successfully, and no error returned:
[root]# echo 87859280-fec6-4bcc-20df7ca8f86b > /sys/block/sde/bcache/attach [root]#

In sysfs_attach(), the return value "v" is initialized to "size" in the beginning, and if no cache set exist in bch_cache_sets, the "v" value would not change any more, and return to sysfs, sysfs regard it as success since the "size" is a positive number.

This patch fixes this issue by assigning "v" with "-ENOENT" in the initialization.

Signed-off-by Tang Junhui <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/md/bcache/sysfs.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

drivers/md/bcache/sysfs.c +3 -2

@@ -191,7 +191,7 @@ STORE(__cached_dev)
 {
 	struct cached_dev *dc = container_of(kobj, struct cached_dev,
 					     disk.kobj);
-	ssize_t v = size;
+	ssize_t v;
 	struct cache_set *c;
 	struct kobj_uevent_env *env;

@@ -268,6 +268,7 @@ STORE(__cached_dev)
 		if (bch_parse_uuid(buf, set_uuid) < 16)
 			return -EINVAL;
 
+		v = -ENOENT;
 		list_for_each_entry(c, &bch_cache_sets, list) {
 			v = bch_cached_dev_attach(dc, c, set_uuid);
 			if (!v)

@@ -275,7 +276,7 @@ STORE(__cached_dev)
 		}
 
 		pr_err("Can't attach %s: cache set not found", buf);
-		size = v;
+		return v;
 	}
 
 	if (attr == &sysfs_detach && dc->disk.c)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #83 lore raw

PATCH 69/268 tools/libbpf: handle issues with bpf ELF objects containing .eh_frames

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

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

From: Jesper Dangaard Brouer <[email protected]>

[ Upstream commit e3d91b0ca523d53158f435a3e13df7f0cb360ea2 ]

V3: More generic skipping of relo-section (suggested by Daniel)

If clang >= 4.0.1 is missing the option '-target bpf', it will cause llc/llvm to create two ELF sections for "Exception Frames", with section names '.eh_frame' and '.rel.eh_frame'.

The BPF ELF loader library libbpf fails when loading files with these sections. The other in-kernel BPF ELF loader in samples/bpf/bpf_load.c, handle this gracefully. And iproute2 loader also seems to work with these "eh" sections.

The issue in libbpf is caused by bpf_object__elf_collect() skipping some sections, and later when performing relocation it will be pointing to a skipped section, as these sections cannot be found by bpf_object__find_prog_by_idx() in bpf_object__collect_reloc().

This is a general issue that also occurs for other sections, like debug sections which are also skipped and can have relo section.

As suggested by Daniel. To avoid keeping state about all skipped sections, instead perform a direct qlookup in the ELF object. Lookup the section that the relo-section points to and check if it contains executable machine instructions (denoted by the sh_flags SHF_EXECINSTR). Use this check to also skip irrelevant relo-sections.

Note, for samples/bpf/ the '-target bpf' parameter to clang cannot be used due to incompatibility with asm embedded headers, that some of the samples include. This is explained in more details by Yonghong Song in bpf_devel_QA.

Signed-off-by Jesper Dangaard Brouer <[email protected]>

Signed-off-by Daniel Borkmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 tools/lib/bpf/libbpf.c |   26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

tools/lib/bpf/libbpf.c +26 -0

@@ -487,6 +487,24 @@ bpf_object__init_maps(struct bpf_object
 	return 0;
 }
 
+static bool section_have_execinstr(struct bpf_object *obj, int idx)
+{
+	Elf_Scn *scn;
+	GElf_Shdr sh;
+
+	scn = elf_getscn(obj->efile.elf, idx);
+	if (!scn)
+		return false;
+
+	if (gelf_getshdr(scn, &sh) != &sh)
+		return false;
+
+	if (sh.sh_flags & SHF_EXECINSTR)
+		return true;
+
+	return false;
+}
+
 static int bpf_object__elf_collect(struct bpf_object *obj)
 {
 	Elf *elf = obj->efile.elf;

@@ -567,6 +585,14 @@ static int bpf_object__elf_collect(struc
 		} else if (sh.sh_type == SHT_REL) {
 			void *reloc = obj->efile.reloc;
 			int nr_reloc = obj->efile.nr_reloc + 1;
+			int sec = sh.sh_info; /* points to other section */
+
+			/* Only do relo for section with exec instructions */
+			if (!section_have_execinstr(obj, sec)) {
+				pr_debug("skip relo %s(%d) for section(%d)\n",
+					 name, idx, sec);
+				continue;
+			}
 
 			reloc = realloc(reloc,
 					sizeof(*obj->efile.reloc) * nr_reloc);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #84 lore raw

PATCH 70/268 locking/qspinlock: Ensure node->count is updated before initialising node

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

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

From: Will Deacon <[email protected]>

[ Upstream commit 11dc13224c975efcec96647a4768a6f1bb7a19a8 ]

When queuing on the qspinlock, the count field for the current CPU's head node is incremented. This needn't be atomic because locking in e.g. IRQ context is balanced and so an IRQ will return with node->count as it found it.

However, the compiler could in theory reorder the initialisation of node[idx] before the increment of the head node->count, causing an IRQ to overwrite the initialised node and potentially corrupt the lock state.

Avoid the potential for this harmful compiler reordering by placing a barrier() between the increment of the head node->count and the subsequent node initialisation.

Signed-off-by Will Deacon <[email protected]>

Acked-by Peter Zijlstra (Intel) <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 kernel/locking/qspinlock.c |    8 ++++++++
 1 file changed, 8 insertions(+)

kernel/locking/qspinlock.c +8 -0

@@ -423,6 +423,14 @@ queue:
 	tail = encode_tail(smp_processor_id(), idx);
 
 	node += idx;
+
+	/*
+	 * Ensure that we increment the head node->count before initialising
+	 * the actual node. If the compiler is kind enough to reorder these
+	 * stores, then an IRQ could overwrite our assignments.
+	 */
+	barrier();
+
 	node->locked = 0;
 	node->next = NULL;
 	pv_init_node(node);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #85 lore raw

PATCH 71/268 irqchip/gic-v3: Change pr_debug message to pr_devel

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

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

From: Mark Salter <[email protected]>

[ Upstream commit b6dd4d83dc2f78cebc9a7e6e7e4bc2be4d29b94d ]

The pr_debug() in gic-v3 gic_send_sgi() can trigger a circular locking warning:

GICv3: CPU10: ICC_SGI1R_EL1 5000400
======================================================
WARNING: possible circular locking dependency detected
4.15.0+ #1 Tainted: G W
------------------------------------------------------
dynamic_debug01/1873 is trying to acquire lock:
((console_sem).lock){-...}, at: [<0000000099c891ec>] down_trylock+0x20/0x4c

but task is already holding lock:
(&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&rq->lock){-.-.}:

        __lock_acquire+0x3b4/0x6e0
        lock_acquire+0xf4/0x2a8
        _raw_spin_lock+0x4c/0x60
        task_fork_fair+0x3c/0x148
        sched_fork+0x10c/0x214
        copy_process.isra.32.part.33+0x4e8/0x14f0
        _do_fork+0xe8/0x78c
        kernel_thread+0x48/0x54
        rest_init+0x34/0x2a4
        start_kernel+0x45c/0x488

-> #1 (&p->pi_lock){-.-.}:

        __lock_acquire+0x3b4/0x6e0
        lock_acquire+0xf4/0x2a8
        _raw_spin_lock_irqsave+0x58/0x70
        try_to_wake_up+0x48/0x600
        wake_up_process+0x28/0x34
        __up.isra.0+0x60/0x6c
        up+0x60/0x68
        __up_console_sem+0x4c/0x7c
        console_unlock+0x328/0x634
        vprintk_emit+0x25c/0x390
        dev_vprintk_emit+0xc4/0x1fc
        dev_printk_emit+0x88/0xa8
        __dev_printk+0x58/0x9c
        _dev_info+0x84/0xa8
        usb_new_device+0x100/0x474
        hub_port_connect+0x280/0x92c
        hub_event+0x740/0xa84
        process_one_work+0x240/0x70c
        worker_thread+0x60/0x400
        kthread+0x110/0x13c
        ret_from_fork+0x10/0x18

-> #0 ((console_sem).lock){-...}:

        validate_chain.isra.34+0x6e4/0xa20
        __lock_acquire+0x3b4/0x6e0
        lock_acquire+0xf4/0x2a8
        _raw_spin_lock_irqsave+0x58/0x70
        down_trylock+0x20/0x4c
        __down_trylock_console_sem+0x3c/0x9c
        console_trylock+0x20/0xb0
        vprintk_emit+0x254/0x390
        vprintk_default+0x58/0x90
        vprintk_func+0xbc/0x164
        printk+0x80/0xa0
        __dynamic_pr_debug+0x84/0xac
        gic_raise_softirq+0x184/0x18c
        smp_cross_call+0xac/0x218
        smp_send_reschedule+0x3c/0x48
        resched_curr+0x60/0x9c
        check_preempt_curr+0x70/0xdc
        wake_up_new_task+0x310/0x470
        _do_fork+0x188/0x78c
        SyS_clone+0x44/0x50
        __sys_trace_return+0x0/0x4

other info that might help us debug this:

 Chain exists of:
   (console_sem).lock --> &p->pi_lock --> &rq->lock

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&rq->lock);
                                lock(&p->pi_lock);
                                lock(&rq->lock);

lock((console_sem).lock);

*** DEADLOCK ***

2 locks held by dynamic_debug01/1873:
#0: (&p->pi_lock){-.-.}, at: [<000000001366df53>] wake_up_new_task+0x40/0x470 #1: (&rq->lock){-.-.}, at: [<00000000842e1587>] __task_rq_lock+0x54/0xdc

 stack backtrace:
 CPU: 10 PID: 1873 Comm: dynamic_debug01 Tainted: G        W        4.15.0+ #1
 Hardware name: GIGABYTE R120-T34-00/MT30-GS2-00, BIOS T48 10/02/2017
 Call trace:
  dump_backtrace+0x0/0x188
  show_stack+0x24/0x2c
  dump_stack+0xa4/0xe0
  print_circular_bug.isra.31+0x29c/0x2b8
  check_prev_add.constprop.39+0x6c8/0x6dc
  validate_chain.isra.34+0x6e4/0xa20
  __lock_acquire+0x3b4/0x6e0
  lock_acquire+0xf4/0x2a8
  _raw_spin_lock_irqsave+0x58/0x70
  down_trylock+0x20/0x4c
  __down_trylock_console_sem+0x3c/0x9c
  console_trylock+0x20/0xb0
  vprintk_emit+0x254/0x390
  vprintk_default+0x58/0x90
  vprintk_func+0xbc/0x164
  printk+0x80/0xa0
  __dynamic_pr_debug+0x84/0xac
  gic_raise_softirq+0x184/0x18c
  smp_cross_call+0xac/0x218
  smp_send_reschedule+0x3c/0x48
  resched_curr+0x60/0x9c
  check_preempt_curr+0x70/0xdc
  wake_up_new_task+0x310/0x470
  _do_fork+0x188/0x78c
  SyS_clone+0x44/0x50
  __sys_trace_return+0x0/0x4
 GICv3: CPU0: ICC_SGI1R_EL1 12000

This could be fixed with printk_deferred() but that might lessen its usefulness for debugging. So change it to pr_devel to keep it out of production kernels. Developers working on gic-v3 can enable it as needed in their kernels.

Signed-off-by Mark Salter <[email protected]>

Signed-off-by Marc Zyngier <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/irqchip/irq-gic-v3.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/irqchip/irq-gic-v3.c +1 -1

@@ -589,7 +589,7 @@ static void gic_send_sgi(u64 cluster_id,
 	       MPIDR_TO_SGI_AFFINITY(cluster_id, 1)	|
 	       tlist << ICC_SGI1R_TARGET_LIST_SHIFT);
 
-	pr_debug("CPU%d: ICC_SGI1R_EL1 %llx\n", smp_processor_id(), val);
+	pr_devel("CPU%d: ICC_SGI1R_EL1 %llx\n", smp_processor_id(), val);
 	gic_write_sgi1r(val);
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #86 lore raw

PATCH 72/268 scsi: ufs: Enable quirk to ignore sending WRITE_SAME command

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

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

From: Sujit Reddy Thumma <[email protected]>

[ Upstream commit 84af7e8b895088d89f246d6b0f82717fafdebf61 ]

WRITE_SAME command is not supported by UFS. Enable a quirk for the upper level drivers to not send WRITE SAME command.

[mkp: botched patch, applied by hand]

Signed-off-by Sujit Reddy Thumma <[email protected]>

Signed-off-by Subhash Jadavani <[email protected]>

Signed-off-by Asutosh Das <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/ufs/ufshcd.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/scsi/ufs/ufshcd.c +2 -0

@@ -2923,6 +2923,8 @@ static int ufshcd_slave_alloc(struct scs
 	/* REPORT SUPPORTED OPERATION CODES is not supported */
 	sdev->no_report_opcodes = 1;
 
+	/* WRITE_SAME command is not supported */
+	sdev->no_write_same = 1;
 
 	ufshcd_set_queue_depth(sdev);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #87 lore raw

PATCH 73/268 scsi: bnx2fc: Fix check in SCSI completion handler for timed out request

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

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

From: Chad Dupuis <[email protected]>

[ Upstream commit ecf7ff49945f5741fa1da112f994939f942031d3 ]

When a request times out we set the io_req flag BNX2FC_FLAG_IO_COMPL so that if a subsequent completion comes in on that task ID we will ignore it. The issue is that in the check for this flag there is a missing return so we will continue to process a request which may have already been returned to the ownership of the SCSI layer. This can cause unpredictable results.

Solution is to add in the missing return.

[mkp: typo plus title shortening]

Signed-off-by Chad Dupuis <[email protected]>

Reviewed-by Laurence Oberman <[email protected]>

Tested-by Laurence Oberman <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/bnx2fc/bnx2fc_io.c |    1 +
 1 file changed, 1 insertion(+)

drivers/scsi/bnx2fc/bnx2fc_io.c +1 -0

@@ -1858,6 +1858,7 @@ void bnx2fc_process_scsi_cmd_compl(struc
 		/* we will not receive ABTS response for this IO */
 		BNX2FC_IO_DBG(io_req, "Timer context finished processing "
 			   "this scsi cmd\n");
+		return;
 	}
 
 	/* Cancel the timeout_work, as we received IO completion */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #88 lore raw

PATCH 74/268 scsi: sym53c8xx_2: iterator underflow in sym_getsync()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit e6f791d95313c85f3dd4a26141e28e50ae9aa0ae ]

We wanted to exit the loop with "div" set to zero, but instead, if we don't hit the break then "div" is -1 when we finish the loop. It leads to an array underflow a few lines later.

Reviewed-by Johannes Thumshirn <[email protected]>

Acked-by Matthew Wilcox <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/sym53c8xx_2/sym_hipd.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/sym53c8xx_2/sym_hipd.c +1 -1

@@ -536,7 +536,7 @@ sym_getsync(struct sym_hcb *np, u_char d
 	 *  Look for the greatest clock divisor that allows an 
 	 *  input speed faster than the period.
 	 */
-	while (div-- > 0)
+	while (--div > 0)
 		if (kpc >= (div_10M[div] << 2)) break;
 
 	/*

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #89 lore raw

PATCH 75/268 scsi: mptfusion: Add bounds check in mptctl_hp_targetinfo()

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

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

From: Dan Carpenter <[email protected]>

[ Upstream commit a7043e9529f3c367cc4d82997e00be034cbe57ca ]

My static checker complains about an out of bounds read:

    drivers/message/fusion/mptctl.c:2786 mptctl_hp_targetinfo()
    error: buffer overflow 'hd->sel_timeout' 255 <= u32max.

It's true that we probably should have a bounds check here.

Reviewed-by Johannes Thumshirn <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/message/fusion/mptctl.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/message/fusion/mptctl.c +2 -0

@@ -2698,6 +2698,8 @@ mptctl_hp_targetinfo(unsigned long arg)
 				__FILE__, __LINE__, iocnum);
 		return -ENODEV;
 	}
+	if (karg.hdr.id >= MPT_MAX_FC_DEVICES)
+		return -EINVAL;
 	dctlprintk(ioc, printk(MYIOC_s_DEBUG_FMT "mptctl_hp_targetinfo called.\n",
 	    ioc->name));

Greg Kroah-Hartman

author maintainer

2018-05-28 10:00 UTC #90 lore raw

PATCH 76/268 scsi: qla2xxx: Avoid triggering undefined behavior in qla2x00_mbx_completion()

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

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

From: Bart Van Assche <[email protected]>

[ Upstream commit c02189e12ce3bf3808cb880569d3b10249f50bd9 ]

A left shift must shift less than the bit width of the left argument. Avoid triggering undefined behavior if ha->mbx_count == 32.

This patch avoids that UBSAN reports the following complaint:

UBSAN: Undefined behaviour in drivers/scsi/qla2xxx/qla_isr.c:275:14
shift exponent 32 is too large for 32-bit type 'int'
Call Trace:
 dump_stack+0x4e/0x6c
 ubsan_epilogue+0xd/0x3b
 __ubsan_handle_shift_out_of_bounds+0x112/0x14c
 qla2x00_mbx_completion+0x1c5/0x25d [qla2xxx]
 qla2300_intr_handler+0x1ea/0x3bb [qla2xxx]
 qla2x00_mailbox_command+0x77b/0x139a [qla2xxx]
 qla2x00_mbx_reg_test+0x83/0x114 [qla2xxx]
 qla2x00_chip_diag+0x354/0x45f [qla2xxx]
 qla2x00_initialize_adapter+0x2c2/0xa4e [qla2xxx]
 qla2x00_probe_one+0x1681/0x392e [qla2xxx]
 pci_device_probe+0x10b/0x1f1
 driver_probe_device+0x21f/0x3a4
 __driver_attach+0xa9/0xe1
 bus_for_each_dev+0x6e/0xb5
 driver_attach+0x22/0x3c
 bus_add_driver+0x1d1/0x2ae
 driver_register+0x78/0x130
 __pci_register_driver+0x75/0xa8
 qla2x00_module_init+0x21b/0x267 [qla2xxx]
 do_one_initcall+0x5a/0x1e2
 do_init_module+0x9d/0x285
 load_module+0x20db/0x38e3
 SYSC_finit_module+0xa8/0xbc
 SyS_finit_module+0x9/0xb
 do_syscall_64+0x77/0x271
 entry_SYSCALL64_slow_path+0x25/0x25

Reported-by Meelis Roos <[email protected]>

Signed-off-by Bart Van Assche <[email protected]>

Cc Himanshu Madhani <[email protected]>

Reviewed-by Laurence Oberman <[email protected]>

Acked-by Himanshu Madhani <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/qla2xxx/qla_isr.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

drivers/scsi/qla2xxx/qla_isr.c +4 -2

@@ -268,7 +268,8 @@ qla2x00_mbx_completion(scsi_qla_host_t *
 	struct device_reg_2xxx __iomem *reg = &ha->iobase->isp;
 
 	/* Read all mbox registers? */
-	mboxes = (1 << ha->mbx_count) - 1;
+	WARN_ON_ONCE(ha->mbx_count > 32);
+	mboxes = (1ULL << ha->mbx_count) - 1;
 	if (!ha->mcp)
 		ql_dbg(ql_dbg_async, vha, 0x5001, "MBX pointer ERROR.\n");
 	else

@@ -2495,7 +2496,8 @@ qla24xx_mbx_completion(scsi_qla_host_t *
 	struct device_reg_24xx __iomem *reg = &ha->iobase->isp24;
 
 	/* Read all mbox registers? */
-	mboxes = (1 << ha->mbx_count) - 1;
+	WARN_ON_ONCE(ha->mbx_count > 32);
+	mboxes = (1ULL << ha->mbx_count) - 1;
 	if (!ha->mcp)
 		ql_dbg(ql_dbg_async, vha, 0x504e, "MBX pointer ERROR.\n");
 	else

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #91 lore raw

PATCH 77/268 ARC: Fix malformed ARC_EMUL_UNALIGNED default

Discovered with the
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ulfalizer_Kconfiglib_blob_master_examples_list-5Fundefined.py&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=c14YS-cH-kdhTOW89KozFhBtBJgs1zXscZojEZQ0THs&m=WxxD8ozR7QQUVzNCBksiznaisBGO_crN7PBOvAoju8s&s=1LmxsNqxwT-7wcInVpZ6Z1J27duZKSoyKxHIJclXU_M&e=
script.

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

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

From: Ulf Magnusson <[email protected]>

[ Upstream commit 827cc2fa024dd6517d62de7a44c7b42f32af371b ]

'default N' should be 'default n', though they happen to have the same effect here, due to undefined symbols (N in this case) evaluating to n in a tristate sense.

Remove the default from ARC_EMUL_UNALIGNED instead of changing it. bool and tristate symbols implicitly default to n.

Signed-off-by Vineet Gupta <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/arc/Kconfig |    1 -
 1 file changed, 1 deletion(-)

arch/arc/Kconfig +0 -1

@@ -479,7 +479,6 @@ config ARC_CURR_IN_REG
 
 config ARC_EMUL_UNALIGNED
 	bool "Emulate unaligned memory access (userspace only)"
-	default N
 	select SYSCTL_ARCH_UNALIGN_NO_WARN
 	select SYSCTL_ARCH_UNALIGN_ALLOW
 	depends on ISA_ARCOMPACT

Greg Kroah-Hartman

author maintainer

2018-05-28 10:00 UTC #92 lore raw

PATCH 78/268 usb: gadget: f_uac2: fix bFirstInterface in composite gadget

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

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

From: John Keeping <[email protected]>

[ Upstream commit 8813a59ed892305b5ac1b5b901740b1ad4b5fefa ]

If there are multiple functions associated with a configuration, then the UAC2 interfaces may not start at zero. Set the correct first interface number in the association descriptor so that the audio interfaces are enumerated correctly in this case.

Reviewed-by Krzysztof Opasiak <[email protected]>

Signed-off-by John Keeping <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/usb/gadget/function/f_uac2.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/usb/gadget/function/f_uac2.c +2 -0

@@ -1052,6 +1052,8 @@ afunc_bind(struct usb_configuration *cfg
 		dev_err(dev, "%s:%d Error!\n", __func__, __LINE__);
 		return ret;
 	}
+	iad_desc.bFirstInterface = ret;
+
 	std_ac_if_desc.bInterfaceNumber = ret;
 	agdev->ac_intf = ret;
 	agdev->ac_alt = 0;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #93 lore raw

PATCH 79/268 usb: gadget: fsl_udc_core: fix ep valid checks

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

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

From: Stefan Agner <[email protected]>

[ Upstream commit 20c63f4089cceab803438c383631963e34c4d8e5 ]

Clang reports the following warning:
drivers/usb/gadget/udc/fsl_udc_core.c:1312:10: warning: address of array 'ep->name' will always evaluate to 'true' [-Wpointer-bool-conversion]

        if (ep->name)
        ~~  ~~~~^~~~

It seems that the authors intention was to check if the ep has been configured through struct_ep_setup. Check whether struct usb_ep name pointer has been set instead.

Signed-off-by Stefan Agner <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/usb/gadget/udc/fsl_udc_core.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/usb/gadget/udc/fsl_udc_core.c +2 -2

@@ -1310,7 +1310,7 @@ static void udc_reset_ep_queue(struct fs
 {
 	struct fsl_ep *ep = get_ep_by_pipe(udc, pipe);
 
-	if (ep->name)
+	if (ep->ep.name)
 		nuke(ep, -ESHUTDOWN);
 }

@@ -1698,7 +1698,7 @@ static void dtd_complete_irq(struct fsl_
 		curr_ep = get_ep_by_pipe(udc, i);
 
 		/* If the ep is configured */
-		if (curr_ep->name == NULL) {
+		if (!curr_ep->ep.name) {
 			WARNING("Invalid EP?");
 			continue;
 		}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:00 UTC #94 lore raw

PATCH 80/268 usb: dwc2: Fix dwc2_hsotg_core_init_disconnected()

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

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

From: Vardan Mikayelyan <[email protected]>

[ Upstream commit 755d739534f998d92e348fba8ffb0478416576e7 ]

We should call dwc2_hsotg_enqueue_setup() after properly setting lx_state. Because it may cause error-out from dwc2_hsotg_enqueue_setup() due to wrong value in lx_state.

Issue can be reproduced by loading driver while connected A-Connector (start in A-HOST mode) then disconnect A-Connector to switch to B-DEVICE.

Acked-by John Youn <[email protected]>

Signed-off-by Vardan Mikayelyan <[email protected]>

Signed-off-by Grigor Tovmasyan <[email protected]>

Signed-off-by Felipe Balbi <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/usb/dwc2/gadget.c |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

drivers/usb/dwc2/gadget.c +6 -6

@@ -2424,12 +2424,6 @@ void dwc2_hsotg_core_init_disconnected(s
 	dwc2_writel(dwc2_hsotg_ep0_mps(hsotg->eps_out[0]->ep.maxpacket) |
 	       DXEPCTL_USBACTEP, hsotg->regs + DIEPCTL0);
 
-	dwc2_hsotg_enqueue_setup(hsotg);
-
-	dev_dbg(hsotg->dev, "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\n",
-		dwc2_readl(hsotg->regs + DIEPCTL0),
-		dwc2_readl(hsotg->regs + DOEPCTL0));
-
 	/* clear global NAKs */
 	val = DCTL_CGOUTNAK | DCTL_CGNPINNAK;
 	if (!is_usb_reset)

@@ -2440,6 +2434,12 @@ void dwc2_hsotg_core_init_disconnected(s
 	mdelay(3);
 
 	hsotg->lx_state = DWC2_L0;
+
+	dwc2_hsotg_enqueue_setup(hsotg);
+
+	dev_dbg(hsotg->dev, "EP0: DIEPCTL0=0x%08x, DOEPCTL0=0x%08x\n",
+		dwc2_readl(hsotg->regs + DIEPCTL0),
+		dwc2_readl(hsotg->regs + DOEPCTL0));
 }
 
 static void dwc2_hsotg_core_disconnect(struct dwc2_hsotg *hsotg)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #95 lore raw

PATCH 82/268 scsi: storvsc: Increase cmd_per_lun for higher speed devices

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

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

From: "Michael Kelley (EOSG)" <[email protected]>

[ Upstream commit cabe92a55e3a12005a4ac4d3954c9a174b0efe2a ]

Increase cmd_per_lun to allow more I/Os in progress per device, particularly for NVMe's. The Hyper-V host side can handle the higher count with no issues.

Signed-off-by Michael Kelley <[email protected]>

Reviewed-by K. Y. Srinivasan <[email protected]>

Acked-by K. Y. Srinivasan <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

drivers/scsi/storvsc_drv.c +1 -1

@@ -1538,7 +1538,7 @@ static struct scsi_host_template scsi_dr
 	.eh_timed_out =		storvsc_eh_timed_out,
 	.slave_alloc =		storvsc_device_alloc,
 	.slave_configure =	storvsc_device_configure,
-	.cmd_per_lun =		255,
+	.cmd_per_lun =		2048,
 	.this_id =		-1,
 	.use_clustering =	ENABLE_CLUSTERING,
 	/* Make sure we dont get a sg segment crosses a page boundary */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #96 lore raw

PATCH 83/268 scsi: aacraid: fix shutdown crash when init fails

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

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

From: Meelis Roos <[email protected]>

[ Upstream commit 00c20cdc79259c6c5bf978b21af96c2d3edb646d ]

When aacraid init fails with "AAC0: adapter self-test failed.", shutdown leads to UBSAN warning and then oops:

[154316.118423] ================================================================================
[154316.118508] UBSAN: Undefined behaviour in drivers/scsi/scsi_lib.c:2328:27
[154316.118566] member access within null pointer of type 'struct Scsi_Host'
[154316.118631] CPU: 2 PID: 14530 Comm: reboot Tainted: G        W        4.15.0-dirty #89
[154316.118701] Hardware name: Hewlett Packard HP NetServer/HP System Board, BIOS 4.06.46 PW 06/25/2003
[154316.118774] Call Trace:
[154316.118848]  dump_stack+0x48/0x65
[154316.118916]  ubsan_epilogue+0xe/0x40
[154316.118976]  __ubsan_handle_type_mismatch+0xfb/0x180
[154316.119043]  scsi_block_requests+0x20/0x30
[154316.119135]  aac_shutdown+0x18/0x40 [aacraid]
[154316.119196]  pci_device_shutdown+0x33/0x50
[154316.119269]  device_shutdown+0x18a/0x390
[...]
[154316.123435] BUG: unable to handle kernel NULL pointer dereference at 000000f4
[154316.123515] IP: scsi_block_requests+0xa/0x30

This is because aac_shutdown() does

        struct Scsi_Host *shost = pci_get_drvdata(dev);
        scsi_block_requests(shost);

and that assumes shost has been assigned with pci_set_drvdata().

However, pci_set_drvdata(pdev, shost) is done in aac_probe_one() far after bailing out with error from calling the init function ((*aac_drivers[index].init)(aac)), and when the init function fails, no error is returned from aac_probe_one() so PCI layer assumes there is driver attached, and tries to shut it down later.

Fix it by returning error from aac_probe_one() when card-specific init function fails.

This fixes reboot on my HP NetRAID-4M with dead battery.

Signed-off-by Meelis Roos <[email protected]>

Reviewed-by Dave Carroll <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/aacraid/linit.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

drivers/scsi/aacraid/linit.c +3 -1

@@ -1189,8 +1189,10 @@ static int aac_probe_one(struct pci_dev
 	 *	Map in the registers from the adapter.
 	 */
 	aac->base_size = AAC_MIN_FOOTPRINT_SIZE;
-	if ((*aac_drivers[index].init)(aac))
+	if ((*aac_drivers[index].init)(aac)) {
+		error = -ENODEV;
 		goto out_unmap;
+	}
 
 	if (aac->sync_mode) {
 		if (aac_sync_mode)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:00 UTC #97 lore raw

PATCH 84/268 scsi: qla4xxx: skip error recovery in case of register disconnect.

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

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

From: Manish Rangankar <[email protected]>

[ Upstream commit 1bc5ad3a6acdcf56f83272f2de1cd2389ea9e9e2 ]

A system crashes when continuously removing/re-adding the storage controller.

Signed-off-by Manish Rangankar <[email protected]>

Reviewed-by Ewan D. Milne <[email protected]>

Reviewed-by Tomas Henzl <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/qla4xxx/ql4_def.h |    2 +
 drivers/scsi/qla4xxx/ql4_os.c  |   46 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 48 insertions(+)

drivers/scsi/qla4xxx/ql4_def.h +2 -0

@@ -168,6 +168,8 @@
 #define DEV_DB_NON_PERSISTENT	0
 #define DEV_DB_PERSISTENT	1
 
+#define QL4_ISP_REG_DISCONNECT 0xffffffffU
+
 #define COPY_ISID(dst_isid, src_isid) {			\
 	int i, j;					\
 	for (i = 0, j = ISID_SIZE - 1; i < ISID_SIZE;)	\

drivers/scsi/qla4xxx/ql4_os.c +46 -0

95 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #98 lore raw

PATCH 85/268 ARM: OMAP2+: timer: fix a kmemleak caused in omap_get_timer_dt

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

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

From: Qi Hou <[email protected]>

[ Upstream commit db35340c536f1af0108ec9a0b2126a05d358d14a ]

When more than one GP timers are used as kernel system timers and the corresponding nodes in device-tree are marked with the same "disabled" property, then the "attr" field of the property will be initialized more than once as the property being added to sys file system via __of_add_property_sysfs().

In __of_add_property_sysfs(), the "name" field of pp->attr.attr is set directly to the return value of safe_name(), without taking care of whether it's already a valid pointer to a memory block. If it is, its old value will always be overwritten by the new one and the memory block allocated before will a "ghost", then a kmemleak happened.

That the same "disabled" property being added to different nodes of device tree would cause that kind of kmemleak overhead, at least once.

To fix it, allocate the property dynamically, and delete static one.

Signed-off-by Qi Hou <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/arm/mach-omap2/timer.c |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

arch/arm/mach-omap2/timer.c +11 -8

@@ -136,12 +136,6 @@ static struct clock_event_device clockev
 	.tick_resume		= omap2_gp_timer_shutdown,
 };
 
-static struct property device_disabled = {
-	.name = "status",
-	.length = sizeof("disabled"),
-	.value = "disabled",
-};
-
 static const struct of_device_id omap_timer_match[] __initconst = {
 	{ .compatible = "ti,omap2420-timer", },
 	{ .compatible = "ti,omap3430-timer", },

@@ -183,8 +177,17 @@ static struct device_node * __init omap_
 				  of_get_property(np, "ti,timer-secure", NULL)))
 			continue;
 
-		if (!of_device_is_compatible(np, "ti,omap-counter32k"))
-			of_add_property(np, &device_disabled);
+		if (!of_device_is_compatible(np, "ti,omap-counter32k")) {
+			struct property *prop;
+
+			prop = kzalloc(sizeof(*prop), GFP_KERNEL);
+			if (!prop)
+				return NULL;
+			prop->name = "status";
+			prop->value = "disabled";
+			prop->length = strlen(prop->value);
+			of_add_property(np, prop);
+		}
 		return np;
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #99 lore raw

PATCH 86/268 ARM: OMAP3: Fix prm wake interrupt for resume

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

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

From: Tony Lindgren <[email protected]>

[ Upstream commit d3be6d2a08bd26580562d9714d3d97ea9ba22c73 ]

For platform_suspend_ops, the finish call is too late to re-enable wake irqs and we need re-enable wake irqs on wake call instead.

Otherwise noirq resume for devices has already happened. And then dev_pm_disarm_wake_irq() has already disabled the dedicated wake irqs when the interrupt triggers and the wake irq is never handled.

For devices that are already in PM runtime suspended state when we enter suspend this means that a possible wake irq will never trigger.

And this can lead into a situation where a device has a pending padconf wake irq, and the device will stay unresponsive to any further wake irqs.

This issue can be easily reproduced by setting serial console log level to zero, letting the serial console idle, and suspend the system from an ssh terminal. Then try to wake up the system by typing to the serial console.

Note that this affects only omap3 PRM interrupt as that's currently the only omap variant that does anything in omap_pm_wake().

In general, for the wake irqs to work, the interrupt must have either IRQF_NO_SUSPEND or IRQF_EARLY_RESUME set for it to trigger before dev_pm_disarm_wake_irq() disables the wake irqs.

Reported-by Grygorii Strashko <[email protected]>

Cc Tero Kristo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/arm/mach-omap2/pm.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

arch/arm/mach-omap2/pm.c +2 -2

@@ -231,7 +231,7 @@ static void omap_pm_end(void)
 	cpu_idle_poll_ctrl(false);
 }
 
-static void omap_pm_finish(void)
+static void omap_pm_wake(void)
 {
 	if (cpu_is_omap34xx())
 		omap_prcm_irq_complete();

@@ -241,7 +241,7 @@ static const struct platform_suspend_ops
 	.begin		= omap_pm_begin,
 	.end		= omap_pm_end,
 	.enter		= omap_pm_enter,
-	.finish		= omap_pm_finish,
+	.wake		= omap_pm_wake,
 	.valid		= suspend_valid_only_mem,
 };

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #100 lore raw

PATCH 87/268 ARM: OMAP1: clock: Fix debugfs_create_*() usage

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

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

From: Geert Uytterhoeven <[email protected]>

[ Upstream commit 8cbbf1745dcde7ba7e423dc70619d223de90fd43 ]

When exposing data access through debugfs, the correct debugfs_create_*() functions must be used, depending on data type.

Remove all casts from data pointers passed to debugfs_create_*() functions, as such casts prevent the compiler from flagging bugs.

Correct all wrong usage:
- clk.rate is unsigned long, not u32,
- clk.flags is u8, not u32, which exposed the successive clk.rate_offset and clk.src_offset fields.

Signed-off-by Geert Uytterhoeven <[email protected]>

Acked-by Aaro Koskinen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/arm/mach-omap1/clock.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm/mach-omap1/clock.c +3 -3

@@ -1031,17 +1031,17 @@ static int clk_debugfs_register_one(stru
 		return -ENOMEM;
 	c->dent = d;
 
-	d = debugfs_create_u8("usecount", S_IRUGO, c->dent, (u8 *)&c->usecount);
+	d = debugfs_create_u8("usecount", S_IRUGO, c->dent, &c->usecount);
 	if (!d) {
 		err = -ENOMEM;
 		goto err_out;
 	}
-	d = debugfs_create_u32("rate", S_IRUGO, c->dent, (u32 *)&c->rate);
+	d = debugfs_create_ulong("rate", S_IRUGO, c->dent, &c->rate);
 	if (!d) {
 		err = -ENOMEM;
 		goto err_out;
 	}
-	d = debugfs_create_x32("flags", S_IRUGO, c->dent, (u32 *)&c->flags);
+	d = debugfs_create_x8("flags", S_IRUGO, c->dent, &c->flags);
 	if (!d) {
 		err = -ENOMEM;
 		goto err_out;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #101 lore raw

PATCH 88/268 NFC: llcp: Limit size of SDP URI

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

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

From: Kees Cook <[email protected]>

[ Upstream commit fe9c842695e26d8116b61b80bfb905356f07834b ]

The tlv_len is u8, so we need to limit the size of the SDP URI. Enforce this both in the NLA policy and in the code that performs the allocation and copy, to avoid writing past the end of the allocated buffer.

Fixes d9b8d8e19b073 ("NFC: llcp: Service Name Lookup netlink interface")

Signed-off-by Kees Cook <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/nfc/llcp_commands.c |    4 ++++
 net/nfc/netlink.c       |    3 ++-
 2 files changed, 6 insertions(+), 1 deletion(-)

net/nfc/llcp_commands.c +4 -0

@@ -149,6 +149,10 @@ struct nfc_llcp_sdp_tlv *nfc_llcp_build_
 
 	pr_debug("uri: %s, len: %zu\n", uri, uri_len);
 
+	/* sdreq->tlv_len is u8, takes uri_len, + 3 for header, + 1 for NULL */
+	if (WARN_ON_ONCE(uri_len > U8_MAX - 4))
+		return NULL;
+
 	sdreq = kzalloc(sizeof(struct nfc_llcp_sdp_tlv), GFP_KERNEL);
 	if (sdreq == NULL)
 		return NULL;

net/nfc/netlink.c +2 -1

@@ -68,7 +68,8 @@ static const struct nla_policy nfc_genl_
 };
 
 static const struct nla_policy nfc_sdp_genl_policy[NFC_SDP_ATTR_MAX + 1] = {
-	[NFC_SDP_ATTR_URI] = { .type = NLA_STRING },
+	[NFC_SDP_ATTR_URI] = { .type = NLA_STRING,
+			       .len = U8_MAX - 4 },
 	[NFC_SDP_ATTR_SAP] = { .type = NLA_U8 },
 };

Greg Kroah-Hartman

author maintainer

2018-05-28 10:17 UTC #102 lore raw

PATCH 89/268 mac80211: round IEEE80211_TX_STATUS_HEADROOM up to multiple of 4

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

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

From: Felix Fietkau <[email protected]>

[ Upstream commit 651b9920d7a694ffb1f885aef2bbb068a25d9d66 ]

This ensures that mac80211 allocated management frames are properly aligned, which makes copying them more efficient.
For instance, mt76 uses iowrite32_copy to copy beacon frames to beacon template memory on the chip.
Misaligned 32-bit accesses cause CPU exceptions on MIPS and should be avoided.

Signed-off-by Felix Fietkau <[email protected]>

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

include/net/mac80211.h +1 -1

@@ -3898,7 +3898,7 @@ static inline int ieee80211_sta_ps_trans
  * The TX headroom reserved by mac80211 for its own tx_status functions.
  * This is enough for the radiotap header.
  */
-#define IEEE80211_TX_STATUS_HEADROOM	14
+#define IEEE80211_TX_STATUS_HEADROOM	ALIGN(14, 4)
 
 /**
  * ieee80211_sta_set_buffered - inform mac80211 about driver-buffered frames

Greg Kroah-Hartman

author maintainer

2018-05-28 11:23 UTC #103 lore raw

PATCH 90/268 md raid10: fix NULL deference in handle_write_completed()

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

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

From: Yufen Yu <[email protected]>

[ Upstream commit 01a69cab01c184d3786af09e9339311123d63d22 ]

In the case of 'recover', an r10bio with R10BIO_WriteError & R10BIO_IsRecover will be progressed by handle_write_completed(). This function traverses all r10bio->devs[copies].
If devs[m].repl_bio != NULL, it thinks conf->mirrors[dev].replacement is also not NULL. However, this is not always true.

When there is an rdev of raid10 has replacement, then each r10bio ->devs[m].repl_bio != NULL in conf->r10buf_pool. However, in 'recover', even if corresponded replacement is NULL, it doesn't clear r10bio ->devs[m].repl_bio, resulting in replacement NULL deference.

This bug was introduced when replacement support for raid10 was added in Linux 3.3.

As NeilBrown suggested:
Elsewhere the determination of "is this device part of the resync/recovery" is made by resting bio->bi_end_io. If this is end_sync_write, then we tried to write here. If it is NULL, then we didn't try to write.

Fixes 9ad1aefc8ae8 ("md/raid10: Handle replacement devices during resync.")

Cc stable (V3.3+)

Suggested-by NeilBrown <[email protected]>

Signed-off-by Yufen Yu <[email protected]>

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

drivers/md/raid10.c +4 -2

@@ -2630,7 +2630,8 @@ static void handle_write_completed(struc
 		for (m = 0; m < conf->copies; m++) {
 			int dev = r10_bio->devs[m].devnum;
 			rdev = conf->mirrors[dev].rdev;
-			if (r10_bio->devs[m].bio == NULL)
+			if (r10_bio->devs[m].bio == NULL ||
+				r10_bio->devs[m].bio->bi_end_io == NULL)
 				continue;
 			if (!r10_bio->devs[m].bio->bi_error) {
 				rdev_clear_badblocks(

@@ -2645,7 +2646,8 @@ static void handle_write_completed(struc
 					md_error(conf->mddev, rdev);
 			}
 			rdev = conf->mirrors[dev].replacement;
-			if (r10_bio->devs[m].repl_bio == NULL)
+			if (r10_bio->devs[m].repl_bio == NULL ||
+				r10_bio->devs[m].repl_bio->bi_end_io == NULL)
 				continue;
 
 			if (!r10_bio->devs[m].repl_bio->bi_error) {

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #104 lore raw

PATCH 91/268 drm/exynos: fix comparison to bitshift when dealing with a mask

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

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

From: Wolfram Sang <[email protected]>

[ Upstream commit 1293b6191010672c0c9dacae8f71c6f3e4d70cbe ]

Due to a typo, the mask was destroyed by a comparison instead of a bit shift.

Signed-off-by Wolfram Sang <[email protected]>

Signed-off-by Inki Dae <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/gpu/drm/exynos/regs-fimc.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/gpu/drm/exynos/regs-fimc.h +1 -1

@@ -569,7 +569,7 @@
 #define EXYNOS_CIIMGEFF_FIN_EMBOSSING		(4 << 26)
 #define EXYNOS_CIIMGEFF_FIN_SILHOUETTE		(5 << 26)
 #define EXYNOS_CIIMGEFF_FIN_MASK			(7 << 26)
-#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK		((0xff < 13) | (0xff < 0))
+#define EXYNOS_CIIMGEFF_PAT_CBCR_MASK		((0xff << 13) | (0xff << 0))
 
 /* Real input DMA size register */
 #define EXYNOS_CIREAL_ISIZE_AUTOLOAD_ENABLE	(1 << 31)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #105 lore raw

PATCH 92/268 drm/exynos: g2d: Delete an error message for a failed memory allocation in two functions

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

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

From: Markus Elfring <[email protected]>

[ Upstream commit 6f0a60298bbbea43ab5e3955913ab19c153076f3 ]

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by Markus Elfring <[email protected]>

Signed-off-by Inki Dae <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/gpu/drm/exynos/exynos_drm_g2d.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

drivers/gpu/drm/exynos/exynos_drm_g2d.c +2 -4

@@ -270,7 +270,6 @@ static int g2d_init_cmdlist(struct g2d_d
 
 	node = kcalloc(G2D_CMDLIST_NUM, sizeof(*node), GFP_KERNEL);
 	if (!node) {
-		dev_err(dev, "failed to allocate memory\n");
 		ret = -ENOMEM;
 		goto err;
 	}

@@ -1254,10 +1253,9 @@ int exynos_g2d_exec_ioctl(struct drm_dev
 		return -EFAULT;
 
 	runqueue_node = kmem_cache_alloc(g2d->runqueue_slab, GFP_KERNEL);
-	if (!runqueue_node) {
-		dev_err(dev, "failed to allocate memory\n");
+	if (!runqueue_node)
 		return -ENOMEM;
-	}
+
 	run_cmdlist = &runqueue_node->run_cmdlist;
 	event_list = &runqueue_node->event_list;
 	INIT_LIST_HEAD(run_cmdlist);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #106 lore raw

PATCH 93/268 usb: musb: fix enumeration after resume

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

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

From: Andreas Kemnade <[email protected]>

[ Upstream commit 17539f2f4f0b7fa906b508765c8ada07a1e45f52 ]

On dm3730 there are enumeration problems after resume. Investigation led to the cause that the MUSB_POWER_SOFTCONN bit is not set. If it was set before suspend (because it was enabled via musb_pullup()), it is set in musb_restore_context() so the pullup is enabled. But then musb_start() is called which overwrites MUSB_POWER and therefore disables MUSB_POWER_SOFTCONN, so no pullup is enabled and the device is not enumerated.

So let's do a subset of what musb_start() does
in the same way as musb_suspend() does it. Platform-specific stuff it still called as there might be some phy-related stuff which needs to be enabled.
Also interrupts are enabled, as it was the original idea of calling musb_start() in musb_resume() according to Commit 6fc6f4b87cb3 ("usb: musb: Disable interrupts on suspend, enable them on resume")

Signed-off-by Andreas Kemnade <[email protected]>

Tested-by Tony Lindgren <[email protected]>

Signed-off-by Bin Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/usb/musb/musb_core.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/usb/musb/musb_core.c +2 -1

@@ -2522,7 +2522,8 @@ static int musb_resume(struct device *de
 	pm_runtime_set_active(dev);
 	pm_runtime_enable(dev);
 
-	musb_start(musb);
+	musb_enable_interrupts(musb);
+	musb_platform_enable(musb);
 
 	return 0;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #107 lore raw

PATCH 94/268 locking/xchg/alpha: Add unconditional memory barrier to cmpxchg()

[1] https://marc.info/?l=linux-kernel&m=150884953419377&w=2

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

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

From: Andrea Parri <[email protected]>

[ Upstream commit cb13b424e986aed68d74cbaec3449ea23c50e167 ]

Continuing along with the fight against smp_read_barrier_depends() [1] (or rather, against its improper use), add an unconditional barrier to cmpxchg. This guarantees that dependency ordering is preserved when a dependency is headed by an unsuccessful cmpxchg. As it turns out, the change could enable further simplification of LKMM as proposed in [2].

    https://marc.info/?l=linux-kernel&m=150884946319353&w=2
    https://marc.info/?l=linux-kernel&m=151215810824468&w=2
    https://marc.info/?l=linux-kernel&m=151215816324484&w=2

[2] https://marc.info/?l=linux-kernel&m=151881978314872&w=2

Signed-off-by Andrea Parri <[email protected]>

Acked-by Peter Zijlstra <[email protected]>

Acked-by Paul E. McKenney <[email protected]>

Cc Alan Stern <[email protected]>

Cc Ivan Kokshaysky <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Matt Turner <[email protected]>

Cc Richard Henderson <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Will Deacon <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/alpha/include/asm/xchg.h |   15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

arch/alpha/include/asm/xchg.h +7 -8

@@ -127,10 +127,9 @@ ____xchg(, volatile void *ptr, unsigned
  * store NEW in MEM.  Return the initial value in MEM.  Success is
  * indicated by comparing RETURN with OLD.
  *
- * The memory barrier should be placed in SMP only when we actually
- * make the change. If we don't change anything (so if the returned
- * prev is equal to old) then we aren't acquiring anything new and
- * we don't need any memory barrier as far I can tell.
+ * The memory barrier is placed in SMP unconditionally, in order to
+ * guarantee that dependency ordering is preserved when a dependency
+ * is headed by an unsuccessful operation.
  */
 
 static inline unsigned long

@@ -149,8 +148,8 @@ ____cmpxchg(_u8, volatile char *m, unsig
 	"	or	%1,%2,%2\n"
 	"	stq_c	%2,0(%4)\n"
 	"	beq	%2,3f\n"
-		__ASM__MB
 	"2:\n"
+		__ASM__MB
 	".subsection 2\n"
 	"3:	br	1b\n"
 	".previous"

@@ -176,8 +175,8 @@ ____cmpxchg(_u16, volatile short *m, uns
 	"	or	%1,%2,%2\n"
 	"	stq_c	%2,0(%4)\n"
 	"	beq	%2,3f\n"
-		__ASM__MB
 	"2:\n"
+		__ASM__MB
 	".subsection 2\n"
 	"3:	br	1b\n"
 	".previous"

@@ -199,8 +198,8 @@ ____cmpxchg(_u32, volatile int *m, int o
 	"	mov %4,%1\n"
 	"	stl_c %1,%2\n"
 	"	beq %1,3f\n"
-		__ASM__MB
 	"2:\n"
+		__ASM__MB
 	".subsection 2\n"
 	"3:	br 1b\n"
 	".previous"

@@ -222,8 +221,8 @@ ____cmpxchg(_u64, volatile long *m, unsi
 	"	mov %4,%1\n"
 	"	stq_c %1,%2\n"
 	"	beq %1,3f\n"
-		__ASM__MB
 	"2:\n"
+		__ASM__MB
 	".subsection 2\n"
 	"3:	br 1b\n"
 	".previous"

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #108 lore raw

PATCH 95/268 md: raid5: avoid string overflow warning

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

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

From: Arnd Bergmann <[email protected]>

[ Upstream commit 53b8d89ddbdbb0e4625a46d2cdbb6f106c52f801 ]

gcc warns about a possible overflow of the kmem_cache string, when adding four characters to a string of the same length:

drivers/md/raid5.c: In function 'setup_conf':
drivers/md/raid5.c:2207:34: error: '-alt' directive writing 4 bytes into a region of size between 1 and 32 [-Werror=format-overflow=]

  sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]);
                                  ^~~~

drivers/md/raid5.c:2207:2: note: 'sprintf' output between 5 and 36 bytes into a destination of size 32
sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If I'm counting correctly, we need 11 characters for the fixed part of the string and 18 characters for a 64-bit pointer (when no gendisk is used), so that leaves three characters for conf->level, which should always be sufficient.

This makes the code use snprintf() with the correct length, to make the code more robust against changes, and to get the compiler to shut up.

In commit f4be6b43f1ac ("md/raid5: ensure we create a unique name for kmem_cache when mddev has no gendisk") from 2010, Neil said that the pointer could be removed "shortly" once devices without gendisk are disallowed. I have no idea if that happened, but if it did, that should probably be changed as well.

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

drivers/md/raid5.c +4 -3

@@ -2028,15 +2028,16 @@ static int grow_one_stripe(struct r5conf
 static int grow_stripes(struct r5conf *conf, int num)
 {
 	struct kmem_cache *sc;
+	size_t namelen = sizeof(conf->cache_name[0]);
 	int devs = max(conf->raid_disks, conf->previous_raid_disks);
 
 	if (conf->mddev->gendisk)
-		sprintf(conf->cache_name[0],
+		snprintf(conf->cache_name[0], namelen,
 			"raid%d-%s", conf->level, mdname(conf->mddev));
 	else
-		sprintf(conf->cache_name[0],
+		snprintf(conf->cache_name[0], namelen,
 			"raid%d-%p", conf->level, conf->mddev);
-	sprintf(conf->cache_name[1], "%s-alt", conf->cache_name[0]);
+	snprintf(conf->cache_name[1], namelen, "%.27s-alt", conf->cache_name[0]);
 
 	conf->active_name = 0;
 	sc = kmem_cache_create(conf->cache_name[conf->active_name],

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #109 lore raw

PATCH 96/268 kernel/relay.c: limit kmalloc size to KMALLOC_MAX_SIZE

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

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

From: David Rientjes <[email protected]>

[ Upstream commit 88913bd8ea2a75d7e460a4bed5f75e1c32660d7e ]

chan->n_subbufs is set by the user and relay_create_buf() does a kmalloc() of chan->n_subbufs * sizeof(size_t *).

kmalloc_slab() will generate a warning when this fails if chan->subbufs * sizeof(size_t *) > KMALLOC_MAX_SIZE.

Limit chan->n_subbufs to the maximum allowed kmalloc() size.

Link http://lkml.kernel.org/r/[email protected] open here

Fixes f6302f1bcd75 ("relay: prevent integer overflow in relay_open()")

Signed-off-by David Rientjes <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Jens Axboe <[email protected]>

Cc Dave Jiang <[email protected]>

Cc Al Viro <[email protected]>

Cc Dan Carpenter <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 kernel/relay.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

kernel/relay.c +1 -1

@@ -163,7 +163,7 @@ static struct rchan_buf *relay_create_bu
 {
 	struct rchan_buf *buf;
 
-	if (chan->n_subbufs > UINT_MAX / sizeof(size_t *))
+	if (chan->n_subbufs > KMALLOC_MAX_SIZE / sizeof(size_t *))
 		return NULL;
 
 	buf = kzalloc(sizeof(struct rchan_buf), GFP_KERNEL);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #110 lore raw

PATCH 97/268 powerpc/bpf/jit: Fix 32-bit JIT for seccomp_data access

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

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

From: Mark Lord <[email protected]>

[ Upstream commit 083b20907185b076f21c265b30fe5b5f24c03d8c ]

I am using SECCOMP to filter syscalls on a ppc32 platform, and noticed that the JIT compiler was failing on the BPF even though the interpreter was working fine.

The issue was that the compiler was missing one of the instructions used by SECCOMP, so here is a patch to enable JIT for that instruction.

Fixes eb84bab0fb38 ("ppc: Kconfig: Enable BPF JIT on ppc32")

Signed-off-by Mark Lord <[email protected]>

Acked-by Naveen N. Rao <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

arch/powerpc/net/bpf_jit_comp.c +3 -0

@@ -329,6 +329,9 @@ static int bpf_jit_build_body(struct bpf
 			BUILD_BUG_ON(FIELD_SIZEOF(struct sk_buff, len) != 4);
 			PPC_LWZ_OFFS(r_A, r_skb, offsetof(struct sk_buff, len));
 			break;
+		case BPF_LDX | BPF_W | BPF_ABS: /* A = *((u32 *)(seccomp_data + K)); */
+			PPC_LWZ_OFFS(r_A, r_skb, K);
+			break;
 		case BPF_LDX | BPF_W | BPF_LEN: /* X = skb->len; */
 			PPC_LWZ_OFFS(r_X, r_skb, offsetof(struct sk_buff, len));
 			break;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #111 lore raw

PATCH 98/268 s390/cio: fix return code after missing interrupt

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

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

From: Sebastian Ott <[email protected]>

[ Upstream commit 770b55c995d171f026a9efb85e71e3b1ea47b93d ]

When a timeout occurs for users of ccw_device_start_timeout we will stop the IO and call the drivers int handler with the irb pointer set to ERR_PTR(-ETIMEDOUT). Sometimes however we'd set the irb pointer to ERR_PTR(-EIO) which is not intended. Just set the correct value in all codepaths.

Reported-by Julian Wiedmann <[email protected]>

Signed-off-by Sebastian Ott <[email protected]>

Signed-off-by Martin Schwidefsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/s390/cio/device_fsm.c |    6 ++++--
 drivers/s390/cio/io_sch.h     |    1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

drivers/s390/cio/device_fsm.c +4 -2

@@ -822,6 +822,7 @@ ccw_device_online_timeout(struct ccw_dev
 
 	ccw_device_set_timeout(cdev, 0);
 	cdev->private->iretry = 255;
+	cdev->private->async_kill_io_rc = -ETIMEDOUT;
 	ret = ccw_device_cancel_halt_clear(cdev);
 	if (ret == -EBUSY) {
 		ccw_device_set_timeout(cdev, 3*HZ);

@@ -898,7 +899,7 @@ ccw_device_killing_irq(struct ccw_device
 	/* OK, i/o is dead now. Call interrupt handler. */
 	if (cdev->handler)
 		cdev->handler(cdev, cdev->private->intparm,
-			      ERR_PTR(-EIO));
+			      ERR_PTR(cdev->private->async_kill_io_rc));
 }
 
 static void

@@ -915,7 +916,7 @@ ccw_device_killing_timeout(struct ccw_de
 	ccw_device_online_verify(cdev, 0);
 	if (cdev->handler)
 		cdev->handler(cdev, cdev->private->intparm,
-			      ERR_PTR(-EIO));
+			      ERR_PTR(cdev->private->async_kill_io_rc));
 }
 
 void ccw_device_kill_io(struct ccw_device *cdev)

@@ -923,6 +924,7 @@ void ccw_device_kill_io(struct ccw_devic
 	int ret;
 
 	cdev->private->iretry = 255;
+	cdev->private->async_kill_io_rc = -EIO;
 	ret = ccw_device_cancel_halt_clear(cdev);
 	if (ret == -EBUSY) {
 		ccw_device_set_timeout(cdev, 3*HZ);

drivers/s390/cio/io_sch.h +1 -0

@@ -155,6 +155,7 @@ struct ccw_device_private {
 	unsigned long intparm;	/* user interruption parameter */
 	struct qdio_irq *qdio_data;
 	struct irb irb;		/* device status */
+	int async_kill_io_rc;
 	struct senseid senseid;	/* SenseID info */
 	struct pgid pgid[8];	/* path group IDs per chpid*/
 	struct ccw1 iccws[2];	/* ccws for SNID/SID/SPGID commands */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #112 lore raw

PATCH 99/268 s390/cio: clear timer when terminating driver I/O

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

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

From: Sebastian Ott <[email protected]>

[ Upstream commit 410d5e13e7638bc146321671e223d56495fbf3c7 ]

When we terminate driver I/O (because we need to stop using a certain channel path) we also need to ensure that a timer (which may have been set up using ccw_device_start_timeout) is cleared.

Signed-off-by Sebastian Ott <[email protected]>

Signed-off-by Martin Schwidefsky <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/s390/cio/device_fsm.c |    1 +
 1 file changed, 1 insertion(+)

drivers/s390/cio/device_fsm.c +1 -0

@@ -923,6 +923,7 @@ void ccw_device_kill_io(struct ccw_devic
 {
 	int ret;
 
+	ccw_device_set_timeout(cdev, 0);
 	cdev->private->iretry = 255;
 	cdev->private->async_kill_io_rc = -EIO;
 	ret = ccw_device_cancel_halt_clear(cdev);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #113 lore raw

PATCH 100/268 ARM: OMAP: Fix dmtimer init for omap1

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

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

From: Tony Lindgren <[email protected]>

[ Upstream commit ba6887836178d43b3665b9da075c2c5dfe1d207c ]

We need to enable PM runtime on omap1 also as otherwise we will get errors:

omap_timer omap_timer.1: omap_dm_timer_probe: pm_runtime_get_sync failed!
omap_timer: probe of omap_timer.1 failed with error -13
...

We are checking for OMAP_TIMER_NEEDS_RESET flag elsewhere so this is safe to do.

Cc Aaro Koskinen <[email protected]>

Cc Keerthy <[email protected]>

Cc Ladislav Michl <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/arm/plat-omap/dmtimer.c |    7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

arch/arm/plat-omap/dmtimer.c +2 -5

@@ -854,11 +854,8 @@ static int omap_dm_timer_probe(struct pl
 	timer->irq = irq->start;
 	timer->pdev = pdev;
 
-	/* Skip pm_runtime_enable for OMAP1 */
-	if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
-		pm_runtime_enable(dev);
-		pm_runtime_irq_safe(dev);
-	}
+	pm_runtime_enable(dev);
+	pm_runtime_irq_safe(dev);
 
 	if (!timer->reserved) {
 		ret = pm_runtime_get_sync(dev);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #114 lore raw

PATCH 101/268 smsc75xx: fix smsc75xx_set_features()

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 88e80c62671ceecdbb77c902731ec95a4bfa62f9 ]

If an attempt is made to disable RX checksums, USB adapter is changed but netdev->features is not, because smsc75xx_set_features() returns a non zero value.

This throws errors from netdev_rx_csum_fault() :
<devname>: hw csum failure

Signed-off-by Eric Dumazet <[email protected]>

Cc Steve Glendinning <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/usb/smsc75xx.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

drivers/net/usb/smsc75xx.c +4 -3

@@ -945,10 +945,11 @@ static int smsc75xx_set_features(struct
 	/* it's racing here! */
 
 	ret = smsc75xx_write_reg(dev, RFE_CTL, pdata->rfe_ctl);
-	if (ret < 0)
+	if (ret < 0) {
 		netdev_warn(dev->net, "Error writing RFE_CTL\n");
-
-	return ret;
+		return ret;
+	}
+	return 0;
 }
 
 static int smsc75xx_wait_ready(struct usbnet *dev, int in_pm)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #115 lore raw

PATCH 102/268 regulatory: add NUL to request alpha2

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

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

From: Johannes Berg <[email protected]>

[ Upstream commit 657308f73e674e86b60509a430a46e569bf02846 ]

Similar to the ancient commit a5fe8e7695dc ("regulatory: add NUL to alpha2"), add another byte to alpha2 in the request struct so that when we use nla_put_string(), we don't overrun anything.

Fixes 73d54c9e74c4 ("cfg80211: add regulatory netlink multicast group")

Reported-by Kees Cook <[email protected]>

Signed-off-by Johannes Berg <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

include/net/regulatory.h +1 -1

@@ -78,7 +78,7 @@ struct regulatory_request {
 	int wiphy_idx;
 	enum nl80211_reg_initiator initiator;
 	enum nl80211_user_reg_hint_type user_reg_hint_type;
-	char alpha2[2];
+	char alpha2[3];
 	enum nl80211_dfs_regions dfs_region;
 	bool intersect;
 	bool processed;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #116 lore raw

PATCH 103/268 locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs

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

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

From: Andrea Parri <[email protected]>

[ Upstream commit 472e8c55cf6622d1c112dc2bc777f68bbd4189db ]

Successful RMW operations are supposed to be fully ordered, but Alpha's xchg() and cmpxchg() do not meet this requirement.

Will Deacon noticed the bug:

Quoted 9 lines

So MP using xchg:
WRITE_ONCE(x, 1)
xchg(y, 1)
smp_load_acquire(y) == 1
READ_ONCE(x) == 0
would be allowed.

... which thus violates the above requirement.

Fix it by adding a leading smp_mb() to the xchg() and cmpxchg() implementations.

Reported-by Will Deacon <[email protected]>

Signed-off-by Andrea Parri <[email protected]>

Acked-by Paul E. McKenney <[email protected]>

Cc Alan Stern <[email protected]>

Cc Andrew Morton <[email protected]>

Cc Ivan Kokshaysky <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Matt Turner <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Richard Henderson <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/alpha/include/asm/xchg.h |   21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

arch/alpha/include/asm/xchg.h +18 -3

@@ -11,6 +11,10 @@
  * Atomic exchange.
  * Since it can be used to implement critical sections
  * it must clobber "memory" (also for interrupts in UP).
+ *
+ * The leading and the trailing memory barriers guarantee that these
+ * operations are fully ordered.
+ *
  */
 
 static inline unsigned long

@@ -18,6 +22,7 @@ ____xchg(_u8, volatile char *m, unsigned
 {
 	unsigned long ret, tmp, addr64;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"	andnot	%4,7,%3\n"
 	"	insbl	%1,%4,%1\n"

@@ -42,6 +47,7 @@ ____xchg(_u16, volatile short *m, unsign
 {
 	unsigned long ret, tmp, addr64;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"	andnot	%4,7,%3\n"
 	"	inswl	%1,%4,%1\n"

@@ -66,6 +72,7 @@ ____xchg(_u32, volatile int *m, unsigned
 {
 	unsigned long dummy;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"1:	ldl_l %0,%4\n"
 	"	bis $31,%3,%1\n"

@@ -86,6 +93,7 @@ ____xchg(_u64, volatile long *m, unsigne
 {
 	unsigned long dummy;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"1:	ldq_l %0,%4\n"
 	"	bis $31,%3,%1\n"

@@ -127,9 +135,12 @@ ____xchg(, volatile void *ptr, unsigned
  * store NEW in MEM.  Return the initial value in MEM.  Success is
  * indicated by comparing RETURN with OLD.
  *
- * The memory barrier is placed in SMP unconditionally, in order to
- * guarantee that dependency ordering is preserved when a dependency
- * is headed by an unsuccessful operation.
+ * The leading and the trailing memory barriers guarantee that these
+ * operations are fully ordered.
+ *
+ * The trailing memory barrier is placed in SMP unconditionally, in
+ * order to guarantee that dependency ordering is preserved when a
+ * dependency is headed by an unsuccessful operation.
  */
 
 static inline unsigned long

@@ -137,6 +148,7 @@ ____cmpxchg(_u8, volatile char *m, unsig
 {
 	unsigned long prev, tmp, cmp, addr64;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"	andnot	%5,7,%4\n"
 	"	insbl	%1,%5,%1\n"

@@ -164,6 +176,7 @@ ____cmpxchg(_u16, volatile short *m, uns
 {
 	unsigned long prev, tmp, cmp, addr64;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"	andnot	%5,7,%4\n"
 	"	inswl	%1,%5,%1\n"

@@ -191,6 +204,7 @@ ____cmpxchg(_u32, volatile int *m, int o
 {
 	unsigned long prev, cmp;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"1:	ldl_l %0,%5\n"
 	"	cmpeq %0,%3,%1\n"

@@ -214,6 +228,7 @@ ____cmpxchg(_u64, volatile long *m, unsi
 {
 	unsigned long prev, cmp;
 
+	smp_mb();
 	__asm__ __volatile__(
 	"1:	ldq_l %0,%5\n"
 	"	cmpeq %0,%3,%1\n"

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #117 lore raw

PATCH 104/268 x86/topology: Update the cpu cores field in /proc/cpuinfo correctly across CPU hotplug operations

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

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

From: Samuel Neves <[email protected]>

[ Upstream commit 4596749339e06dc7a424fc08a15eded850ed78b7 ]

Without this fix, /proc/cpuinfo will display an incorrect amount of CPU cores, after bringing them offline and online again, as exemplified below:

  $ cat /proc/cpuinfo | grep cores
  cpu cores	: 4
  cpu cores	: 8
  cpu cores	: 8
  cpu cores	: 20
  cpu cores	: 4
  cpu cores	: 3
  cpu cores	: 2
  cpu cores	: 2

This patch fixes this by always zeroing the booted_cores variable upon turning off a logical CPU.

Tested-by Dou Liyang <[email protected]>

Signed-off-by Samuel Neves <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Thomas Gleixner <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/x86/kernel/smpboot.c |    1 +
 1 file changed, 1 insertion(+)

arch/x86/kernel/smpboot.c +1 -0

@@ -1344,6 +1344,7 @@ static void remove_siblinginfo(int cpu)
 	cpumask_clear(topology_core_cpumask(cpu));
 	c->phys_proc_id = 0;
 	c->cpu_core_id = 0;
+	c->booted_cores = 0;
 	cpumask_clear_cpu(cpu, cpu_sibling_setup_mask);
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #118 lore raw

PATCH 105/268 media: dmxdev: fix error code for invalid ioctls

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

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

From: Mauro Carvalho Chehab <[email protected]>

[ Upstream commit a145f64c6107d3aa5a7cec9f8977d04ac2a896c9 ]

Returning -EINVAL when an ioctl is not implemented is a very bad idea, as it is hard to distinguish from other error contitions that an ioctl could lead. Replace it by its right error code: -ENOTTY.

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/media/dvb-core/dmxdev.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/media/dvb-core/dmxdev.c +1 -1

@@ -1071,7 +1071,7 @@ static int dvb_demux_do_ioctl(struct fil
 		break;
 
 	default:
-		ret = -EINVAL;
+		ret = -ENOTTY;
 		break;
 	}
 	mutex_unlock(&dmxdev->mutex);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #119 lore raw

PATCH 106/268 md/raid1: fix NULL pointer dereference

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

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

From: Yufen Yu <[email protected]>

[ Upstream commit 3de59bb9d551428cbdc76a9ea57883f82e350b4d ]

In handle_write_finished(), if r1_bio->bios[m] != NULL, it thinks the corresponding conf->mirrors[m].rdev is also not NULL. But, it is not always true.

Even if some io hold replacement rdev(i.e. rdev->nr_pending.count > 0), raid1_remove_disk() can also set the rdev as NULL. That means, bios[m] != NULL, but mirrors[m].rdev is NULL, resulting in NULL pointer dereference in handle_write_finished and sync_request_write.

This patch can fix BUGs as follows:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000140
 IP: [<ffffffff815bbbbd>] raid1d+0x2bd/0xfc0
 PGD 12ab52067 PUD 12f587067 PMD 0
 Oops: 0000 [#1] SMP
 CPU: 1 PID: 2008 Comm: md3_raid1 Not tainted 4.1.44+ #130
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
 Call Trace:
  ? schedule+0x37/0x90
  ? prepare_to_wait_event+0x83/0xf0
  md_thread+0x144/0x150
  ? wake_atomic_t_function+0x70/0x70
  ? md_start_sync+0xf0/0xf0
  kthread+0xd8/0xf0
  ? kthread_worker_fn+0x160/0x160
  ret_from_fork+0x42/0x70
  ? kthread_worker_fn+0x160/0x160

 BUG: unable to handle kernel NULL pointer dereference at 00000000000000b8
 IP: sync_request_write+0x9e/0x980
 PGD 800000007c518067 P4D 800000007c518067 PUD 8002b067 PMD 0
 Oops: 0000 [#1] SMP PTI
 CPU: 24 PID: 2549 Comm: md3_raid1 Not tainted 4.15.0+ #118
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc26 04/01/2014
 Call Trace:
  ? sched_clock+0x5/0x10
  ? sched_clock_cpu+0xc/0xb0
  ? flush_pending_writes+0x3a/0xd0
  ? pick_next_task_fair+0x4d5/0x5f0
  ? __switch_to+0xa2/0x430
  raid1d+0x65a/0x870
  ? find_pers+0x70/0x70
  ? find_pers+0x70/0x70
  ? md_thread+0x11c/0x160
  md_thread+0x11c/0x160
  ? finish_wait+0x80/0x80
  kthread+0x111/0x130
  ? kthread_create_worker_on_cpu+0x70/0x70
  ? do_syscall_64+0x6f/0x190
  ? SyS_exit_group+0x10/0x10
  ret_from_fork+0x35/0x40

Reviewed-by NeilBrown <[email protected]>

Signed-off-by Yufen Yu <[email protected]>

Signed-off-by Shaohua Li <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/md/raid1.c |   11 +++++++++++
 1 file changed, 11 insertions(+)

drivers/md/raid1.c +11 -0

@@ -1686,6 +1686,17 @@ static int raid1_remove_disk(struct mdde
 			struct md_rdev *repl =
 				conf->mirrors[conf->raid_disks + number].rdev;
 			freeze_array(conf, 0);
+			if (atomic_read(&repl->nr_pending)) {
+				/* It means that some queued IO of retry_list
+				 * hold repl. Thus, we cannot set replacement
+				 * as NULL, avoiding rdev NULL pointer
+				 * dereference in sync_request_write and
+				 * handle_write_finished.
+				 */
+				err = -EBUSY;
+				unfreeze_array(conf);
+				goto abort;
+			}
 			clear_bit(Replacement, &repl->flags);
 			p->rdev = repl;
 			conf->mirrors[conf->raid_disks + number].rdev = NULL;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #120 lore raw

PATCH 107/268 batman-adv: fix packet checksum in receive path

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

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

From: Matthias Schiffer <[email protected]>

[ Upstream commit abd6360591d3f8259f41c34e31ac4826dfe621b8 ]

eth_type_trans() internally calls skb_pull(), which does not adjust the skb checksum; skb_postpull_rcsum() is necessary to avoid log spam of the form "bat0: hw csum failure" when packets with CHECKSUM_COMPLETE are received.

Note that in usual setups, packets don't reach batman-adv with CHECKSUM_COMPLETE (I assume NICs bail out of checksumming when they see batadv's ethtype?), which is why the log messages do not occur on every system using batman-adv. I could reproduce this issue by stacking batman-adv on top of a VXLAN interface.

Fixes c6c8fea29769 ("net: Add batman-adv meshing protocol")

Tested-by Maximilian Wilhelm <[email protected]>

Signed-off-by Matthias Schiffer <[email protected]>

Signed-off-by Sven Eckelmann <[email protected]>

Signed-off-by Simon Wunderlich <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/batman-adv/soft-interface.c |    8 +-------
 1 file changed, 1 insertion(+), 7 deletions(-)

net/batman-adv/soft-interface.c +1 -7

@@ -430,13 +430,7 @@ void batadv_interface_rx(struct net_devi
 
 	/* skb->dev & skb->pkt_type are set here */
 	skb->protocol = eth_type_trans(skb, soft_iface);
-
-	/* should not be necessary anymore as we use skb_pull_rcsum()
-	 * TODO: please verify this and remove this TODO
-	 * -- Dec 21st 2009, Simon Wunderlich
-	 */
-
-	/* skb->ip_summed = CHECKSUM_UNNECESSARY; */
+	skb_postpull_rcsum(skb, eth_hdr(skb), ETH_HLEN);
 
 	batadv_inc_counter(bat_priv, BATADV_CNT_RX);
 	batadv_add_counter(bat_priv, BATADV_CNT_RX_BYTES,

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #121 lore raw

PATCH 108/268 batman-adv: invalidate checksum on fragment reassembly

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

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

From: Matthias Schiffer <[email protected]>

[ Upstream commit 3bf2a09da956b43ecfaa630a2ef9a477f991a46a ]

A more sophisticated implementation could try to combine fragment checksums when all fragments have CHECKSUM_COMPLETE and are split at even offsets. For now, we just set ip_summed to CHECKSUM_NONE to avoid "hw csum failure" warnings in the kernel log when fragmented frames are received. In consequence, skb_pull_rcsum() can be replaced with skb_pull().

Fixes 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")

Tested-by Maximilian Wilhelm <[email protected]>

Signed-off-by Matthias Schiffer <[email protected]>

Signed-off-by Sven Eckelmann <[email protected]>

Signed-off-by Simon Wunderlich <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/batman-adv/fragmentation.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

net/batman-adv/fragmentation.c +2 -1

@@ -278,7 +278,8 @@ batadv_frag_merge_packets(struct hlist_h
 	/* Move the existing MAC header to just before the payload. (Override
 	 * the fragment header.)
 	 */
-	skb_pull_rcsum(skb_out, hdr_size);
+	skb_pull(skb_out, hdr_size);
+	skb_out->ip_summed = CHECKSUM_NONE;
 	memmove(skb_out->data - ETH_HLEN, skb_mac_header(skb_out), ETH_HLEN);
 	skb_set_mac_header(skb_out, -ETH_HLEN);
 	skb_reset_network_header(skb_out);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:18 UTC #122 lore raw

PATCH 109/268 netfilter: ebtables: convert BUG_ONs to WARN_ONs

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

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

From: Florian Westphal <[email protected]>

[ Upstream commit fc6a5d0601c5ac1d02f283a46f60b87b2033e5ca ]

All of these conditions are not fatal and should have been WARN_ONs from the get-go.

Convert them to WARN_ONs and bail out.

Signed-off-by Florian Westphal <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/bridge/netfilter/ebtables.c |   27 ++++++++++++++++++---------
 1 file changed, 18 insertions(+), 9 deletions(-)

net/bridge/netfilter/ebtables.c +18 -9

@@ -1614,7 +1614,8 @@ static int compat_match_to_user(struct e
 	int off = ebt_compat_match_offset(match, m->match_size);
 	compat_uint_t msize = m->match_size - off;
 
-	BUG_ON(off >= m->match_size);
+	if (WARN_ON(off >= m->match_size))
+		return -EINVAL;
 
 	if (copy_to_user(cm->u.name, match->name,
 	    strlen(match->name) + 1) || put_user(msize, &cm->match_size))

@@ -1641,7 +1642,8 @@ static int compat_target_to_user(struct
 	int off = xt_compat_target_offset(target);
 	compat_uint_t tsize = t->target_size - off;
 
-	BUG_ON(off >= t->target_size);
+	if (WARN_ON(off >= t->target_size))
+		return -EINVAL;
 
 	if (copy_to_user(cm->u.name, target->name,
 	    strlen(target->name) + 1) || put_user(tsize, &cm->match_size))

@@ -1869,7 +1871,8 @@ static int ebt_buf_add(struct ebt_entrie
 	if (state->buf_kern_start == NULL)
 		goto count_only;
 
-	BUG_ON(state->buf_kern_offset + sz > state->buf_kern_len);
+	if (WARN_ON(state->buf_kern_offset + sz > state->buf_kern_len))
+		return -EINVAL;
 
 	memcpy(state->buf_kern_start + state->buf_kern_offset, data, sz);

@@ -1882,7 +1885,8 @@ static int ebt_buf_add_pad(struct ebt_en
 {
 	char *b = state->buf_kern_start;
 
-	BUG_ON(b && state->buf_kern_offset > state->buf_kern_len);
+	if (WARN_ON(b && state->buf_kern_offset > state->buf_kern_len))
+		return -EINVAL;
 
 	if (b != NULL && sz > 0)
 		memset(b + state->buf_kern_offset, 0, sz);

@@ -1959,8 +1963,10 @@ static int compat_mtw_from_user(struct c
 	pad = XT_ALIGN(size_kern) - size_kern;
 
 	if (pad > 0 && dst) {
-		BUG_ON(state->buf_kern_len <= pad);
-		BUG_ON(state->buf_kern_offset - (match_size + off) + size_kern > state->buf_kern_len - pad);
+		if (WARN_ON(state->buf_kern_len <= pad))
+			return -EINVAL;
+		if (WARN_ON(state->buf_kern_offset - (match_size + off) + size_kern > state->buf_kern_len - pad))
+			return -EINVAL;
 		memset(dst + size_kern, 0, pad);
 	}
 	return off + match_size;

@@ -2011,7 +2017,8 @@ static int ebt_size_mwt(struct compat_eb
 		if (ret < 0)
 			return ret;
 
-		BUG_ON(ret < match32->match_size);
+		if (WARN_ON(ret < match32->match_size))
+			return -EINVAL;
 		growth += ret - match32->match_size;
 		growth += ebt_compat_entry_padsize();

@@ -2121,7 +2128,8 @@ static int size_entry_mwt(struct ebt_ent
 
 	startoff = state->buf_user_offset - startoff;
 
-	BUG_ON(*total < startoff);
+	if (WARN_ON(*total < startoff))
+		return -EINVAL;
 	*total -= startoff;
 	return 0;
 }

@@ -2249,7 +2257,8 @@ static int compat_do_replace(struct net
 	state.buf_kern_len = size64;
 
 	ret = compat_copy_entries(entries_tmp, tmp.entries_size, &state);
-	BUG_ON(ret < 0);	/* parses same data again */
+	if (WARN_ON(ret < 0))
+		goto out_unlock;
 
 	vfree(entries_tmp);
 	tmp.entries_size = size64;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #123 lore raw

PATCH 110/268 nvme-pci: Fix nvme queue cleanup if IRQ setup fails

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

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

From: Jianchao Wang <[email protected]>

[ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ]

This patch fixes nvme queue cleanup if requesting an IRQ handler for the queue's vector fails. It does this by resetting the cq_vector to the uninitialized value of -1 so it is ignored for a controller reset.

Signed-off-by Jianchao Wang <[email protected]>

[changelog updates, removed misc whitespace changes]

Signed-off-by Keith Busch <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/nvme/host/pci.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/nvme/host/pci.c +4 -1

@@ -1583,7 +1583,7 @@ static int nvme_create_queue(struct nvme
 	nvmeq->cq_vector = qid - 1;
 	result = adapter_alloc_cq(dev, qid, nvmeq);
 	if (result < 0)
-		return result;
+		goto release_vector;
 
 	result = adapter_alloc_sq(dev, qid, nvmeq);
 	if (result < 0)

@@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
 	return result;
 
  release_sq:
+	dev->online_queues--;
 	adapter_delete_sq(dev, qid);
  release_cq:
 	adapter_delete_cq(dev, qid);
+ release_vector:
+	nvmeq->cq_vector = -1;
 	return result;
 }

Ben Hutchings

2018-06-13 16:14 UTC #124 lore raw

Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

Quoted 36 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jianchao Wang <[email protected]>
[ Upstream commit f25a2dfc20e3a3ed8fe6618c331799dd7bd01190 ]
This patch fixes nvme queue cleanup if requesting an IRQ handler for the queue's vector fails. It does this by resetting the cq_vector to the uninitialized value of -1 so it is ignored for a controller reset.
Signed-off-by Jianchao Wang <[email protected]>
[changelog updates, removed misc whitespace changes]
Signed-off-by Keith Busch <[email protected]>
Signed-off-by Sasha Levin <[email protected]>
Signed-off-by Greg Kroah-Hartman <[email protected]>
---
drivers/nvme/host/pci.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/nvme/host/pci.c +1 -1
@@ -1583,7 +1583,7 @@ static int nvme_create_queue(struct nvme
  	nvmeq->cq_vector = qid - 1;
  	result = adapter_alloc_cq(dev, qid, nvmeq);
  	if (result < 0)
-		return result;
+		goto release_vector;
result = adapter_alloc_sq(dev, qid, nvmeq); if (result < 0)
drivers/nvme/host/pci.c +0 -0
@@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
  	return result;
release_sq:

drivers/nvme/host/pci.c static int nvme_create_queue(struct nvme · line 1600

Quoted 1 line

drivers/nvme/host/pci.c +1 -0
+	dev->online_queues--;

This addition looks wrong. dev->online_queues is incremented by nvme_init_queue(), but this function only calls that at a point where it is sure to succeed. So why would a failure path need to decrement it?

Ben.

Quoted 11 lines

adapter_delete_sq(dev, qid);
release_cq:
adapter_delete_cq(dev, qid);
+ release_vector:
drivers/nvme/host/pci.c +1 -0
+	nvmeq->cq_vector = -1;
return result;
}

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Keith Busch

2018-06-13 16:27 UTC #125 lore raw

Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

Quoted 13 lines · Ben Hutchings

drivers/nvme/host/pci.c static int nvme_create_queue(struct nvme · line 1600
Quoted 7 lines · Greg Kroah-Hartman
result = adapter_alloc_sq(dev, qid, nvmeq); if (result < 0)
(quoted diff) +0 -0
@@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
  	return result;
release_sq:
drivers/nvme/host/pci.c +1 -0
+	dev->online_queues--;
This addition looks wrong. dev->online_queues is incremented by nvme_init_queue(), but this function only calls that at a point where it is sure to succeed. So why would a failure path need to decrement it?

Thank you very much the catching that. This particular patch is indeed not correct without the following:

161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")

Ben Hutchings

2018-06-13 16:37 UTC #126 lore raw

Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

Quoted 15 lines · Keith Busch

Quoted 13 lines · Ben Hutchings
drivers/nvme/host/pci.c static int nvme_create_queue(struct nvme · line 1600
Quoted 7 lines · Greg Kroah-Hartman
result = adapter_alloc_sq(dev, qid, nvmeq); if (result < 0)
(quoted diff) +0 -0
@@ -1597,9 +1597,12 @@ static int nvme_create_queue(struct nvme
  	return result;
release_sq:
drivers/nvme/host/pci.c +1 -0
+	dev->online_queues--;
This addition looks wrong. dev->online_queues is incremented by nvme_init_queue(), but this function only calls that at a point where it is sure to succeed. So why would a failure path need to decrement it?

Quoted 4 lines

Thank you very much the catching that. This particular patch is indeed not correct without the following:
161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")

Oh, now I see. Do you think that commit is suitable for stable branches?

Ben.

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Keith Busch

2018-06-13 16:53 UTC #127 lore raw

Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

Quoted 8 lines · Ben Hutchings

Quoted 4 lines · Keith Busch
Thank you very much the catching that. This particular patch is indeed not correct without the following:
ï¿½ 161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")
Oh, now I see. Do you think that commit is suitable for stable branches?

Yes, we can safely include that commit 4.4-stable. The scenario it fixes isn't very common in 4.4, but it could happen with quirky hardware or legacy interrupts.

Greg Kroah-Hartman

author maintainer

2018-06-13 17:13 UTC #128 lore raw

Re: [PATCH 4.4 110/268] nvme-pci: Fix nvme queue cleanup if IRQ setup fails

Quoted 5 lines · Keith Busch

Quoted 4 lines · Ben Hutchings
Quoted 3 lines · Keith Busch
Thank you very much the catching that. This particular patch is indeed not correct without the following:

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
ï¿½ 161b8be2bd6ab ("nvme-pci: initialize queue memory before interrupts")
Oh, now I see. Do you think that commit is suitable for stable branches?
Yes, we can safely include that commit 4.4-stable. The scenario it fixes isn't very common in 4.4, but it could happen with quirky hardware or legacy interrupts.

It does not apply to 4.4.y right now, but it does apply to 4.9.y, so I've added it there. If it needs to get to 4.4.y, can someone do a backport?

thanks,

greg k-h

Ben Hutchings

2018-06-19 17:23 UTC #129 lore raw

PATCH 1/1 nvme-pci: initialize queue memory before interrupts

From: Keith Busch <[email protected]>

commit 161b8be2bd6abad250d4b3f674bdd5480f15beeb upstream.

A spurious interrupt before the nvme driver has initialized the completion queue may inadvertently cause the driver to believe it has a completion to process. This may result in a NULL dereference since the nvmeq's tags are not set at this point.

The patch initializes the host's CQ memory so that a spurious interrupt isn't mistaken for a real completion.

Signed-off-by Keith Busch <[email protected]>

Reviewed-by Johannes Thumshirn <[email protected]>

Signed-off-by Christoph Hellwig <[email protected]>

[bwh: Backported to 4.4: adjust context]

Signed-off-by Jens Axboe <[email protected]>

---
 drivers/nvme/host/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/nvme/host/pci.c +2 -2

index e86fcc9e9852..01f47b68b6e7 100644
@@ -1589,11 +1589,11 @@ static int nvme_create_queue(struct nvme_queue *nvmeq, int qid)
 	if (result < 0)
 		goto release_cq;
 
+	nvme_init_queue(nvmeq, qid);
 	result = queue_request_irq(dev, nvmeq, nvmeq->irqname);
 	if (result < 0)
 		goto release_sq;
 
-	nvme_init_queue(nvmeq, qid);
 	return result;
 
  release_sq:

@@ -1797,6 +1797,7 @@ static int nvme_configure_admin_queue(struct nvme_dev *dev)
 		goto free_nvmeq;
 
 	nvmeq->cq_vector = 0;
+	nvme_init_queue(nvmeq, 0);
 	result = queue_request_irq(dev, nvmeq, nvmeq->irqname);
 	if (result) {
 		nvmeq->cq_vector = -1;

@@ -3165,7 +3166,6 @@ static void nvme_probe_work(struct work_struct *work)
 		goto disable;
 	}
 
-	nvme_init_queue(dev->queues[0], 0);
 	result = nvme_alloc_admin_tags(dev);
 	if (result)
 		goto disable;

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Greg Kroah-Hartman

author maintainer

2018-07-05 16:55 UTC #130 lore raw

Re: [PATCH 4.4] nvme-pci: initialize queue memory before interrupts

Quoted 12 lines · Ben Hutchings

From: Keith Busch <[email protected]>
commit 161b8be2bd6abad250d4b3f674bdd5480f15beeb upstream.
A spurious interrupt before the nvme driver has initialized the completion queue may inadvertently cause the driver to believe it has a completion to process. This may result in a NULL dereference since the nvmeq's tags are not set at this point.
The patch initializes the host's CQ memory so that a spurious interrupt isn't mistaken for a real completion.

Quoted 8 lines

Signed-off-by Keith Busch <[email protected]>
Reviewed-by Johannes Thumshirn <[email protected]>
Signed-off-by Christoph Hellwig <[email protected]>
[bwh: Backported to 4.4: adjust context]
Signed-off-by Jens Axboe <[email protected]>
---
 drivers/nvme/host/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Now applied, thanks.

greg k-h

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #131 lore raw

PATCH 111/268 clocksource/drivers/fsl_ftm_timer: Fix error return checking

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

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

From: Colin Ian King <[email protected]>

[ Upstream commit f287eb9013ccf199cbfa4eabd80c36fedfc15a73 ]

The error checks on freq for a negative error return always fails because freq is unsigned and can never be negative. Fix this by making freq a signed long.

Detected with Coccinelle:
drivers/clocksource/fsl_ftm_timer.c:287:5-9: WARNING: Unsigned expression compared with zero: freq <= 0 drivers/clocksource/fsl_ftm_timer.c:291:5-9: WARNING: Unsigned expression compared with zero: freq <= 0

Fixes 2529c3a33079 ("clocksource: Add Freescale FlexTimer Module (FTM) timer support")

Signed-off-by Colin Ian King <[email protected]>

Signed-off-by Thomas Gleixner <[email protected]>

Cc Daniel Lezcano <[email protected]>

Link https://lkml.kernel.org/r/[email protected] open here

Signed-off-by Sasha Levin <[email protected]>

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

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

drivers/clocksource/fsl_ftm_timer.c +1 -1

@@ -281,7 +281,7 @@ static int __init __ftm_clk_init(struct
 
 static unsigned long __init ftm_clk_init(struct device_node *np)
 {
-	unsigned long freq;
+	long freq;
 
 	freq = __ftm_clk_init(np, "ftm-evt-counter-en", "ftm-evt");
 	if (freq <= 0)

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #132 lore raw

PATCH 112/268 r8152: fix tx packets accounting

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

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

From: Eric Dumazet <[email protected]>

[ Upstream commit 4c27bf3c5b7434ccb9ab962301da661c26b467a4 ]

r8152 driver handles TSO packets (limited to ~16KB) quite well, but pretends each TSO logical packet is a single packet on the wire.

There is also some error since headers are accounted once, but error rate is small enough that we do not care.

Signed-off-by Eric Dumazet <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/usb/r8152.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/usb/r8152.c +1 -1

@@ -1610,7 +1610,7 @@ static int r8152_tx_agg_fill(struct r815
 
 		tx_data += len;
 		agg->skb_len += len;
-		agg->skb_num++;
+		agg->skb_num += skb_shinfo(skb)->gso_segs ?: 1;
 
 		dev_kfree_skb_any(skb);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #133 lore raw

PATCH 113/268 virtio-gpu: fix ioctl and expose the fixed status to userspace.

Link http://patchwork.freedesktop.org/patch/msgid/[email protected]

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

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

From: Dave Airlie <[email protected]>

[ Upstream commit 9a191b114906457c4b2494c474f58ae4142d4e67 ]

This exposes to mesa that it can use the fixed ioctl for querying later cap sets, cap set 1 is forever frozen in time.

Signed-off-by Dave Airlie <[email protected]>

Signed-off-by Gerd Hoffmann <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/gpu/drm/virtio/virtgpu_ioctl.c |   17 +++++++++++------
 include/uapi/drm/virtgpu_drm.h         |    1 +
 2 files changed, 12 insertions(+), 6 deletions(-)

drivers/gpu/drm/virtio/virtgpu_ioctl.c +11 -6

@@ -208,6 +208,9 @@ static int virtio_gpu_getparam_ioctl(str
 	case VIRTGPU_PARAM_3D_FEATURES:
 		value = vgdev->has_virgl_3d == true ? 1 : 0;
 		break;
+	case VIRTGPU_PARAM_CAPSET_QUERY_FIX:
+		value = 1;
+		break;
 	default:
 		return -EINVAL;
 	}

@@ -483,7 +486,7 @@ static int virtio_gpu_get_caps_ioctl(str
 {
 	struct virtio_gpu_device *vgdev = dev->dev_private;
 	struct drm_virtgpu_get_caps *args = data;
-	int size;
+	unsigned size, host_caps_size;
 	int i;
 	int found_valid = -1;
 	int ret;

@@ -492,6 +495,10 @@ static int virtio_gpu_get_caps_ioctl(str
 	if (vgdev->num_capsets == 0)
 		return -ENOSYS;
 
+	/* don't allow userspace to pass 0 */
+	if (args->size == 0)
+		return -EINVAL;
+
 	spin_lock(&vgdev->display_info_lock);
 	for (i = 0; i < vgdev->num_capsets; i++) {
 		if (vgdev->capsets[i].id == args->cap_set_id) {

@@ -507,11 +514,9 @@ static int virtio_gpu_get_caps_ioctl(str
 		return -EINVAL;
 	}
 
-	size = vgdev->capsets[found_valid].max_size;
-	if (args->size > size) {
-		spin_unlock(&vgdev->display_info_lock);
-		return -EINVAL;
-	}
+	host_caps_size = vgdev->capsets[found_valid].max_size;
+	/* only copy to user the minimum of the host caps size or the guest caps size */
+	size = min(args->size, host_caps_size);
 
 	list_for_each_entry(cache_ent, &vgdev->cap_cache, head) {
 		if (cache_ent->id == args->cap_set_id &&

include/uapi/drm/virtgpu_drm.h +1 -0

@@ -60,6 +60,7 @@ struct drm_virtgpu_execbuffer {
 };
 
 #define VIRTGPU_PARAM_3D_FEATURES 1 /* do we have 3D features in the hw */
+#define VIRTGPU_PARAM_CAPSET_QUERY_FIX 2 /* do we have the capset fix */
 
 struct drm_virtgpu_getparam {
 	uint64_t param;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #134 lore raw

PATCH 114/268 dmaengine: rcar-dmac: fix max_chunk_size for R-Car Gen3

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

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

From: Yoshihiro Shimoda <[email protected]>

[ Upstream commit d716d9b702bb759dd6fb50804f10a174bd156d71 ]

According to R-Car Gen3 Rev.0.80 manual, the DMATCR can be set to 16,777,215 as maximum. So, this patch fixes the max_chunk_size for safety on all of SoCs. Otherwise, a system may hang if the DMATCR is set to 0 on R-Car Gen3.

Signed-off-by Yoshihiro Shimoda <[email protected]>

Reviewed-by Simon Horman <[email protected]>

Signed-off-by Vinod Koul <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/dma/sh/rcar-dmac.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/dma/sh/rcar-dmac.c +1 -1

@@ -851,7 +851,7 @@ rcar_dmac_chan_prep_sg(struct rcar_dmac_
 
 	rcar_dmac_chan_configure_desc(chan, desc);
 
-	max_chunk_size = (RCAR_DMATCR_MASK + 1) << desc->xfer_shift;
+	max_chunk_size = RCAR_DMATCR_MASK << desc->xfer_shift;
 
 	/*
 	 * Allocate and fill the transfer chunk descriptors. We own the only

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #135 lore raw

PATCH 115/268 bcache: fix kcrashes with fio in RAID5 backend dev

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

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

From: Tang Junhui <[email protected]>

[ Upstream commit 60eb34ec5526e264c2bbaea4f7512d714d791caf ]

Kernel crashed when run fio in a RAID5 backend bcache device, the call trace is bellow:

[  440.012034] kernel BUG at block/blk-ioc.c:146!
[  440.012696] invalid opcode: 0000 [#1] SMP NOPTI
[  440.026537] CPU: 2 PID: 2205 Comm: md127_raid5 Not tainted 4.15.0 #8
[  440.027441] Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 07/16
/2015
[  440.028615] RIP: 0010:put_io_context+0x8b/0x90
[  440.029246] RSP: 0018:ffffa8c882b43af8 EFLAGS: 00010246
[  440.029990] RAX: 0000000000000000 RBX: ffffa8c88294fca0 RCX: 0000000000
0f4240
[  440.031006] RDX: 0000000000000004 RSI: 0000000000000286 RDI: ffffa8c882
94fca0
[  440.032030] RBP: ffffa8c882b43b10 R08: 0000000000000003 R09: ffff949cb8
0c1700
[  440.033206] R10: 0000000000000104 R11: 000000000000b71c R12: 00000000000
01000
[  440.034222] R13: 0000000000000000 R14: ffff949cad84db70 R15: ffff949cb11
bd1e0
[  440.035239] FS:  0000000000000000(0000) GS:ffff949cba280000(0000) knlGS:
0000000000000000
[  440.060190] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  440.084967] CR2: 00007ff0493ef000 CR3: 00000002f1e0a002 CR4: 00000000001
606e0
[  440.110498] Call Trace:
[  440.135443]  bio_disassociate_task+0x1b/0x60
[  440.160355]  bio_free+0x1b/0x60
[  440.184666]  bio_put+0x23/0x30
[  440.208272]  search_free+0x23/0x40 [bcache]
[  440.231448]  cached_dev_write_complete+0x31/0x70 [bcache]
[  440.254468]  closure_put+0xb6/0xd0 [bcache]
[  440.277087]  request_endio+0x30/0x40 [bcache]
[  440.298703]  bio_endio+0xa1/0x120
[  440.319644]  handle_stripe+0x418/0x2270 [raid456]
[  440.340614]  ? load_balance+0x17b/0x9c0
[  440.360506]  handle_active_stripes.isra.58+0x387/0x5a0 [raid456]
[  440.380675]  ? __release_stripe+0x15/0x20 [raid456]
[  440.400132]  raid5d+0x3ed/0x5d0 [raid456]
[  440.419193]  ? schedule+0x36/0x80
[  440.437932]  ? schedule_timeout+0x1d2/0x2f0
[  440.456136]  md_thread+0x122/0x150
[  440.473687]  ? wait_woken+0x80/0x80
[  440.491411]  kthread+0x102/0x140
[  440.508636]  ? find_pers+0x70/0x70
[  440.524927]  ? kthread_associate_blkcg+0xa0/0xa0
[  440.541791]  ret_from_fork+0x35/0x40
[  440.558020] Code: c2 48 00 5b 41 5c 41 5d 5d c3 48 89 c6 4c 89 e7 e8 bb c2
48 00 48 8b 3d bc 36 4b 01 48 89 de e8 7c f7 e0 ff 5b 41 5c 41 5d 5d c3 <0f> 0b
0f 1f 00 0f 1f 44 00 00 55 48 8d 47 b8 48 89 e5 41 57 41
[  440.610020] RIP: put_io_context+0x8b/0x90 RSP: ffffa8c882b43af8
[  440.628575] ---[ end trace a1fd79d85643a73e ]--

All the crash issue happened when a bypass IO coming, in such scenario s->iop.bio is pointed to the s->orig_bio. In search_free(), it finishes the s->orig_bio by calling bio_complete(), and after that, s->iop.bio became invalid, then kernel would crash when calling bio_put(). Maybe its upper layer's faulty, since bio should not be freed before we calling bio_put(), but we'd better calling bio_put() first before calling bio_complete() to notify upper layer ending this bio.

This patch moves bio_complete() under bio_put() to avoid kernel crash.

[mlyle: fixed commit subject for character limits]

Reported-by Matthias Ferdinand <[email protected]>

Tested-by Matthias Ferdinand <[email protected]>

Signed-off-by Tang Junhui <[email protected]>

Signed-off-by Jens Axboe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

drivers/md/bcache/request.c +1 -1

@@ -633,11 +633,11 @@ static void do_bio_hook(struct search *s
 static void search_free(struct closure *cl)
 {
 	struct search *s = container_of(cl, struct search, cl);
-	bio_complete(s);
 
 	if (s->iop.bio)
 		bio_put(s->iop.bio);
 
+	bio_complete(s);
 	closure_debug_destroy(cl);
 	mempool_free(s, s->d->c->search);
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #136 lore raw

PATCH 116/268 sit: fix IFLA_MTU ignored on NEWLINK

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

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

From: Xin Long <[email protected]>

[ Upstream commit 2b3957c34b6d7f03544b12ebbf875eee430745db ]

Commit 128bb975dc3c ("ip6_gre: init dev->mtu and dev->hard_header_len correctly") fixed IFLA_MTU ignored on NEWLINK for ip6_gre. The same mtu fix is also needed for sit.

Note that dev->hard_header_len setting for sit works fine, no need to fix it. sit is actually ipv4 tunnel, it can't call ip6_tnl_change_mtu to set mtu.

Reported-by Jianlin Shi <[email protected]>

Signed-off-by Xin Long <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/ipv6/sit.c |    7 +++++++
 1 file changed, 7 insertions(+)

net/ipv6/sit.c +7 -0

@@ -1574,6 +1574,13 @@ static int ipip6_newlink(struct net *src
 	if (err < 0)
 		return err;
 
+	if (tb[IFLA_MTU]) {
+		u32 mtu = nla_get_u32(tb[IFLA_MTU]);
+
+		if (mtu >= IPV6_MIN_MTU && mtu <= 0xFFF8 - dev->hard_header_len)
+			dev->mtu = mtu;
+	}
+
 #ifdef CONFIG_IPV6_SIT_6RD
 	if (ipip6_netlink_6rd_parms(data, &ip6rd))
 		err = ipip6_tunnel_update_6rd(nt, &ip6rd);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #137 lore raw

PATCH 117/268 gianfar: Fix Rx byte accounting for ndev stats

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

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

From: Claudiu Manoil <[email protected]>

[ Upstream commit 590399ddf9561f2ed0839311c8ae1be21597ba68 ]

Don't include in the Rx bytecount of the packet sent up the stack:
the FCB (frame control block), and the padding bytes inserted by the controller into the frame payload, nor the FCS. All these are being pulled out of the skb by gfar_process_frame().
This issue is old, likely from the driver's beginnings, however it was amplified by recent:
commit d903ec77118c ("gianfar: simplify FCS handling and fix memory leak") which basically added the FCS to the Rx bytecount, and so brought this to my attention.

Signed-off-by Claudiu Manoil <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/ethernet/freescale/gianfar.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

drivers/net/ethernet/freescale/gianfar.c +3 -4

@@ -3053,9 +3053,6 @@ static void gfar_process_frame(struct ne
 	if (ndev->features & NETIF_F_RXCSUM)
 		gfar_rx_checksum(skb, fcb);
 
-	/* Tell the skb what kind of packet this is */
-	skb->protocol = eth_type_trans(skb, ndev);
-
 	/* There's need to check for NETIF_F_HW_VLAN_CTAG_RX here.
 	 * Even if vlan rx accel is disabled, on some chips
 	 * RXFCB_VLN is pseudo randomly set.

@@ -3126,13 +3123,15 @@ int gfar_clean_rx_ring(struct gfar_priv_
 			continue;
 		}
 
+		gfar_process_frame(ndev, skb);
+
 		/* Increment the number of packets */
 		total_pkts++;
 		total_bytes += skb->len;
 
 		skb_record_rx_queue(skb, rx_queue->qindex);
 
-		gfar_process_frame(ndev, skb);
+		skb->protocol = eth_type_trans(skb, ndev);
 
 		/* Send the packet up the stack */
 		napi_gro_receive(&rx_queue->grp->napi_rx, skb);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #138 lore raw

PATCH 118/268 net/tcp/illinois: replace broken algorithm reference link

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.296.6350&rep=rep1&type=pdf

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

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

From: Joey Pabalinas <[email protected]>

[ Upstream commit ecc832758a654e375924ebf06a4ac971acb5ce60 ]

The link to the pdf containing the algorithm description is now a dead link; it seems http://www.ifp.illinois.edu/~srikant/ has been moved to https://sites.google.com/a/illinois.edu/srikant/ and none of the original papers can be found there...

I have replaced it with the only working copy I was able to find.

n.b. there is also a copy available at:

However, this seems to only be a *cached* version, so I am unsure exactly how reliable that link can be expected to remain over time and have decided against using that one.

Signed-off-by Joey Pabalinas <[email protected]>

 net/ipv4/tcp_illinois.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/ipv4/tcp_illinois.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/ipv4/tcp_illinois.c +1 -1

@@ -6,7 +6,7 @@
  * The algorithm is described in:
  * "TCP-Illinois: A Loss and Delay-Based Congestion Control Algorithm
  *  for High-Speed Networks"
- * http://www.ifp.illinois.edu/~srikant/Papers/liubassri06perf.pdf
+ * http://tamerbasar.csl.illinois.edu/LiuBasarSrikantPerfEvalArtJun2008.pdf
  *
  * Implemented from description in paper and ns-2 simulation.
  * Copyright (C) 2007 Stephen Hemminger <[email protected]>

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #139 lore raw

PATCH 120/268 Btrfs: send, fix issuing write op when processing hole in no data mode

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

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

From: Filipe Manana <[email protected]>

[ Upstream commit d4dfc0f4d39475ccbbac947880b5464a74c30b99 ]

When doing an incremental send of a filesystem with the no-holes feature enabled, we end up issuing a write operation when using the no data mode send flag, instead of issuing an update extent operation. Fix this by issuing the update extent operation instead.

Trivial reproducer:

  $ mkfs.btrfs -f -O no-holes /dev/sdc
  $ mkfs.btrfs -f /dev/sdd
  $ mount /dev/sdc /mnt/sdc
  $ mount /dev/sdd /mnt/sdd

  $ xfs_io -f -c "pwrite -S 0xab 0 32K" /mnt/sdc/foobar
  $ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap1

  $ xfs_io -c "fpunch 8K 8K" /mnt/sdc/foobar
  $ btrfs subvolume snapshot -r /mnt/sdc /mnt/sdc/snap2

  $ btrfs send /mnt/sdc/snap1 | btrfs receive /mnt/sdd
  $ btrfs send --no-data -p /mnt/sdc/snap1 /mnt/sdc/snap2 \
       | btrfs receive -vv /mnt/sdd

Before this change the output of the second receive command is:

receiving snapshot snap2 uuid=f6922049-8c22-e544-9ff9-fc6755918447... utimes
write foobar, offset 8192, len 8192
utimes foobar
BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=f6922049-8c22-e544-9ff9-...

After this change it is:

receiving snapshot snap2 uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64... utimes
update_extent foobar: offset=8192, len=8192
utimes foobar
BTRFS_IOC_SET_RECEIVED_SUBVOL uuid=564d36a3-ebc8-7343-aec9-bf6fda278e64...

Signed-off-by Filipe Manana <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 fs/btrfs/send.c |    3 +++
 1 file changed, 3 insertions(+)

fs/btrfs/send.c +3 -0

@@ -4674,6 +4674,9 @@ static int send_hole(struct send_ctx *sc
 	u64 len;
 	int ret = 0;
 
+	if (sctx->flags & BTRFS_SEND_FLAG_NO_FILE_DATA)
+		return send_update_extent(sctx, offset, end - offset);
+
 	p = fs_path_alloc();
 	if (!p)
 		return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #140 lore raw

PATCH 121/268 selftests/powerpc: Skip the subpage_prot tests if the syscall is unavailable

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

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

From: Michael Ellerman <[email protected]>

[ Upstream commit cd4a6f3ab4d80cb919d15897eb3cbc85c2009d4b ]

The subpage_prot syscall is only functional when the system is using the Hash MMU. Since commit 5b2b80714796 ("powerpc/mm: Invalidate subpage_prot() system call on radix platforms") it returns ENOENT when the Radix MMU is active. Currently this just makes the test fail.

Additionally the syscall is not available if the kernel is built with 4K pages, or if CONFIG_PPC_SUBPAGE_PROT=n, in which case it returns ENOSYS because the syscall is missing entirely.

So check explicitly for ENOENT and ENOSYS and skip if we see either of those.

Signed-off-by Sasha Levin <[email protected]>

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

---
 tools/testing/selftests/powerpc/mm/subpage_prot.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)

tools/testing/selftests/powerpc/mm/subpage_prot.c +14 -0

@@ -135,6 +135,16 @@ static int run_test(void *addr, unsigned
 	return 0;
 }
 
+static int syscall_available(void)
+{
+	int rc;
+
+	errno = 0;
+	rc = syscall(__NR_subpage_prot, 0, 0, 0);
+
+	return rc == 0 || (errno != ENOENT && errno != ENOSYS);
+}
+
 int test_anon(void)
 {
 	unsigned long align;

@@ -145,6 +155,8 @@ int test_anon(void)
 	void *mallocblock;
 	unsigned long mallocsize;
 
+	SKIP_IF(!syscall_available());
+
 	if (getpagesize() != 0x10000) {
 		fprintf(stderr, "Kernel page size must be 64K!\n");
 		return 1;

@@ -180,6 +192,8 @@ int test_file(void)
 	off_t filesize;
 	int fd;
 
+	SKIP_IF(!syscall_available());
+
 	fd = open(file_name, O_RDWR);
 	if (fd == -1) {
 		perror("failed to open file");

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #141 lore raw

PATCH 122/268 KVM: PPC: Book3S HV: Fix VRMA initialization with 2MB or 1GB memory backing

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

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

From: Paul Mackerras <[email protected]>

[ Upstream commit debd574f4195e205ba505b25e19b2b797f4bcd94 ]

The current code for initializing the VRMA (virtual real memory area) for HPT guests requires the page size of the backing memory to be one of 4kB, 64kB or 16MB. With a radix host we have the possibility that the backing memory page size can be 2MB or 1GB. In these cases, if the guest switches to HPT mode, KVM will not initialize the VRMA and the guest will fail to run.

In fact it is not necessary that the VRMA page size is the same as the backing memory page size; any VRMA page size less than or equal to the backing memory page size is acceptable. Therefore we now choose the largest page size out of the set {4k, 64k, 16M} which is not larger than the backing memory page size.

Signed-off-by Paul Mackerras <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/powerpc/kvm/book3s_hv.c |   12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

arch/powerpc/kvm/book3s_hv.c +7 -5

@@ -3002,15 +3002,17 @@ static int kvmppc_hv_setup_htab_rma(stru
 		goto up_out;
 
 	psize = vma_kernel_pagesize(vma);
-	porder = __ilog2(psize);
 
 	up_read(&current->mm->mmap_sem);
 
 	/* We can handle 4k, 64k or 16M pages in the VRMA */
-	err = -EINVAL;
-	if (!(psize == 0x1000 || psize == 0x10000 ||
-	      psize == 0x1000000))
-		goto out_srcu;
+	if (psize >= 0x1000000)
+		psize = 0x1000000;
+	else if (psize >= 0x10000)
+		psize = 0x10000;
+	else
+		psize = 0x1000;
+	porder = __ilog2(psize);
 
 	/* Update VRMASD field in the LPCR */
 	senc = slb_pgsize_encoding(psize);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #142 lore raw

PATCH 123/268 watchdog: f71808e_wdt: Fix magic close handling

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

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

From: Igor Pylypiv <[email protected]>

[ Upstream commit 7bd3e7b743956afbec30fb525bc3c5e22e3d475c ]

Watchdog close is "expected" when any byte is 'V' not just the last one. Writing "V" to the device fails because the last byte is the end of string.

$ echo V > /dev/watchdog
f71808e_wdt: Unexpected close, not stopping watchdog!

Signed-off-by Igor Pylypiv <[email protected]>

Reviewed-by Guenter Roeck <[email protected]>

Signed-off-by Guenter Roeck <[email protected]>

Signed-off-by Wim Van Sebroeck <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/watchdog/f71808e_wdt.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/watchdog/f71808e_wdt.c +2 -1

@@ -520,7 +520,8 @@ static ssize_t watchdog_write(struct fil
 				char c;
 				if (get_user(c, buf + i))
 					return -EFAULT;
-				expect_close = (c == 'V');
+				if (c == 'V')
+					expect_close = true;
 			}
 
 			/* Properly order writes across fork()ed processes */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #143 lore raw

PATCH 124/268 e1000e: Fix check_for_link return value with autoneg off

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

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

From: Benjamin Poirier <[email protected]>

[ Upstream commit 4e7dc08e57c95673d2edaba8983c3de4dd1f65f5 ]

When autoneg is off, the .check_for_link callback functions clear the get_link_status flag and systematically return a "pseudo-error". This means that the link is not detected as up until the next execution of the e1000_watchdog_task() 2 seconds later.

Fixes 19110cfbb34d ("e1000e: Separate signaling for link check/link up")

Signed-off-by Benjamin Poirier <[email protected]>

Acked-by Sasha Neftin <[email protected]>

Tested-by Aaron Brown <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/ethernet/intel/e1000e/ich8lan.c |    2 +-
 drivers/net/ethernet/intel/e1000e/mac.c     |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/e1000e/ich8lan.c +1 -1

@@ -1574,7 +1574,7 @@ static s32 e1000_check_for_copper_link_i
 	 * we have already determined whether we have link or not.
 	 */
 	if (!mac->autoneg)
-		return -E1000_ERR_CONFIG;
+		return 1;
 
 	/* Auto-Neg is enabled.  Auto Speed Detection takes care
 	 * of MAC speed/duplex configuration.  So we only need to

drivers/net/ethernet/intel/e1000e/mac.c +1 -1

@@ -450,7 +450,7 @@ s32 e1000e_check_for_copper_link(struct
 	 * we have already determined whether we have link or not.
 	 */
 	if (!mac->autoneg)
-		return -E1000_ERR_CONFIG;
+		return 1;
 
 	/* Auto-Neg is enabled.  Auto Speed Detection takes care
 	 * of MAC speed/duplex configuration.  So we only need to

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #144 lore raw

PATCH 125/268 e1000e: allocate ring descriptors with dma_zalloc_coherent

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

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

From: Pierre-Yves Kerbrat <[email protected]>

[ Upstream commit aea3fca005fb45f80869f2e8d56fd4e64c1d1fdb ]

Descriptor rings were not initialized at zero when allocated When area contained garbage data, it caused skb_over_panic in e1000_clean_rx_irq (if data had E1000_RXD_STAT_DD bit set)

This patch makes use of dma_zalloc_coherent to make sure the ring is memset at 0 to prevent the area from containing garbage.

Following is the signature of the panic:
[email protected]: skbuff: skb_over_panic: text:80407b20 len:64010 put:64010 head:ab46d800 data:ab46d842 tail:0xab47d24c end:0xab46df40 dev:eth0 [email protected]: BUG: failure at net/core/skbuff.c:105/skb_panic()!
[email protected]: Kernel panic - not syncing: BUG!
[email protected]:
[email protected]: Process swapper/0 (pid: 0, threadinfo=81728000, task=8173cc00 ,cpu: 0)
[email protected]: SP = <815a1c0c>
[email protected]: Stack: 00000001
[email protected]: b2d89800 815e33ac
[email protected]: ea73c040 00000001
[email protected]: 60040003 0000fa0a
[email protected]: 00000002
[email protected]:
[email protected]: 804540c0 815a1c70
[email protected]: b2744000 602ac070
[email protected]: 815a1c44 b2d89800
[email protected]: 8173cc00 815a1c08
[email protected]:
[email protected]: 00000006
[email protected]: 815a1b50 00000000
[email protected]: 80079434 00000001
[email protected]: ab46df40 b2744000
[email protected]: b2d89800
[email protected]:
[email protected]: 0000fa0a 8045745c
[email protected]: 815a1c88 0000fa0a
[email protected]: 80407b20 b2789f80
[email protected]: 00000005 80407b20
[email protected]:
[email protected]:
[email protected]: Call Trace:
[email protected]: [<804540bc>] skb_panic+0xa4/0xa8
[email protected]: [<80079430>] console_unlock+0x2f8/0x6d0
[email protected]: [<80457458>] skb_put+0xa0/0xc0
[email protected]: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
[email protected]: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
[email protected]: [<804079c8>] e1000_clean_rx_irq+0x188/0x3e8
[email protected]: [<80407b1c>] e1000_clean_rx_irq+0x2dc/0x3e8
[email protected]: [<80468b48>] __dev_kfree_skb_any+0x88/0xa8
[email protected]: [<804101ac>] e1000e_poll+0x94/0x288
[email protected]: [<8046e9d4>] net_rx_action+0x19c/0x4e8
[email protected]: ...
[email protected]: Maximum depth to print reached. Use kstack=<maximum_depth_to_print> To specify a custom value (where 0 means to display the full backtrace) [email protected]: ---[ end Kernel panic - not syncing: BUG!

Signed-off-by Pierre-Yves Kerbrat <[email protected]>

Signed-off-by Marius Gligor <[email protected]>

Tested-by Aaron Brown <[email protected]>

Reviewed-by Alexander Duyck <[email protected]>

Signed-off-by Jeff Kirsher <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/ethernet/intel/e1000e/netdev.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/net/ethernet/intel/e1000e/netdev.c +2 -2

@@ -2330,8 +2330,8 @@ static int e1000_alloc_ring_dma(struct e
 {
 	struct pci_dev *pdev = adapter->pdev;
 
-	ring->desc = dma_alloc_coherent(&pdev->dev, ring->size, &ring->dma,
-					GFP_KERNEL);
+	ring->desc = dma_zalloc_coherent(&pdev->dev, ring->size, &ring->dma,
+					 GFP_KERNEL);
 	if (!ring->desc)
 		return -ENOMEM;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #145 lore raw

PATCH 126/268 usb: musb: call pm_runtime_{get,put}_sync before reading vbus registers

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

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

From: Merlijn Wajer <[email protected]>

[ Upstream commit df6b074dbe248d8c43a82131e8fd429e401841a5 ]

Without pm_runtime_{get,put}_sync calls in place, reading vbus status via /sys causes the following error:

Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa0ab060 pgd = b333e822
[fa0ab060] *pgd=48011452(bad)

[<c05261b0>] (musb_default_readb) from [<c0525bd0>] (musb_vbus_show+0x58/0xe4) [<c0525bd0>] (musb_vbus_show) from [<c04c0148>] (dev_attr_show+0x20/0x44) [<c04c0148>] (dev_attr_show) from [<c0259f74>] (sysfs_kf_seq_show+0x80/0xdc) [<c0259f74>] (sysfs_kf_seq_show) from [<c0210bac>] (seq_read+0x250/0x448) [<c0210bac>] (seq_read) from [<c01edb40>] (__vfs_read+0x1c/0x118) [<c01edb40>] (__vfs_read) from [<c01edccc>] (vfs_read+0x90/0x144) [<c01edccc>] (vfs_read) from [<c01ee1d0>] (SyS_read+0x3c/0x74) [<c01ee1d0>] (SyS_read) from [<c0106fe0>] (ret_fast_syscall+0x0/0x54)

Solution was suggested by Tony Lindgren <[email protected]>.

Signed-off-by Merlijn Wajer <[email protected]>

Acked-by Tony Lindgren <[email protected]>

Signed-off-by Bin Liu <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/usb/musb/musb_core.c |    2 ++
 1 file changed, 2 insertions(+)

drivers/usb/musb/musb_core.c +2 -0

@@ -1775,6 +1775,7 @@ musb_vbus_show(struct device *dev, struc
 	int		vbus;
 	u8		devctl;
 
+	pm_runtime_get_sync(dev);
 	spin_lock_irqsave(&musb->lock, flags);
 	val = musb->a_wait_bcon;
 	vbus = musb_platform_get_vbus_status(musb);

@@ -1788,6 +1789,7 @@ musb_vbus_show(struct device *dev, struc
 			vbus = 0;
 	}
 	spin_unlock_irqrestore(&musb->lock, flags);
+	pm_runtime_put_sync(dev);
 
 	return sprintf(buf, "Vbus %s, timeout %lu msec\n",
 			vbus ? "on" : "off", val);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #146 lore raw

PATCH 127/268 scsi: mpt3sas: Do not mark fw_event workqueue as WQ_MEM_RECLAIM

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

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

From: Hannes Reinecke <[email protected]>

[ Upstream commit 864449eea7c600596e305ffdc4a6a846414b222c ]

The firmware event workqueue should not be marked as WQ_MEM_RECLAIM as it's doesn't need to make forward progress under memory pressure. In the current state it will result in a deadlock if the device had been forcefully removed.

Cc Sreekanth Reddy <[email protected]>

Cc Suganath Prabu Subramani <[email protected]>

Acked-by Sreekanth Reddy <[email protected]>

Signed-off-by Hannes Reinecke <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/mpt3sas/mpt3sas_scsih.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/scsi/mpt3sas/mpt3sas_scsih.c +1 -1

@@ -8637,7 +8637,7 @@ _scsih_probe(struct pci_dev *pdev, const
 	snprintf(ioc->firmware_event_name, sizeof(ioc->firmware_event_name),
 	    "fw_event_%s%d", ioc->driver_name, ioc->id);
 	ioc->firmware_event_thread = alloc_ordered_workqueue(
-	    ioc->firmware_event_name, WQ_MEM_RECLAIM);
+	    ioc->firmware_event_name, 0);
 	if (!ioc->firmware_event_thread) {
 		pr_err(MPT3SAS_FMT "failure at %s:%d/%s()!\n",
 		    ioc->name, __FILE__, __LINE__, __func__);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #147 lore raw

PATCH 128/268 scsi: sd: Keep disk read-only when re-reading partition

In reply to Ben Hutchings

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

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

From: Jeremy Cline <[email protected]>

[ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]

If the read-only flag is true on a SCSI disk, re-reading the partition table sets the flag back to false.

To observe this bug, you can run:

1. blockdev --setro /dev/sda
2. blockdev --rereadpt /dev/sda
3. blockdev --getro /dev/sda

This commit reads the disk's old state and combines it with the device disk-reported state rather than unconditionally marking it as RW.

Reported-by Li Ning <[email protected]>

Signed-off-by Jeremy Cline <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/scsi/sd.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/scsi/sd.c +2 -1

@@ -2395,6 +2395,7 @@ sd_read_write_protect_flag(struct scsi_d
 	int res;
 	struct scsi_device *sdp = sdkp->device;
 	struct scsi_mode_data data;
+	int disk_ro = get_disk_ro(sdkp->disk);
 	int old_wp = sdkp->write_prot;
 
 	set_disk_ro(sdkp->disk, 0);

@@ -2435,7 +2436,7 @@ sd_read_write_protect_flag(struct scsi_d
 			  "Test WP failed, assume Write Enabled\n");
 	} else {
 		sdkp->write_prot = ((data.device_specific & 0x80) != 0);
-		set_disk_ro(sdkp->disk, sdkp->write_prot);
+		set_disk_ro(sdkp->disk, sdkp->write_prot || disk_ro);
 		if (sdkp->first_scan || old_wp != sdkp->write_prot) {
 			sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n",
 				  sdkp->write_prot ? "on" : "off");

Ben Hutchings

2018-06-13 21:25 UTC #148 lore raw

Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

Quoted 11 lines · Greg Kroah-Hartman

4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeremy Cline <[email protected]>
[ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]
If the read-only flag is true on a SCSI disk, re-reading the partition table sets the flag back to false.

Quoted 8 lines

To observe this bug, you can run:
1. blockdev --setro /dev/sda
2. blockdev --rereadpt /dev/sda
3. blockdev --getro /dev/sda
This commit reads the disk's old state and combines it with the device disk-reported state rather than unconditionally marking it as RW.

It seems to me that this change is likely to cause a regression: if a SCSI device switches from read-only to read-write state then a subsequent rescan won't automatically change the block device to read- write state. The administrator will have to use the blockdev command too.

Even if this change in behaviour is acceptable, this commit does not implement it consistently. The function starts by clearing the ro flag and this commit only changes one of the three exit paths to preserve it. (The log message about Write Protect status also reports the underlying SCSI device flag and not the combined ro flag, but maybe that was intentional.)

I think this commit should be reverted, both in stable and upstream. A proper fix would involve splitting the ro flag into two flags—one controlled by user-space and one read from the device—with the effective read-only status being the logical-or of those two.

Ben.

Quoted 28 lines

Reported-by Li Ning <[email protected]>

Signed-off-by Jeremy Cline <[email protected]>

Signed-off-by Martin K. Petersen <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
drivers/scsi/sd.c | 3 ++-

 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/scsi/sd.c +1 -0

@@ -2395,6 +2395,7 @@ sd_read_write_protect_flag(struct scsi_d
  	int res;
  	struct scsi_device *sdp = sdkp->device;
  	struct scsi_mode_data data;
+	int disk_ro = get_disk_ro(sdkp->disk);
  	int old_wp = sdkp->write_prot;

set_disk_ro(sdkp->disk, 0);

drivers/scsi/sd.c +1 -1

@@ -2435,7 +2436,7 @@ sd_read_write_protect_flag(struct scsi_d
  			  "Test WP failed, assume Write Enabled\n");
  	} else {
  		sdkp->write_prot = ((data.device_specific & 0x80) != 0);
-		set_disk_ro(sdkp->disk, sdkp->write_prot);
+		set_disk_ro(sdkp->disk, sdkp->write_prot || disk_ro);
  		if (sdkp->first_scan || old_wp != sdkp->write_prot) {
  			sd_printk(KERN_NOTICE, sdkp, "Write Protect is %s\n",
  				  sdkp->write_prot ? "on" : "off");

Signature · 3 lines

Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom

Jeremy Cline

2018-06-14 18:50 UTC #149 lore raw

Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

Hi Ben,

Quoted 27 lines · Ben Hutchings

Quoted 11 lines · Greg Kroah-Hartman
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeremy Cline <[email protected]>
[ Upstream commit 20bd1d026aacc5399464f8328f305985c493cde3 ]
If the read-only flag is true on a SCSI disk, re-reading the partition table sets the flag back to false.
Quoted 8 lines
To observe this bug, you can run:
1. blockdev --setro /dev/sda
2. blockdev --rereadpt /dev/sda
3. blockdev --getro /dev/sda
This commit reads the disk's old state and combines it with the device disk-reported state rather than unconditionally marking it as RW.
It seems to me that this change is likely to cause a regression: if a SCSI device switches from read-only to read-write state then a subsequent rescan won't automatically change the block device to read- write state. The administrator will have to use the blockdev command too.

Quoted 6 lines

Even if this change in behaviour is acceptable, this commit does not implement it consistently. The function starts by clearing the ro flag and this commit only changes one of the three exit paths to preserve it. (The log message about Write Protect status also reports the underlying SCSI device flag and not the combined ro flag, but maybe that was intentional.)

Yes, it looks like I messed this up.

Quoted 5 lines

I think this commit should be reverted, both in stable and upstream. A proper fix would involve splitting the ro flag into two flags—one controlled by user-space and one read from the device—with the effective read-only status being the logical-or of those two.

This seems sensible to me, for whatever that's worth. I'm new to the kernel so I'm not certain I'll produce a reasonable patch, but I'm willing to give it a shot.

So the change would be something like:

1. Add a flag to the gendisk struct to indicate if the device is read-only. The driver sets this.

2. In hd_struct struct's policy flag is one that indicates the user-space setting and this gets set by BLKROSET ioctl/set_disk_ro.

3. The effective read-only status reported by the BLKROGET ioctl and bdev_read_only is the logical-or of the hd_struct policy flag and the gendisk device flag.

Maybe that doesn't make sense at all, though. Thoughts?

Thanks,
Jeremy

Martin K. Petersen

2018-06-15 01:41 UTC #150 lore raw

Re: [PATCH 4.4 128/268] scsi: sd: Keep disk read-only when re-reading partition

Hi Ben,

Quoted 3 lines

(The log message about Write Protect status also reports the underlying SCSI device flag and not the combined ro flag, but maybe that was intentional.)

I'd prefer for the printk in question to reflect the device-reported state, not the state of the block device.

Quoted 4 lines

I think this commit should be reverted, both in stable and upstream. A proper fix would involve splitting the ro flag into two flags—one controlled by user-space and one read from the device—with the effective read-only status being the logical-or of those two.

I don't have a problem with distinguishing between current state and an override flag in the block layer. However, I think an incremental patch to fix that up is fine. SCSI devices don't typically switch write protection state on a whim.

Signature · 1 line

Martin K. Petersen	Oracle Linux Engineering

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #151 lore raw

PATCH 129/268 fbdev: Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

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

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

From: Peter Malone <[email protected]>

[ Upstream commit 250c6c49e3b68756b14983c076183568636e2bde ]

Fixing arbitrary kernel leak in case FBIOGETCMAP_SPARC in sbusfb_ioctl_helper().

'index' is defined as an int in sbusfb_ioctl_helper(). We retrieve this from the user:
if (get_user(index, &c->index) ||

    __get_user(count, &c->count) ||
    __get_user(ured, &c->red) ||
    __get_user(ugreen, &c->green) ||
    __get_user(ublue, &c->blue))
       return -EFAULT;

and then we use 'index' in the following way:
red = cmap->red[index + i] >> 8;
green = cmap->green[index + i] >> 8;
blue = cmap->blue[index + i] >> 8;

This is a classic information leak vulnerability. 'index' should be an unsigned int, given its usage above.

This patch is straight-forward; it changes 'index' to unsigned int in two switch-cases: FBIOGETCMAP_SPARC && FBIOPUTCMAP_SPARC.

This patch fixes CVE-2018-6412.

Signed-off-by Peter Malone <[email protected]>

Acked-by Mathieu Malaterre <[email protected]>

Signed-off-by Bartlomiej Zolnierkiewicz <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/video/fbdev/sbuslib.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

drivers/video/fbdev/sbuslib.c +2 -2

@@ -121,7 +121,7 @@ int sbusfb_ioctl_helper(unsigned long cm
 		unsigned char __user *ured;
 		unsigned char __user *ugreen;
 		unsigned char __user *ublue;
-		int index, count, i;
+		unsigned int index, count, i;
 
 		if (get_user(index, &c->index) ||
 		    __get_user(count, &c->count) ||

@@ -160,7 +160,7 @@ int sbusfb_ioctl_helper(unsigned long cm
 		unsigned char __user *ugreen;
 		unsigned char __user *ublue;
 		struct fb_cmap *cmap = &info->cmap;
-		int index, count, i;
+		unsigned int index, count, i;
 		u8 red, green, blue;
 
 		if (get_user(index, &c->index) ||

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #152 lore raw

PATCH 130/268 xen: xenbus: use put_device() instead of kfree()

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

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

From: Arvind Yadav <[email protected]>

[ Upstream commit 351b2bccede1cb673ec7957b35ea997ea24c8884 ]

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized.

Signed-off-by Arvind Yadav <[email protected]>

Reviewed-by Juergen Gross <[email protected]>

Signed-off-by Juergen Gross <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/xen/xenbus/xenbus_probe.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/xen/xenbus/xenbus_probe.c +4 -1

@@ -470,8 +470,11 @@ int xenbus_probe_node(struct xen_bus_typ
 
 	/* Register with generic device framework. */
 	err = device_register(&xendev->dev);
-	if (err)
+	if (err) {
+		put_device(&xendev->dev);
+		xendev = NULL;
 		goto fail;
+	}
 
 	return 0;
 fail:

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #153 lore raw

PATCH 131/268 USB: OHCI: Fix NULL dereference in HCDs using HCD_LOCAL_MEM

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

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

From: Fredrik Noring <[email protected]>

[ Upstream commit d6c931ea32dc08ac2665bb5f009f9c40ad1bbdb3 ]

Scatter-gather needs to be disabled when using dma_declare_coherent_memory and HCD_LOCAL_MEM. Andrea Righi made the equivalent fix for EHCI drivers in commit 4307a28eb01284 "USB: EHCI: fix NULL pointer dererence in HCDs that use HCD_LOCAL_MEM".

The following NULL pointer WARN_ON_ONCE triggered with OHCI drivers:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 49 at drivers/usb/core/hcd.c:1379 hcd_alloc_coherent+0x4c/0xc8
Modules linked in:
CPU: 0 PID: 49 Comm: usb-storage Not tainted 4.15.0+ #1014
Stack : 00000000 00000000 805a78d2 0000003a 81f5c2cc 8053d367 804d77fc 00000031
        805a3a08 00000563 81ee9400 805a0000 00000000 10058c00 81f61b10 805c0000
        00000000 00000000 805a0000 00d9038e 00000004 803ee818 00000006 312e3420
        805c0000 00000000 00000073 81f61958 00000000 00000000 802eb380 804fd538
        00000009 00000563 81ee9400 805a0000 00000002 80056148 00000000 805a0000
        ...
Call Trace:
[<578af360>] show_stack+0x74/0x104
[<2f3702c6>] __warn+0x118/0x120
[<ae93fc9e>] warn_slowpath_null+0x44/0x58
[<a891a517>] hcd_alloc_coherent+0x4c/0xc8
[<3578fa36>] usb_hcd_map_urb_for_dma+0x4d8/0x534
[<110bc94c>] usb_hcd_submit_urb+0x82c/0x834
[<02eb5baf>] usb_sg_wait+0x14c/0x1a0
[<ccd09e85>] usb_stor_bulk_transfer_sglist.part.1+0xac/0x124
[<87a5c34c>] usb_stor_bulk_srb+0x40/0x60
[<ff1792ac>] usb_stor_Bulk_transport+0x160/0x37c
[<b9e2709c>] usb_stor_invoke_transport+0x3c/0x500
[<004754f4>] usb_stor_control_thread+0x258/0x28c
[<22edf42e>] kthread+0x134/0x13c
[<a419ffd0>] ret_from_kernel_thread+0x14/0x1c
---[ end trace bcdb825805eefdcc ]---

Signed-off-by Fredrik Noring <[email protected]>

Acked-by Alan Stern <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/usb/host/ohci-hcd.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

drivers/usb/host/ohci-hcd.c +2 -1

@@ -444,7 +444,8 @@ static int ohci_init (struct ohci_hcd *o
 	struct usb_hcd *hcd = ohci_to_hcd(ohci);
 
 	/* Accept arbitrarily long scatter-gather lists */
-	hcd->self.sg_tablesize = ~0;
+	if (!(hcd->driver->flags & HCD_LOCAL_MEM))
+		hcd->self.sg_tablesize = ~0;
 
 	if (distrust_firmware)
 		ohci->flags |= OHCI_QUIRK_HUB_POWER;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:19 UTC #154 lore raw

PATCH 132/268 netfilter: ebtables: fix erroneous reject of last rule

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

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

From: Florian Westphal <[email protected]>

[ Upstream commit 932909d9b28d27e807ff8eecb68c7748f6701628 ]

The last rule in the blob has next_entry offset that is same as total size. This made "ebtables32 -A OUTPUT -d de:ad:be:ef:01:02" fail on 64 bit kernel.

Fixes b71812168571fa ("netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets")

Signed-off-by Florian Westphal <[email protected]>

Signed-off-by Pablo Neira Ayuso <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/bridge/netfilter/ebtables.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

net/bridge/netfilter/ebtables.c +5 -1

@@ -2088,8 +2088,12 @@ static int size_entry_mwt(struct ebt_ent
 	 * offsets are relative to beginning of struct ebt_entry (i.e., 0).
 	 */
 	for (i = 0; i < 4 ; ++i) {
-		if (offsets[i] >= *total)
+		if (offsets[i] > *total)
 			return -EINVAL;
+
+		if (i < 3 && offsets[i] == *total)
+			return -EINVAL;
+
 		if (i == 0)
 			continue;
 		if (offsets[i-1] > offsets[i])

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #155 lore raw

PATCH 133/268 bnxt_en: Check valid VNIC ID in bnxt_hwrm_vnic_set_tpa().

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

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

From: Michael Chan <[email protected]>

[ Upstream commit 3c4fe80b32c685bdc02b280814d0cfe80d441c72 ]

During initialization, if we encounter errors, there is a code path that calls bnxt_hwrm_vnic_set_tpa() with invalid VNIC ID. This may cause a warning in firmware logs.

Fixes c0c050c58d84 ("bnxt_en: New Broadcom ethernet driver.")

Signed-off-by Michael Chan <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/ethernet/broadcom/bnxt/bnxt.c |    3 +++
 1 file changed, 3 insertions(+)

drivers/net/ethernet/broadcom/bnxt/bnxt.c +3 -0

@@ -2925,6 +2925,9 @@ static int bnxt_hwrm_vnic_set_tpa(struct
 	struct bnxt_vnic_info *vnic = &bp->vnic_info[vnic_id];
 	struct hwrm_vnic_tpa_cfg_input req = {0};
 
+	if (vnic->fw_vnic_id == INVALID_HW_RING_ID)
+		return 0;
+
 	bnxt_hwrm_cmd_hdr_init(bp, &req, HWRM_VNIC_TPA_CFG, -1, -1);
 
 	if (tpa_flags) {

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #156 lore raw

PATCH 134/268 workqueue: use put_device() instead of kfree()

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

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

From: Arvind Yadav <[email protected]>

[ Upstream commit 537f4146c53c95aac977852b371bafb9c6755ee1 ]

Never directly free @dev after calling device_register(), even if it returned an error! Always use put_device() to give up the reference initialized in this function instead.

Signed-off-by Arvind Yadav <[email protected]>

Signed-off-by Tejun Heo <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 kernel/workqueue.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

kernel/workqueue.c +1 -1

@@ -5199,7 +5199,7 @@ int workqueue_sysfs_register(struct work
 
 	ret = device_register(&wq_dev->dev);
 	if (ret) {
-		kfree(wq_dev);
+		put_device(&wq_dev->dev);
 		wq->wq_dev = NULL;
 		return ret;
 	}

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #157 lore raw

PATCH 135/268 ipv4: lock mtu in fnhe when received PMTU < net.ipv4.route.min_pmtu

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

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

From: Sabrina Dubroca <[email protected]>

[ Upstream commit d52e5a7e7ca49457dd31fc8b42fb7c0d58a31221 ]

Prior to the rework of PMTU information storage in commit 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer."), when a PMTU event advertising a PMTU smaller than net.ipv4.route.min_pmtu was received, we would disable setting the DF flag on packets by locking the MTU metric, and set the PMTU to net.ipv4.route.min_pmtu.

Since then, we don't disable DF, and set PMTU to net.ipv4.route.min_pmtu, so the intermediate router that has this link with a small MTU will have to drop the packets.

This patch reestablishes pre-2.6.39 behavior by splitting rtable->rt_pmtu into a bitfield with rt_mtu_locked and rt_pmtu. rt_mtu_locked indicates that we shouldn't set the DF bit on that path, and is checked in ip_dont_fragment().

One possible workaround is to set net.ipv4.route.min_pmtu to a value low enough to accommodate the lowest MTU encountered.

Fixes 2c8cec5c10bc ("ipv4: Cache learned PMTU information in inetpeer.")

Signed-off-by Sabrina Dubroca <[email protected]>

Reviewed-by Stefano Brivio <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 include/net/ip.h        |   11 +++++++++--
 include/net/ip_fib.h    |    1 +
 include/net/route.h     |    3 ++-
 net/ipv4/route.c        |   26 +++++++++++++++++++-------
 net/ipv4/xfrm4_policy.c |    1 +
 5 files changed, 32 insertions(+), 10 deletions(-)

include/net/ip.h +9 -2

@@ -279,6 +279,13 @@ int ip_decrease_ttl(struct iphdr *iph)
 	return --iph->ttl;
 }
 
+static inline int ip_mtu_locked(const struct dst_entry *dst)
+{
+	const struct rtable *rt = (const struct rtable *)dst;
+
+	return rt->rt_mtu_locked || dst_metric_locked(dst, RTAX_MTU);
+}
+
 static inline
 int ip_dont_fragment(const struct sock *sk, const struct dst_entry *dst)
 {

@@ -286,7 +293,7 @@ int ip_dont_fragment(const struct sock *
 
 	return  pmtudisc == IP_PMTUDISC_DO ||
 		(pmtudisc == IP_PMTUDISC_WANT &&
-		 !(dst_metric_locked(dst, RTAX_MTU)));
+		 !ip_mtu_locked(dst));
 }
 
 static inline bool ip_sk_accept_pmtu(const struct sock *sk)

@@ -312,7 +319,7 @@ static inline unsigned int ip_dst_mtu_ma
 	struct net *net = dev_net(dst->dev);
 
 	if (net->ipv4.sysctl_ip_fwd_use_pmtu ||
-	    dst_metric_locked(dst, RTAX_MTU) ||
+	    ip_mtu_locked(dst) ||
 	    !forwarding)
 		return dst_mtu(dst);

include/net/ip_fib.h +1 -0

@@ -56,6 +56,7 @@ struct fib_nh_exception {
 	int				fnhe_genid;
 	__be32				fnhe_daddr;
 	u32				fnhe_pmtu;
+	bool				fnhe_mtu_locked;
 	__be32				fnhe_gw;
 	unsigned long			fnhe_expires;
 	struct rtable __rcu		*fnhe_rth_input;

include/net/route.h +2 -1

@@ -64,7 +64,8 @@ struct rtable {
 	__be32			rt_gateway;
 
 	/* Miscellaneous cached information */
-	u32			rt_pmtu;
+	u32			rt_mtu_locked:1,
+				rt_pmtu:31;
 
 	u32			rt_table_id;

net/ipv4/route.c +19 -7

@@ -612,6 +612,7 @@ static inline u32 fnhe_hashfun(__be32 da
 static void fill_route_from_fnhe(struct rtable *rt, struct fib_nh_exception *fnhe)
 {
 	rt->rt_pmtu = fnhe->fnhe_pmtu;
+	rt->rt_mtu_locked = fnhe->fnhe_mtu_locked;
 	rt->dst.expires = fnhe->fnhe_expires;
 
 	if (fnhe->fnhe_gw) {

@@ -622,7 +623,7 @@ static void fill_route_from_fnhe(struct
 }
 
 static void update_or_create_fnhe(struct fib_nh *nh, __be32 daddr, __be32 gw,
-				  u32 pmtu, unsigned long expires)
+				  u32 pmtu, bool lock, unsigned long expires)
 {
 	struct fnhe_hash_bucket *hash;
 	struct fib_nh_exception *fnhe;

@@ -659,8 +660,10 @@ static void update_or_create_fnhe(struct
 			fnhe->fnhe_genid = genid;
 		if (gw)
 			fnhe->fnhe_gw = gw;
-		if (pmtu)
+		if (pmtu) {
 			fnhe->fnhe_pmtu = pmtu;
+			fnhe->fnhe_mtu_locked = lock;
+		}
 		fnhe->fnhe_expires = max(1UL, expires);
 		/* Update all cached dsts too */
 		rt = rcu_dereference(fnhe->fnhe_rth_input);

@@ -684,6 +687,7 @@ static void update_or_create_fnhe(struct
 		fnhe->fnhe_daddr = daddr;
 		fnhe->fnhe_gw = gw;
 		fnhe->fnhe_pmtu = pmtu;
+		fnhe->fnhe_mtu_locked = lock;
 		fnhe->fnhe_expires = expires;
 
 		/* Exception created; mark the cached routes for the nexthop

@@ -765,7 +769,8 @@ static void __ip_do_redirect(struct rtab
 				struct fib_nh *nh = &FIB_RES_NH(res);
 
 				update_or_create_fnhe(nh, fl4->daddr, new_gw,
-						0, jiffies + ip_rt_gc_timeout);
+						0, false,
+						jiffies + ip_rt_gc_timeout);
 			}
 			if (kill_route)
 				rt->dst.obsolete = DST_OBSOLETE_KILL;

@@ -977,15 +982,18 @@ static void __ip_rt_update_pmtu(struct r
 {
 	struct dst_entry *dst = &rt->dst;
 	struct fib_result res;
+	bool lock = false;
 
-	if (dst_metric_locked(dst, RTAX_MTU))
+	if (ip_mtu_locked(dst))
 		return;
 
 	if (ipv4_mtu(dst) < mtu)
 		return;
 
-	if (mtu < ip_rt_min_pmtu)
+	if (mtu < ip_rt_min_pmtu) {
+		lock = true;
 		mtu = ip_rt_min_pmtu;
+	}
 
 	if (rt->rt_pmtu == mtu &&
 	    time_before(jiffies, dst->expires - ip_rt_mtu_expires / 2))

@@ -995,7 +1003,7 @@ static void __ip_rt_update_pmtu(struct r
 	if (fib_lookup(dev_net(dst->dev), fl4, &res, 0) == 0) {
 		struct fib_nh *nh = &FIB_RES_NH(res);
 
-		update_or_create_fnhe(nh, fl4->daddr, 0, mtu,
+		update_or_create_fnhe(nh, fl4->daddr, 0, mtu, lock,
 				      jiffies + ip_rt_mtu_expires);
 	}
 	rcu_read_unlock();

@@ -1250,7 +1258,7 @@ static unsigned int ipv4_mtu(const struc
 
 	mtu = READ_ONCE(dst->dev->mtu);
 
-	if (unlikely(dst_metric_locked(dst, RTAX_MTU))) {
+	if (unlikely(ip_mtu_locked(dst))) {
 		if (rt->rt_uses_gateway && mtu > 576)
 			mtu = 576;
 	}

@@ -1473,6 +1481,7 @@ static struct rtable *rt_dst_alloc(struc
 		rt->rt_is_input = 0;
 		rt->rt_iif = 0;
 		rt->rt_pmtu = 0;
+		rt->rt_mtu_locked = 0;
 		rt->rt_gateway = 0;
 		rt->rt_uses_gateway = 0;
 		rt->rt_table_id = 0;

@@ -2393,6 +2402,7 @@ struct dst_entry *ipv4_blackhole_route(s
 		rt->rt_is_input = ort->rt_is_input;
 		rt->rt_iif = ort->rt_iif;
 		rt->rt_pmtu = ort->rt_pmtu;
+		rt->rt_mtu_locked = ort->rt_mtu_locked;
 
 		rt->rt_genid = rt_genid_ipv4(net);
 		rt->rt_flags = ort->rt_flags;

@@ -2495,6 +2505,8 @@ static int rt_fill_info(struct net *net,
 	memcpy(metrics, dst_metrics_ptr(&rt->dst), sizeof(metrics));
 	if (rt->rt_pmtu && expires)
 		metrics[RTAX_MTU - 1] = rt->rt_pmtu;
+	if (rt->rt_mtu_locked && expires)
+		metrics[RTAX_LOCK - 1] |= BIT(RTAX_MTU);
 	if (rtnetlink_put_metrics(skb, metrics) < 0)
 		goto nla_put_failure;

net/ipv4/xfrm4_policy.c +1 -0

@@ -97,6 +97,7 @@ static int xfrm4_fill_dst(struct xfrm_ds
 	xdst->u.rt.rt_gateway = rt->rt_gateway;
 	xdst->u.rt.rt_uses_gateway = rt->rt_uses_gateway;
 	xdst->u.rt.rt_pmtu = rt->rt_pmtu;
+	xdst->u.rt.rt_mtu_locked = rt->rt_mtu_locked;
 	xdst->u.rt.rt_table_id = rt->rt_table_id;
 	INIT_LIST_HEAD(&xdst->u.rt.rt_uncached);

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #158 lore raw

PATCH 136/268 sunvnet: does not support GSO for sctp

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

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

From: Cathy Zhou <[email protected]>

[ Upstream commit cf55612a945039476abfd73e39064b2e721c3272 ]

The NETIF_F_GSO_SOFTWARE implies support for GSO on SCTP, but the sunvnet driver does not support GSO for sctp. Here we remove the NETIF_F_GSO_SOFTWARE feature flag and only report NETIF_F_ALL_TSO instead.

Signed-off-by Cathy Zhou <[email protected]>

Signed-off-by Shannon Nelson <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/net/ethernet/sun/sunvnet.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/net/ethernet/sun/sunvnet.c +1 -1

@@ -1787,7 +1787,7 @@ static struct vnet *vnet_new(const u64 *
 	dev->ethtool_ops = &vnet_ethtool_ops;
 	dev->watchdog_timeo = VNET_TX_TIMEOUT;
 
-	dev->hw_features = NETIF_F_TSO | NETIF_F_GSO | NETIF_F_GSO_SOFTWARE |
+	dev->hw_features = NETIF_F_TSO | NETIF_F_GSO | NETIF_F_ALL_TSO |
 			   NETIF_F_HW_CSUM | NETIF_F_SG;
 	dev->features = dev->hw_features;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #159 lore raw

PATCH 137/268 microblaze: switch to NO_BOOTMEM

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

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

From: Rob Herring <[email protected]>

[ Upstream commit 101646a24a2f9cdb61d7732459fbf068a7bbb542 ]

Microblaze doesn't set CONFIG_NO_BOOTMEM and so memblock_virt_alloc() doesn't work for CONFIG_HAVE_MEMBLOCK && !CONFIG_NO_BOOTMEM.

Similar change was already done by others architectures "ARM: mm: Remove bootmem code and switch to NO_BOOTMEM" (sha1: 84f452b1e8fc73ac0e31254c66e3e2260ce5263d)
or
"openrisc: Consolidate setup to use memblock instead of bootmem" (sha1: 266c7fad157265bb54d17db1c9545f2aaa488643)
or
"parisc: Drop bootmem and switch to memblock"
(sha1: 4fe9e1d957e45ad8eba9885ee860a0e93d13a7c7)
or
"powerpc: Remove bootmem allocator"
(sha1: 10239733ee8617bac3f1c1769af43a88ed979324)
or
"s390/mm: Convert bootmem to memblock"
(sha1: 50be634507284eea38df78154d22615d21200b42)
or
"sparc64: Convert over to NO_BOOTMEM."
(sha1: 625d693e9784f988371e69c2b41a2172c0be6c11)
or
"xtensa: drop sysmem and switch to memblock"
(sha1: 0e46c1115f5816949220d62dd3ff04aa68e7ac6b)

Issue was introduced by:
"of/fdt: use memblock_virt_alloc for early alloc"
(sha1: 0fa1c579349fdd90173381712ad78aa99c09d38b)

Signed-off-by Rob Herring <[email protected]>

Tested-by Alvaro Gamez Machado <[email protected]>

Tested-by Michal Simek <[email protected]>

Signed-off-by Michal Simek <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 arch/microblaze/Kconfig   |    1 
 arch/microblaze/mm/init.c |   56 ++++------------------------------------------
 2 files changed, 7 insertions(+), 50 deletions(-)

arch/microblaze/Kconfig +1 -0

@@ -24,6 +24,7 @@ config MICROBLAZE
 	select HAVE_FTRACE_MCOUNT_RECORD
 	select HAVE_FUNCTION_GRAPH_TRACER
 	select HAVE_FUNCTION_TRACER
+	select NO_BOOTMEM
 	select HAVE_MEMBLOCK
 	select HAVE_MEMBLOCK_NODE_MAP
 	select HAVE_OPROFILE

arch/microblaze/mm/init.c +6 ~~-50~~

89 lines not on this page · raw message

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #160 lore raw

PATCH 138/268 net: Fix vlan untag for bridge and vlan_dev with reorder_hdr off

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

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

From: Toshiaki Makita <[email protected]>

[ Upstream commit 4bbb3e0e8239f9079bf1fe20b3c0cb598714ae61 ]

When we have a bridge with vlan_filtering on and a vlan device on top of it, packets would be corrupted in skb_vlan_untag() called from br_dev_xmit().

The problem sits in skb_reorder_vlan_header() used in skb_vlan_untag(), which makes use of skb->mac_len. In this function mac_len is meant for handling rx path with vlan devices with reorder_header disabled, but in tx path mac_len is typically 0 and cannot be used, which is the problem in this case.

The current code even does not properly handle rx path (skb_vlan_untag() called from __netif_receive_skb_core()) with reorder_header off actually.

In rx path single tag case, it works as follows:

- Before skb_reorder_vlan_header()

mac_header data
v v

   +-------------------+-------------+------+----
   |        ETH        |    VLAN     | ETH  |
   |       ADDRS       | TPID | TCI  | TYPE |
   +-------------------+-------------+------+----

<-------- mac_len --------->
<------------->
to be removed

- After skb_reorder_vlan_header()

            mac_header                     data
                 v                          v
                 +-------------------+------+----
                 |        ETH        | ETH  |
                 |       ADDRS       | TYPE |
                 +-------------------+------+----
                 <-------- mac_len --------->

This is ok, but in rx double tag case, it corrupts packets:

- Before skb_reorder_vlan_header()

mac_header data
v v

   +-------------------+-------------+-------------+------+----
   |        ETH        |    VLAN     |    VLAN     | ETH  |
   |       ADDRS       | TPID | TCI  | TPID | TCI  | TYPE |
   +-------------------+-------------+-------------+------+----

<--------------- mac_len ---------------->
<------------->
should be removed
<--------------------------->
actually will be removed

- After skb_reorder_vlan_header()

            mac_header                                   data
                 v                                        v
                               +-------------------+------+----
                               |        ETH        | ETH  |
                               |       ADDRS       | TYPE |
                               +-------------------+------+----
                 <--------------- mac_len ---------------->

So, two of vlan tags are both removed while only inner one should be removed and mac_header (and mac_len) is broken.

skb_vlan_untag() is meant for removing the vlan header at (skb->data - 2), so use skb->data and skb->mac_header to calculate the right offset.

Reported-by Brandon Carpenter <[email protected]>

Fixes a6e18ff11170 ("vlan: Fix untag operations of stacked vlans with REORDER_HEADER off")

Signed-off-by Toshiaki Makita <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 include/uapi/linux/if_ether.h |    1 +
 net/core/skbuff.c             |    7 +++++--
 2 files changed, 6 insertions(+), 2 deletions(-)

include/uapi/linux/if_ether.h +1 -0

@@ -29,6 +29,7 @@
  */
 
 #define ETH_ALEN	6		/* Octets in one ethernet addr	 */
+#define ETH_TLEN	2		/* Octets in ethernet type field */
 #define ETH_HLEN	14		/* Total octets in header.	 */
 #define ETH_ZLEN	60		/* Min. octets in frame sans FCS */
 #define ETH_DATA_LEN	1500		/* Max. octets in payload	 */

net/core/skbuff.c +5 -2

@@ -4295,13 +4295,16 @@ EXPORT_SYMBOL_GPL(skb_gso_transport_segl
 
 static struct sk_buff *skb_reorder_vlan_header(struct sk_buff *skb)
 {
+	int mac_len;
+
 	if (skb_cow(skb, skb_headroom(skb)) < 0) {
 		kfree_skb(skb);
 		return NULL;
 	}
 
-	memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN,
-		2 * ETH_ALEN);
+	mac_len = skb->data - skb_mac_header(skb);
+	memmove(skb_mac_header(skb) + VLAN_HLEN, skb_mac_header(skb),
+		mac_len - VLAN_HLEN - ETH_TLEN);
 	skb->mac_header += VLAN_HLEN;
 	return skb;
 }

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #161 lore raw

PATCH 139/268 batman-adv: fix header size check in batadv_dbg_arp()

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

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

From: Matthias Schiffer <[email protected]>

[ Upstream commit 6f27d2c2a8c236d296201c19abb8533ec20d212b ]

Checking for 0 is insufficient: when an SKB without a batadv header, but with a VLAN header is received, hdr_size will be 4, making the following code interpret the Ethernet header as a batadv header.

Fixes be1db4f6615b ("batman-adv: make the Distributed ARP Table vlan aware")

Signed-off-by Matthias Schiffer <[email protected]>

Signed-off-by Sven Eckelmann <[email protected]>

Signed-off-by Simon Wunderlich <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/batman-adv/distributed-arp-table.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

net/batman-adv/distributed-arp-table.c +1 -1

@@ -374,7 +374,7 @@ static void batadv_dbg_arp(struct batadv
 		   batadv_arp_hw_src(skb, hdr_size), &ip_src,
 		   batadv_arp_hw_dst(skb, hdr_size), &ip_dst);
 
-	if (hdr_size == 0)
+	if (hdr_size < sizeof(struct batadv_unicast_packet))
 		return;
 
 	unicast_4addr_packet = (struct batadv_unicast_4addr_packet *)skb->data;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:01 UTC #162 lore raw

PATCH 140/268 vti4: Dont count header length twice on tunnel setup

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

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

From: Stefano Brivio <[email protected]>

[ Upstream commit dd1df24737727e119c263acf1be2a92763938297 ]

This re-introduces the effect of commit a32452366b72 ("vti4:
Don't count header length twice.") which was accidentally reverted by merge commit f895f0cfbb77 ("Merge branch 'master' of
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec").

The commit message from Steffen Klassert said:

We currently count the size of LL_MAX_HEADER and struct iphdr twice for vti4 devices, this leads to a wrong device mtu. The size of LL_MAX_HEADER and struct iphdr is already counted in ip_tunnel_bind_dev(), so don't do it again in vti_tunnel_init().

And this is still the case now: ip_tunnel_bind_dev() already accounts for the header length of the link layer (not necessarily LL_MAX_HEADER, if the output device is found), plus one IP header.

For example, with a vti device on top of veth, with MTU of 1500, the existing implementation would set the initial vti MTU to 1332, accounting once for LL_MAX_HEADER (128, included in hard_header_len by vti) and twice for the same IP header (once from hard_header_len, once from ip_tunnel_bind_dev()).

It should instead be 1480, because ip_tunnel_bind_dev() is able to figure out that the output device is veth, so no additional link layer header is attached, and will properly count one single IP header.

The existing issue had the side effect of avoiding PMTUD for most xfrm policies, by arbitrarily lowering the initial MTU. However, the only way to get a consistent PMTU value is to let the xfrm PMTU discovery do its course, and commit d6af1a31cc72 ("vti: Add pmtu handling to vti_xmit.") now takes care of local delivery cases where the application ignores local socket notifications.

Fixes b9959fd3b0fa ("vti: switch to new ip tunnel code")

Fixes f895f0cfbb77 ("Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec")

Signed-off-by Stefano Brivio <[email protected]>

Acked-by Sabrina Dubroca <[email protected]>

Signed-off-by Steffen Klassert <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/ipv4/ip_vti.c |    1 -
 1 file changed, 1 deletion(-)

net/ipv4/ip_vti.c +0 -1

@@ -366,7 +366,6 @@ static int vti_tunnel_init(struct net_de
 	memcpy(dev->dev_addr, &iph->saddr, 4);
 	memcpy(dev->broadcast, &iph->daddr, 4);
 
-	dev->hard_header_len	= LL_MAX_HEADER + sizeof(struct iphdr);
 	dev->mtu		= ETH_DATA_LEN;
 	dev->flags		= IFF_NOARP;
 	dev->addr_len		= 4;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #163 lore raw

PATCH 141/268 vti4: Dont override MTU passed on link creation via IFLA_MTU

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

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

From: Stefano Brivio <[email protected]>

[ Upstream commit 03080e5ec72740c1a62e6730f2a5f3f114f11b19 ]

Don't hardcode a MTU value on vti tunnel initialization, ip_tunnel_newlink() is able to deal with this already. See also commit ffc2b6ee4174 ("ip_gre: fix IFLA_MTU ignored on NEWLINK").

Fixes 1181412c1a67 ("net/ipv4: VTI support new module for ip_vti.")

Signed-off-by Stefano Brivio <[email protected]>

Acked-by Sabrina Dubroca <[email protected]>

Signed-off-by Steffen Klassert <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 net/ipv4/ip_vti.c |    1 -
 1 file changed, 1 deletion(-)

net/ipv4/ip_vti.c +0 -1

@@ -366,7 +366,6 @@ static int vti_tunnel_init(struct net_de
 	memcpy(dev->dev_addr, &iph->saddr, 4);
 	memcpy(dev->broadcast, &iph->daddr, 4);
 
-	dev->mtu		= ETH_DATA_LEN;
 	dev->flags		= IFF_NOARP;
 	dev->addr_len		= 4;
 	dev->features		|= NETIF_F_LLTX;

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #164 lore raw

PATCH 142/268 perf/cgroup: Fix child event counting bug

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

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

From: Song Liu <[email protected]>

[ Upstream commit c917e0f259908e75bd2a65877e25f9d90c22c848 ]

When a perf_event is attached to parent cgroup, it should count events for all children cgroups:

parent_group <---- perf_event
\
- child_group <---- process(es)

However, in our tests, we found this perf_event cannot report reliable results. Here is an example case:

  # create cgroups
  mkdir -p /sys/fs/cgroup/p/c
  # start perf for parent group
  perf stat -e instructions -G "p"

  # on another console, run test process in child cgroup:
  stressapptest -s 2 -M 1000 & echo $! > /sys/fs/cgroup/p/c/cgroup.procs

  # after the test process is done, stop perf in the first console shows

<not counted> instructions p

The instruction should not be "not counted" as the process runs in the child cgroup.

We found this is because perf_event->cgrp and cpuctx->cgrp are not identical, thus perf_event->cgrp are not updated properly.

This patch fixes this by updating perf_cgroup properly for ancestor cgroup(s).

Reported-by Ephraim Park <[email protected]>

Signed-off-by Song Liu <[email protected]>

Signed-off-by Peter Zijlstra (Intel) <[email protected]>

Cc Alexander Shishkin <[email protected]>

Cc Arnaldo Carvalho de Melo <[email protected]>

Cc Jiri Olsa <[email protected]>

Cc Linus Torvalds <[email protected]>

Cc Peter Zijlstra <[email protected]>

Cc Stephane Eranian <[email protected]>

Cc Thomas Gleixner <[email protected]>

Cc Vince Weaver <[email protected]>

Link http://lkml.kernel.org/r/[email protected] open here

Signed-off-by Ingo Molnar <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

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

kernel/events/core.c +16 -5

@@ -419,9 +419,15 @@ static inline void __update_cgrp_time(st
 
 static inline void update_cgrp_time_from_cpuctx(struct perf_cpu_context *cpuctx)
 {
-	struct perf_cgroup *cgrp_out = cpuctx->cgrp;
-	if (cgrp_out)
-		__update_cgrp_time(cgrp_out);
+	struct perf_cgroup *cgrp = cpuctx->cgrp;
+	struct cgroup_subsys_state *css;
+
+	if (cgrp) {
+		for (css = &cgrp->css; css; css = css->parent) {
+			cgrp = container_of(css, struct perf_cgroup, css);
+			__update_cgrp_time(cgrp);
+		}
+	}
 }
 
 static inline void update_cgrp_time_from_event(struct perf_event *event)

@@ -449,6 +455,7 @@ perf_cgroup_set_timestamp(struct task_st
 {
 	struct perf_cgroup *cgrp;
 	struct perf_cgroup_info *info;
+	struct cgroup_subsys_state *css;
 
 	/*
 	 * ctx->lock held by caller

@@ -459,8 +466,12 @@ perf_cgroup_set_timestamp(struct task_st
 		return;
 
 	cgrp = perf_cgroup_from_task(task, ctx);
-	info = this_cpu_ptr(cgrp->info);
-	info->timestamp = ctx->timestamp;
+
+	for (css = &cgrp->css; css; css = css->parent) {
+		cgrp = container_of(css, struct perf_cgroup, css);
+		info = this_cpu_ptr(cgrp->info);
+		info->timestamp = ctx->timestamp;
+	}
 }
 
 #define PERF_CGROUP_SWOUT	0x1 /* cgroup switch out every event */

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #165 lore raw

PATCH 143/268 RDMA/ucma: Correct option size check using optlen

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

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

From: Chien Tin Tung <[email protected]>

[ Upstream commit 5f3e3b85cc0a5eae1c46d72e47d3de7bf208d9e2 ]

The option size check is using optval instead of optlen causing the set option call to fail. Use the correct field, optlen, for size check.

Fixes 6a21dfc0d0db ("RDMA/ucma: Limit possible option size")

Signed-off-by Chien Tin Tung <[email protected]>

Signed-off-by Shiraz Saleem <[email protected]>

Reviewed-by Leon Romanovsky <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 drivers/infiniband/core/ucma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/infiniband/core/ucma.c +1 -1

@@ -1295,7 +1295,7 @@ static ssize_t ucma_set_option(struct uc
 	if (IS_ERR(ctx))
 		return PTR_ERR(ctx);
 
-	if (unlikely(cmd.optval > KMALLOC_MAX_SIZE))
+	if (unlikely(cmd.optlen > KMALLOC_MAX_SIZE))
 		return -EINVAL;
 
 	optval = memdup_user((void __user *) (unsigned long) cmd.optval,

Greg Kroah-Hartman

author maintainer

2018-05-28 10:20 UTC #166 lore raw

PATCH 144/268 mm/mempolicy.c: avoid use uninitialized preferred_node

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

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

From: Yisheng Xie <[email protected]>

[ Upstream commit 8970a63e965b43288c4f5f40efbc2bbf80de7f16 ]

Alexander reported a use of uninitialized memory in __mpol_equal(), which is caused by incorrect use of preferred_node.

When mempolicy in mode MPOL_PREFERRED with flags MPOL_F_LOCAL, it uses numa_node_id() instead of preferred_node, however, __mpol_equal() uses preferred_node without checking whether it is MPOL_F_LOCAL or not.

[[email protected]: slight comment tweak]

Link http://lkml.kernel.org/r/[email protected] open here

Fixes fc36b8d3d819 ("mempolicy: use MPOL_F_LOCAL to Indicate Preferred Local Policy")

Signed-off-by Yisheng Xie <[email protected]>

Reported-by Alexander Potapenko <[email protected]>

Tested-by Alexander Potapenko <[email protected]>

Reviewed-by Andrew Morton <[email protected]>

Cc Dmitriy Vyukov <[email protected]>

Cc Vlastimil Babka <[email protected]>

Cc Michal Hocko <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 mm/mempolicy.c |    3 +++
 1 file changed, 3 insertions(+)

mm/mempolicy.c +3 -0

@@ -2142,6 +2142,9 @@ bool __mpol_equal(struct mempolicy *a, s
 	case MPOL_INTERLEAVE:
 		return !!nodes_equal(a->v.nodes, b->v.nodes);
 	case MPOL_PREFERRED:
+		/* a's ->flags is the same as b's */
+		if (a->flags & MPOL_F_LOCAL)
+			return true;
 		return a->v.preferred_node == b->v.preferred_node;
 	default:
 		BUG();

Greg Kroah-Hartman

author maintainer

2018-05-28 10:22 UTC #167 lore raw

PATCH 145/268 selftests: ftrace: Add probe event argument syntax testcase

Link http://lkml.kernel.org/r/152129033679.31874.12705519603869152799.stgit@devbox open here

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

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

From: Masami Hiramatsu <[email protected]>

[ Upstream commit 871bef2000968c312a4000b2f56d370dcedbc93c ]

Add a testcase for probe event argument syntax which ensures the kprobe_events interface correctly parses given event arguments.

Signed-off-by Masami Hiramatsu <[email protected]>

Signed-off-by Steven Rostedt (VMware) <[email protected]>

Signed-off-by Sasha Levin <[email protected]>

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

---
 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc |   97 ++++++++++
 1 file changed, 97 insertions(+)
 create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc

tools/testing/selftests/ftrace/test.d/kprobe/kprobe_args_syntax.tc new file +97 -0

@@ -0,0 +1,97 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: Kprobe event argument syntax
+
+[ -f kprobe_events ] || exit_unsupported # this is configurable
+
+grep "x8/16/32/64" README > /dev/null || exit_unsupported # version issue
+
+echo 0 > events/enable
+echo > kprobe_events
+
+PROBEFUNC="vfs_read"
+GOODREG=
+BADREG=
+GOODSYM="_sdata"
+if ! grep -qw ${GOODSYM} /proc/kallsyms ; then
+  GOODSYM=$PROBEFUNC
+fi
+BADSYM="deaqswdefr"
+SYMADDR=0x`grep -w ${GOODSYM} /proc/kallsyms | cut -f 1 -d " "`
+GOODTYPE="x16"
+BADTYPE="y16"
+
+case `uname -m` in
+x86_64|i[3456]86)
+  GOODREG=%ax
+  BADREG=%ex
+;;
+aarch64)
+  GOODREG=%x0
+  BADREG=%ax
+;;
+arm*)
+  GOODREG=%r0
+  BADREG=%ax
+;;
+esac
+
+test_goodarg() # Good-args
+{
+  while [ "$1" ]; do
+    echo "p ${PROBEFUNC} $1" > kprobe_events
+    shift 1
+  done;
+}
+
+test_badarg() # Bad-args
+{
+  while [ "$1" ]; do
+    ! echo "p ${PROBEFUNC} $1" > kprobe_events
+    shift 1
+  done;
+}
+
+echo > kprobe_events
+
+: "Register access"
+test_goodarg ${GOODREG}
+test_badarg ${BADREG}
+
+: "Symbol access"
+test_goodarg "@${GOODSYM}" "@${SYMADDR}" "@${GOODSYM}+10" "@${GOODSYM}-10"
+test_badarg "@" "@${BADSYM}" "@${GOODSYM}*10" "@${GOODSYM}/10" \
+	    "@${GOODSYM}%10" "@${GOODSYM}&10" "@${GOODSYM}|10"
+
+: "Stack access"
+test_goodarg "\$stack" "\$stack0" "\$stack1"
+test_badarg "\$stackp" "\$stack0+10" "\$stack1-10"
+
+: "Retval access"
+echo "r ${PROBEFUNC} \$retval" > kprobe_events
+! echo "p ${PROBEFUNC} \$retval" > kprobe_events
+
+: "Comm access"
+test_goodarg "\$comm"
+
+: "Indirect memory access"
+test_goodarg "+0(${GOODREG})" "-0(${GOODREG})" "+10(\$stack)" \
+	"+0(\$stack1)" "+10(@${GOODSYM}-10)" "+0(+10(+20(\$stack)))"
+test_badarg "+(${GOODREG})" "(${GOODREG}+10)" "-(${GOODREG})" "(${GOODREG})" \
+	"+10(\$comm)" "+0(${GOODREG})+10"
+
+: "Name assignment"
+test_goodarg "varname=${GOODREG}"
+test_badarg "varname=varname2=${GOODREG}"
+
+: "Type syntax"
+test_goodarg "${GOODREG}:${GOODTYPE}"
+test_badarg "${GOODREG}::${GOODTYPE}" "${GOODREG}:${BADTYPE}" \
+	"${GOODTYPE}:${GOODREG}"
+
+: "Combination check"
+
+test_goodarg "\$comm:string" "+0(\$stack):string"
+test_badarg "\$comm:x64" "\$stack:string" "${GOODREG}:string"
+
+echo > kprobe_events

Greg Kroah-Hartman

author maintainer

2018-05-28 10:02 UTC #168 lore raw

PATCH 146/268 selftests: ftrace: Add a testcase for string type with kprobe_event