[PATCH 4.9 00/14] 4.9.50-stable review

[PATCH 4.9 00/14] 4.9.50-stable review

[Greg Kroah-Hartman]

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

Responses should be made by Thu Sep 14 16:52:45 UTC 2017.
Anything received after that time might be too late.

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

thanks,

greg k-h

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

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

tarangg@amazon.com <tarangg@amazon.com>
    NFS: Sync the correct byte range during synchronous writes

Trond Myklebust <trond.myklebust@primarydata.com>
    NFS: Fix 2 use after free issues in the I/O code

Mark Rutland <mark.rutland@arm.com>
    ARM: 8692/1: mm: abort uaccess retries upon fatal signal

Marc Zyngier <marc.zyngier@arm.com>
    ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt

Ben Seri <ben@armis.com>
    Bluetooth: Properly check L2CAP config option output buffer length

Takashi Iwai <tiwai@suse.de>
    ALSA: msnd: Optimize / harden DSP and MIDI loops

Yang Shi <yang.shi@linaro.org>
    locktorture: Fix potential memory leak with rw lock test

Laurent Dufour <ldufour@linux.vnet.ibm.com>
    mm/memory.c: fix mem_cgroup_oom_disable() call missing

Andy Lutomirski <luto@kernel.org>
    selftests/x86/fsgsbase: Test selectors 1, 2, and 3

Aleksa Sarai <asarai@suse.de>
    btrfs: resume qgroup rescan on rw remount

Daniel Verkamp <daniel.verkamp@intel.com>
    nvme-fabrics: generate spec-compliant UUID NQNs

Abhishek Sahu <absahu@codeaurora.org>
    mtd: nand: qcom: fix config error for BCH

Abhishek Sahu <absahu@codeaurora.org>
    mtd: nand: qcom: fix read failure without complete bootchain

Boris Brezillon <boris.brezillon@free-electrons.com>
    mtd: nand: mxc: Fix mxc_v1 ooblayout


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

Diffstat:

 Makefile                                     |  4 +-
 arch/arm/mm/fault.c                          |  5 +-
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi |  1 +
 drivers/mtd/nand/mxc_nand.c                  |  7 +--
 drivers/mtd/nand/qcom_nandc.c                | 18 +++++--
 drivers/nvme/host/fabrics.c                  |  2 +-
 fs/btrfs/super.c                             |  2 +
 fs/nfs/file.c                                |  6 +--
 fs/nfs/internal.h                            |  1 -
 fs/nfs/pagelist.c                            | 26 +++++----
 fs/nfs/pnfs.c                                |  2 -
 kernel/locking/locktorture.c                 |  6 +++
 mm/memory.c                                  | 10 ++--
 net/bluetooth/l2cap_core.c                   | 80 +++++++++++++++-------------
 sound/isa/msnd/msnd_midi.c                   | 30 +++++------
 sound/isa/msnd/msnd_pinnacle.c               | 23 ++++----
 tools/testing/selftests/x86/fsgsbase.c       | 41 +++++++++++---
 17 files changed, 158 insertions(+), 106 deletions(-)

[PATCH 4.9 01/14] mtd: nand: mxc: Fix mxc_v1 ooblayout

[Greg Kroah-Hartman]

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

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

From: Boris Brezillon <boris.brezillon@free-electrons.com>

commit 3bff08dffe3115a25ce04b95ea75f6d868572c60 upstream.

Commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
introduced a bug in the OOB layout description. Even if the driver claims
that 3 ECC bytes are reserved to protect 512 bytes of data, it's actually
5 ECC bytes to protect 512+6 bytes of data (some OOB bytes are also
protected using extra ECC bytes).

Fix the mxc_v1_ooblayout_{free,ecc}() functions to reflect this behavior.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Fixes: a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/nand/mxc_nand.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

--- a/drivers/mtd/nand/mxc_nand.c
+++ b/drivers/mtd/nand/mxc_nand.c
@@ -877,6 +877,8 @@ static void mxc_do_addr_cycle(struct mtd
 	}
 }
 
+#define MXC_V1_ECCBYTES		5
+
 static int mxc_v1_ooblayout_ecc(struct mtd_info *mtd, int section,
 				struct mtd_oob_region *oobregion)
 {
@@ -886,7 +888,7 @@ static int mxc_v1_ooblayout_ecc(struct m
 		return -ERANGE;
 
 	oobregion->offset = (section * 16) + 6;
-	oobregion->length = nand_chip->ecc.bytes;
+	oobregion->length = MXC_V1_ECCBYTES;
 
 	return 0;
 }
@@ -908,8 +910,7 @@ static int mxc_v1_ooblayout_free(struct
 			oobregion->length = 4;
 		}
 	} else {
-		oobregion->offset = ((section - 1) * 16) +
-				    nand_chip->ecc.bytes + 6;
+		oobregion->offset = ((section - 1) * 16) + MXC_V1_ECCBYTES + 6;
 		if (section < nand_chip->ecc.steps)
 			oobregion->length = (section * 16) + 6 -
 					    oobregion->offset;

[PATCH 4.9 02/14] mtd: nand: qcom: fix read failure without complete bootchain

[Greg Kroah-Hartman]

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

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

From: Abhishek Sahu <absahu@codeaurora.org>

commit d8a9b320a26c1ea28e51e4f3ecfb593d5aac2910 upstream.

The NAND page read fails without complete boot chain since
NAND_DEV_CMD_VLD value is not proper. The default power on reset
value for this register is

    0xe - ERASE_START_VALID | WRITE_START_VALID | READ_STOP_VALID

The READ_START_VALID should be enabled for sending PAGE_READ
command. READ_STOP_VALID should be cleared since normal NAND
page read does not require READ_STOP command.

Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver")
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/nand/qcom_nandc.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -109,7 +109,11 @@
 #define	READ_ADDR			0
 
 /* NAND_DEV_CMD_VLD bits */
-#define	READ_START_VLD			0
+#define	READ_START_VLD			BIT(0)
+#define	READ_STOP_VLD			BIT(1)
+#define	WRITE_START_VLD			BIT(2)
+#define	ERASE_START_VLD			BIT(3)
+#define	SEQ_READ_START_VLD		BIT(4)
 
 /* NAND_EBI2_ECC_BUF_CFG bits */
 #define	NUM_STEPS			0
@@ -148,6 +152,10 @@
 #define	FETCH_ID			0xb
 #define	RESET_DEVICE			0xd
 
+/* Default Value for NAND_DEV_CMD_VLD */
+#define NAND_DEV_CMD_VLD_VAL		(READ_START_VLD | WRITE_START_VLD | \
+					 ERASE_START_VLD | SEQ_READ_START_VLD)
+
 /*
  * the NAND controller performs reads/writes with ECC in 516 byte chunks.
  * the driver calls the chunks 'step' or 'codeword' interchangeably
@@ -672,8 +680,7 @@ static int nandc_param(struct qcom_nand_
 
 	/* configure CMD1 and VLD for ONFI param probing */
 	nandc_set_reg(nandc, NAND_DEV_CMD_VLD,
-		      (nandc->vld & ~(1 << READ_START_VLD))
-		      | 0 << READ_START_VLD);
+		      (nandc->vld & ~READ_START_VLD));
 	nandc_set_reg(nandc, NAND_DEV_CMD1,
 		      (nandc->cmd1 & ~(0xFF << READ_ADDR))
 		      | NAND_CMD_PARAM << READ_ADDR);
@@ -1972,13 +1979,14 @@ static int qcom_nandc_setup(struct qcom_
 {
 	/* kill onenand */
 	nandc_write(nandc, SFLASHC_BURST_CFG, 0);
+	nandc_write(nandc, NAND_DEV_CMD_VLD, NAND_DEV_CMD_VLD_VAL);
 
 	/* enable ADM DMA */
 	nandc_write(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
 
 	/* save the original values of these registers */
 	nandc->cmd1 = nandc_read(nandc, NAND_DEV_CMD1);
-	nandc->vld = nandc_read(nandc, NAND_DEV_CMD_VLD);
+	nandc->vld = NAND_DEV_CMD_VLD_VAL;
 
 	return 0;
 }

[PATCH 4.9 03/14] mtd: nand: qcom: fix config error for BCH

[Greg Kroah-Hartman]

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

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

From: Abhishek Sahu <absahu@codeaurora.org>

commit 10777de570016471fd929869c7830a7772893e39 upstream.

The configuration for BCH is not correct in the current driver.
The ECC_CFG_ECC_DISABLE bit defines whether to enable or disable the
BCH ECC in which

	0x1 : BCH_DISABLED
	0x0 : BCH_ENABLED

But currently host->bch_enabled is being assigned to BCH_DISABLED.

Fixes: c76b78d8ec05a ("mtd: nand: Qualcomm NAND controller driver")
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/mtd/nand/qcom_nandc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/mtd/nand/qcom_nandc.c
+++ b/drivers/mtd/nand/qcom_nandc.c
@@ -1900,7 +1900,7 @@ static int qcom_nand_host_setup(struct q
 				| wide_bus << WIDE_FLASH
 				| 1 << DEV0_CFG1_ECC_DISABLE;
 
-	host->ecc_bch_cfg = host->bch_enabled << ECC_CFG_ECC_DISABLE
+	host->ecc_bch_cfg = !host->bch_enabled << ECC_CFG_ECC_DISABLE
 				| 0 << ECC_SW_RESET
 				| host->cw_data << ECC_NUM_DATA_BYTES
 				| 1 << ECC_FORCE_CLK_OPEN

[PATCH 4.9 04/14] nvme-fabrics: generate spec-compliant UUID NQNs

[Greg Kroah-Hartman]

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

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

From: Daniel Verkamp <daniel.verkamp@intel.com>

commit 40a5fce495715c48c2e02668144e68a507ac5a30 upstream.

The default host NQN, which is generated based on the host's UUID,
does not follow the UUID-based NQN format laid out in the NVMe 1.3
specification.  Remove the "NVMf:" portion of the NQN to match the spec.

Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/nvme/host/fabrics.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/nvme/host/fabrics.c
+++ b/drivers/nvme/host/fabrics.c
@@ -77,7 +77,7 @@ static struct nvmf_host *nvmf_host_defau
 	kref_init(&host->ref);
 	uuid_be_gen(&host->id);
 	snprintf(host->nqn, NVMF_NQN_SIZE,
-		"nqn.2014-08.org.nvmexpress:NVMf:uuid:%pUb", &host->id);
+		"nqn.2014-08.org.nvmexpress:uuid:%pUb", &host->id);
 
 	mutex_lock(&nvmf_hosts_mutex);
 	list_add_tail(&host->list, &nvmf_hosts);

[PATCH 4.9 05/14] btrfs: resume qgroup rescan on rw remount

[Greg Kroah-Hartman]

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

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

From: Aleksa Sarai <asarai@suse.de>

commit 6c6b5a39c4bf3dbd8cf629c9f5450e983c19dbb9 upstream.

Several distributions mount the "proper root" as ro during initrd and
then remount it as rw before pivot_root(2). Thus, if a rescan had been
aborted by a previous shutdown, the rescan would never be resumed.

This issue would manifest itself as several btrfs ioctl(2)s causing the
entire machine to hang when btrfs_qgroup_wait_for_completion was hit
(due to the fs_info->qgroup_rescan_running flag being set but the rescan
itself not being resumed). Notably, Docker's btrfs storage driver makes
regular use of BTRFS_QUOTA_CTL_DISABLE and BTRFS_IOC_QUOTA_RESCAN_WAIT
(causing this problem to be manifested on boot for some machines).

Cc: Jeff Mahoney <jeffm@suse.com>
Fixes: b382a324b60f ("Btrfs: fix qgroup rescan resume on mount")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Tested-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

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

--- a/fs/btrfs/super.c
+++ b/fs/btrfs/super.c
@@ -1834,6 +1834,8 @@ static int btrfs_remount(struct super_bl
 			goto restore;
 		}
 
+		btrfs_qgroup_rescan_resume(fs_info);
+
 		if (!fs_info->uuid_root) {
 			btrfs_info(fs_info, "creating UUID tree");
 			ret = btrfs_create_uuid_tree(fs_info);

[PATCH 4.9 06/14] selftests/x86/fsgsbase: Test selectors 1, 2, and 3

[Greg Kroah-Hartman]

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

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

From: Andy Lutomirski <luto@kernel.org>

commit 23d98c204386a98d9ef9f9e744f41443ece4929f upstream.

Those are funny cases.  Make sure they work.

(Something is screwy with signal handling if a selector is 1, 2, or 3.
Anyone who wants to dive into that rabbit hole is welcome to do so.)

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bpetkov@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Chang Seok <chang.seok.bae@intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/testing/selftests/x86/fsgsbase.c |   41 ++++++++++++++++++++++++++++-----
 1 file changed, 35 insertions(+), 6 deletions(-)

--- a/tools/testing/selftests/x86/fsgsbase.c
+++ b/tools/testing/selftests/x86/fsgsbase.c
@@ -285,9 +285,12 @@ static void *threadproc(void *ctx)
 	}
 }
 
-static void set_gs_and_switch_to(unsigned long local, unsigned long remote)
+static void set_gs_and_switch_to(unsigned long local,
+				 unsigned short force_sel,
+				 unsigned long remote)
 {
 	unsigned long base;
+	unsigned short sel_pre_sched, sel_post_sched;
 
 	bool hard_zero = false;
 	if (local == HARD_ZERO) {
@@ -297,6 +300,8 @@ static void set_gs_and_switch_to(unsigne
 
 	printf("[RUN]\tARCH_SET_GS(0x%lx)%s, then schedule to 0x%lx\n",
 	       local, hard_zero ? " and clear gs" : "", remote);
+	if (force_sel)
+		printf("\tBefore schedule, set selector to 0x%hx\n", force_sel);
 	if (syscall(SYS_arch_prctl, ARCH_SET_GS, local) != 0)
 		err(1, "ARCH_SET_GS");
 	if (hard_zero)
@@ -307,18 +312,35 @@ static void set_gs_and_switch_to(unsigne
 		printf("[FAIL]\tGSBASE wasn't set as expected\n");
 	}
 
+	if (force_sel) {
+		asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
+		sel_pre_sched = force_sel;
+		local = read_base(GS);
+
+		/*
+		 * Signal delivery seems to mess up weird selectors.  Put it
+		 * back.
+		 */
+		asm volatile ("mov %0, %%gs" : : "rm" (force_sel));
+	} else {
+		asm volatile ("mov %%gs, %0" : "=rm" (sel_pre_sched));
+	}
+
 	remote_base = remote;
 	ftx = 1;
 	syscall(SYS_futex, &ftx, FUTEX_WAKE, 0, NULL, NULL, 0);
 	while (ftx != 0)
 		syscall(SYS_futex, &ftx, FUTEX_WAIT, 1, NULL, NULL, 0);
 
+	asm volatile ("mov %%gs, %0" : "=rm" (sel_post_sched));
 	base = read_base(GS);
-	if (base == local) {
-		printf("[OK]\tGSBASE remained 0x%lx\n", local);
+	if (base == local && sel_pre_sched == sel_post_sched) {
+		printf("[OK]\tGS/BASE remained 0x%hx/0x%lx\n",
+		       sel_pre_sched, local);
 	} else {
 		nerrs++;
-		printf("[FAIL]\tGSBASE changed to 0x%lx\n", base);
+		printf("[FAIL]\tGS/BASE changed from 0x%hx/0x%lx to 0x%hx/0x%lx\n",
+		       sel_pre_sched, local, sel_post_sched, base);
 	}
 }
 
@@ -381,8 +403,15 @@ int main()
 
 	for (int local = 0; local < 4; local++) {
 		for (int remote = 0; remote < 4; remote++) {
-			set_gs_and_switch_to(bases_with_hard_zero[local],
-					     bases_with_hard_zero[remote]);
+			for (unsigned short s = 0; s < 5; s++) {
+				unsigned short sel = s;
+				if (s == 4)
+					asm ("mov %%ss, %0" : "=rm" (sel));
+				set_gs_and_switch_to(
+					bases_with_hard_zero[local],
+					sel,
+					bases_with_hard_zero[remote]);
+			}
 		}
 	}
 

[PATCH 4.9 07/14] mm/memory.c: fix mem_cgroup_oom_disable() call missing

[Greg Kroah-Hartman]

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

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

From: Laurent Dufour <ldufour@linux.vnet.ibm.com>

commit de0c799bba2610a8e1e9a50d76a28614520a4cd4 upstream.

Seen while reading the code, in handle_mm_fault(), in the case
arch_vma_access_permitted() is failing the call to
mem_cgroup_oom_disable() is not made.

To fix that, move the call to mem_cgroup_oom_enable() after calling
arch_vma_access_permitted() as it should not have entered the memcg OOM.

Link: http://lkml.kernel.org/r/1504625439-31313-1-git-send-email-ldufour@linux.vnet.ibm.com
Fixes: bae473a423f6 ("mm: introduce fault_env")
Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Acked-by: Kirill A. Shutemov <kirill@shutemov.name>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 mm/memory.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3596,6 +3596,11 @@ int handle_mm_fault(struct vm_area_struc
 	/* do counter updates before entering really critical section. */
 	check_sync_rss_stat(current);
 
+	if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
+					    flags & FAULT_FLAG_INSTRUCTION,
+					    flags & FAULT_FLAG_REMOTE))
+		return VM_FAULT_SIGSEGV;
+
 	/*
 	 * Enable the memcg OOM handling for faults triggered in user
 	 * space.  Kernel faults are handled more gracefully.
@@ -3603,11 +3608,6 @@ int handle_mm_fault(struct vm_area_struc
 	if (flags & FAULT_FLAG_USER)
 		mem_cgroup_oom_enable();
 
-	if (!arch_vma_access_permitted(vma, flags & FAULT_FLAG_WRITE,
-					    flags & FAULT_FLAG_INSTRUCTION,
-					    flags & FAULT_FLAG_REMOTE))
-		return VM_FAULT_SIGSEGV;
-
 	if (unlikely(is_vm_hugetlb_page(vma)))
 		ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
 	else

[PATCH 4.9 09/14] ALSA: msnd: Optimize / harden DSP and MIDI loops

[Greg Kroah-Hartman]

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

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

From: Takashi Iwai <tiwai@suse.de>

commit 20e2b791796bd68816fa115f12be5320de2b8021 upstream.

The ISA msnd drivers have loops fetching the ring-buffer head, tail
and size values inside the loops.  Such codes are inefficient and
fragile.

This patch optimizes it, and also adds the sanity check to avoid the
endless loops.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196131
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196133
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: grygorii tertychnyi <gtertych@cisco.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 sound/isa/msnd/msnd_midi.c     |   28 ++++++++++++++--------------
 sound/isa/msnd/msnd_pinnacle.c |   23 ++++++++++++-----------
 2 files changed, 26 insertions(+), 25 deletions(-)

--- a/sound/isa/msnd/msnd_midi.c
+++ b/sound/isa/msnd/msnd_midi.c
@@ -120,24 +120,24 @@ void snd_msndmidi_input_read(void *mpuv)
 	unsigned long flags;
 	struct snd_msndmidi *mpu = mpuv;
 	void *pwMIDQData = mpu->dev->mappedbase + MIDQ_DATA_BUFF;
+	u16 head, tail, size;
 
 	spin_lock_irqsave(&mpu->input_lock, flags);
-	while (readw(mpu->dev->MIDQ + JQS_wTail) !=
-	       readw(mpu->dev->MIDQ + JQS_wHead)) {
-		u16 wTmp, val;
-		val = readw(pwMIDQData + 2 * readw(mpu->dev->MIDQ + JQS_wHead));
+	head = readw(mpu->dev->MIDQ + JQS_wHead);
+	tail = readw(mpu->dev->MIDQ + JQS_wTail);
+	size = readw(mpu->dev->MIDQ + JQS_wSize);
+	if (head > size || tail > size)
+		goto out;
+	while (head != tail) {
+		unsigned char val = readw(pwMIDQData + 2 * head);
 
-			if (test_bit(MSNDMIDI_MODE_BIT_INPUT_TRIGGER,
-				     &mpu->mode))
-				snd_rawmidi_receive(mpu->substream_input,
-						    (unsigned char *)&val, 1);
-
-		wTmp = readw(mpu->dev->MIDQ + JQS_wHead) + 1;
-		if (wTmp > readw(mpu->dev->MIDQ + JQS_wSize))
-			writew(0,  mpu->dev->MIDQ + JQS_wHead);
-		else
-			writew(wTmp,  mpu->dev->MIDQ + JQS_wHead);
+		if (test_bit(MSNDMIDI_MODE_BIT_INPUT_TRIGGER, &mpu->mode))
+			snd_rawmidi_receive(mpu->substream_input, &val, 1);
+		if (++head > size)
+			head = 0;
+		writew(head, mpu->dev->MIDQ + JQS_wHead);
 	}
+ out:
 	spin_unlock_irqrestore(&mpu->input_lock, flags);
 }
 EXPORT_SYMBOL(snd_msndmidi_input_read);
--- a/sound/isa/msnd/msnd_pinnacle.c
+++ b/sound/isa/msnd/msnd_pinnacle.c
@@ -170,23 +170,24 @@ static irqreturn_t snd_msnd_interrupt(in
 {
 	struct snd_msnd *chip = dev_id;
 	void *pwDSPQData = chip->mappedbase + DSPQ_DATA_BUFF;
+	u16 head, tail, size;
 
 	/* Send ack to DSP */
 	/* inb(chip->io + HP_RXL); */
 
 	/* Evaluate queued DSP messages */
-	while (readw(chip->DSPQ + JQS_wTail) != readw(chip->DSPQ + JQS_wHead)) {
-		u16 wTmp;
-
-		snd_msnd_eval_dsp_msg(chip,
-			readw(pwDSPQData + 2 * readw(chip->DSPQ + JQS_wHead)));
-
-		wTmp = readw(chip->DSPQ + JQS_wHead) + 1;
-		if (wTmp > readw(chip->DSPQ + JQS_wSize))
-			writew(0, chip->DSPQ + JQS_wHead);
-		else
-			writew(wTmp, chip->DSPQ + JQS_wHead);
+	head = readw(chip->DSPQ + JQS_wHead);
+	tail = readw(chip->DSPQ + JQS_wTail);
+	size = readw(chip->DSPQ + JQS_wSize);
+	if (head > size || tail > size)
+		goto out;
+	while (head != tail) {
+		snd_msnd_eval_dsp_msg(chip, readw(pwDSPQData + 2 * head));
+		if (++head > size)
+			head = 0;
+		writew(head, chip->DSPQ + JQS_wHead);
 	}
+ out:
 	/* Send ack to DSP */
 	inb(chip->io + HP_RXL);
 	return IRQ_HANDLED;

[PATCH 4.9 10/14] Bluetooth: Properly check L2CAP config option output buffer length

[Greg Kroah-Hartman]

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

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

From: Ben Seri <ben@armis.com>

commit e860d2c904d1a9f38a24eb44c9f34b8f915a6ea3 upstream.

Validate the output buffer length for L2CAP config requests and responses
to avoid overflowing the stack buffer used for building the option blocks.

Signed-off-by: Ben Seri <ben@armis.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 net/bluetooth/l2cap_core.c |   80 ++++++++++++++++++++++++---------------------
 1 file changed, 43 insertions(+), 37 deletions(-)

--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -58,7 +58,7 @@ static struct sk_buff *l2cap_build_cmd(s
 				       u8 code, u8 ident, u16 dlen, void *data);
 static void l2cap_send_cmd(struct l2cap_conn *conn, u8 ident, u8 code, u16 len,
 			   void *data);
-static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data);
+static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data, size_t data_size);
 static void l2cap_send_disconn_req(struct l2cap_chan *chan, int err);
 
 static void l2cap_tx(struct l2cap_chan *chan, struct l2cap_ctrl *control,
@@ -1473,7 +1473,7 @@ static void l2cap_conn_start(struct l2ca
 
 			set_bit(CONF_REQ_SENT, &chan->conf_state);
 			l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
-				       l2cap_build_conf_req(chan, buf), buf);
+				       l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
 			chan->num_conf_req++;
 		}
 
@@ -2977,12 +2977,15 @@ static inline int l2cap_get_conf_opt(voi
 	return len;
 }
 
-static void l2cap_add_conf_opt(void **ptr, u8 type, u8 len, unsigned long val)
+static void l2cap_add_conf_opt(void **ptr, u8 type, u8 len, unsigned long val, size_t size)
 {
 	struct l2cap_conf_opt *opt = *ptr;
 
 	BT_DBG("type 0x%2.2x len %u val 0x%lx", type, len, val);
 
+	if (size < L2CAP_CONF_OPT_SIZE + len)
+		return;
+
 	opt->type = type;
 	opt->len  = len;
 
@@ -3007,7 +3010,7 @@ static void l2cap_add_conf_opt(void **pt
 	*ptr += L2CAP_CONF_OPT_SIZE + len;
 }
 
-static void l2cap_add_opt_efs(void **ptr, struct l2cap_chan *chan)
+static void l2cap_add_opt_efs(void **ptr, struct l2cap_chan *chan, size_t size)
 {
 	struct l2cap_conf_efs efs;
 
@@ -3035,7 +3038,7 @@ static void l2cap_add_opt_efs(void **ptr
 	}
 
 	l2cap_add_conf_opt(ptr, L2CAP_CONF_EFS, sizeof(efs),
-			   (unsigned long) &efs);
+			   (unsigned long) &efs, size);
 }
 
 static void l2cap_ack_timeout(struct work_struct *work)
@@ -3181,11 +3184,12 @@ static inline void l2cap_txwin_setup(str
 	chan->ack_win = chan->tx_win;
 }
 
-static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data)
+static int l2cap_build_conf_req(struct l2cap_chan *chan, void *data, size_t data_size)
 {
 	struct l2cap_conf_req *req = data;
 	struct l2cap_conf_rfc rfc = { .mode = chan->mode };
 	void *ptr = req->data;
+	void *endptr = data + data_size;
 	u16 size;
 
 	BT_DBG("chan %p", chan);
@@ -3210,7 +3214,7 @@ static int l2cap_build_conf_req(struct l
 
 done:
 	if (chan->imtu != L2CAP_DEFAULT_MTU)
-		l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu);
+		l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu, endptr - ptr);
 
 	switch (chan->mode) {
 	case L2CAP_MODE_BASIC:
@@ -3229,7 +3233,7 @@ done:
 		rfc.max_pdu_size    = 0;
 
 		l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
-				   (unsigned long) &rfc);
+				   (unsigned long) &rfc, endptr - ptr);
 		break;
 
 	case L2CAP_MODE_ERTM:
@@ -3249,21 +3253,21 @@ done:
 				       L2CAP_DEFAULT_TX_WINDOW);
 
 		l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
-				   (unsigned long) &rfc);
+				   (unsigned long) &rfc, endptr - ptr);
 
 		if (test_bit(FLAG_EFS_ENABLE, &chan->flags))
-			l2cap_add_opt_efs(&ptr, chan);
+			l2cap_add_opt_efs(&ptr, chan, endptr - ptr);
 
 		if (test_bit(FLAG_EXT_CTRL, &chan->flags))
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_EWS, 2,
-					   chan->tx_win);
+					   chan->tx_win, endptr - ptr);
 
 		if (chan->conn->feat_mask & L2CAP_FEAT_FCS)
 			if (chan->fcs == L2CAP_FCS_NONE ||
 			    test_bit(CONF_RECV_NO_FCS, &chan->conf_state)) {
 				chan->fcs = L2CAP_FCS_NONE;
 				l2cap_add_conf_opt(&ptr, L2CAP_CONF_FCS, 1,
-						   chan->fcs);
+						   chan->fcs, endptr - ptr);
 			}
 		break;
 
@@ -3281,17 +3285,17 @@ done:
 		rfc.max_pdu_size = cpu_to_le16(size);
 
 		l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
-				   (unsigned long) &rfc);
+				   (unsigned long) &rfc, endptr - ptr);
 
 		if (test_bit(FLAG_EFS_ENABLE, &chan->flags))
-			l2cap_add_opt_efs(&ptr, chan);
+			l2cap_add_opt_efs(&ptr, chan, endptr - ptr);
 
 		if (chan->conn->feat_mask & L2CAP_FEAT_FCS)
 			if (chan->fcs == L2CAP_FCS_NONE ||
 			    test_bit(CONF_RECV_NO_FCS, &chan->conf_state)) {
 				chan->fcs = L2CAP_FCS_NONE;
 				l2cap_add_conf_opt(&ptr, L2CAP_CONF_FCS, 1,
-						   chan->fcs);
+						   chan->fcs, endptr - ptr);
 			}
 		break;
 	}
@@ -3302,10 +3306,11 @@ done:
 	return ptr - data;
 }
 
-static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data)
+static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data_size)
 {
 	struct l2cap_conf_rsp *rsp = data;
 	void *ptr = rsp->data;
+	void *endptr = data + data_size;
 	void *req = chan->conf_req;
 	int len = chan->conf_len;
 	int type, hint, olen;
@@ -3407,7 +3412,7 @@ done:
 			return -ECONNREFUSED;
 
 		l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
-				   (unsigned long) &rfc);
+				   (unsigned long) &rfc, endptr - ptr);
 	}
 
 	if (result == L2CAP_CONF_SUCCESS) {
@@ -3420,7 +3425,7 @@ done:
 			chan->omtu = mtu;
 			set_bit(CONF_MTU_DONE, &chan->conf_state);
 		}
-		l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->omtu);
+		l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->omtu, endptr - ptr);
 
 		if (remote_efs) {
 			if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
@@ -3434,7 +3439,7 @@ done:
 
 				l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS,
 						   sizeof(efs),
-						   (unsigned long) &efs);
+						   (unsigned long) &efs, endptr - ptr);
 			} else {
 				/* Send PENDING Conf Rsp */
 				result = L2CAP_CONF_PENDING;
@@ -3467,7 +3472,7 @@ done:
 			set_bit(CONF_MODE_DONE, &chan->conf_state);
 
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
-					   sizeof(rfc), (unsigned long) &rfc);
+					   sizeof(rfc), (unsigned long) &rfc, endptr - ptr);
 
 			if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) {
 				chan->remote_id = efs.id;
@@ -3481,7 +3486,7 @@ done:
 					le32_to_cpu(efs.sdu_itime);
 				l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS,
 						   sizeof(efs),
-						   (unsigned long) &efs);
+						   (unsigned long) &efs, endptr - ptr);
 			}
 			break;
 
@@ -3495,7 +3500,7 @@ done:
 			set_bit(CONF_MODE_DONE, &chan->conf_state);
 
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
-					   (unsigned long) &rfc);
+					   (unsigned long) &rfc, endptr - ptr);
 
 			break;
 
@@ -3517,10 +3522,11 @@ done:
 }
 
 static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
-				void *data, u16 *result)
+				void *data, size_t size, u16 *result)
 {
 	struct l2cap_conf_req *req = data;
 	void *ptr = req->data;
+	void *endptr = data + size;
 	int type, olen;
 	unsigned long val;
 	struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_BASIC };
@@ -3538,13 +3544,13 @@ static int l2cap_parse_conf_rsp(struct l
 				chan->imtu = L2CAP_DEFAULT_MIN_MTU;
 			} else
 				chan->imtu = val;
-			l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu);
+			l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, chan->imtu, endptr - ptr);
 			break;
 
 		case L2CAP_CONF_FLUSH_TO:
 			chan->flush_to = val;
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_FLUSH_TO,
-					   2, chan->flush_to);
+					   2, chan->flush_to, endptr - ptr);
 			break;
 
 		case L2CAP_CONF_RFC:
@@ -3558,13 +3564,13 @@ static int l2cap_parse_conf_rsp(struct l
 			chan->fcs = 0;
 
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC,
-					   sizeof(rfc), (unsigned long) &rfc);
+					   sizeof(rfc), (unsigned long) &rfc, endptr - ptr);
 			break;
 
 		case L2CAP_CONF_EWS:
 			chan->ack_win = min_t(u16, val, chan->ack_win);
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_EWS, 2,
-					   chan->tx_win);
+					   chan->tx_win, endptr - ptr);
 			break;
 
 		case L2CAP_CONF_EFS:
@@ -3577,7 +3583,7 @@ static int l2cap_parse_conf_rsp(struct l
 				return -ECONNREFUSED;
 
 			l2cap_add_conf_opt(&ptr, L2CAP_CONF_EFS, sizeof(efs),
-					   (unsigned long) &efs);
+					   (unsigned long) &efs, endptr - ptr);
 			break;
 
 		case L2CAP_CONF_FCS:
@@ -3682,7 +3688,7 @@ void __l2cap_connect_rsp_defer(struct l2
 		return;
 
 	l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
-		       l2cap_build_conf_req(chan, buf), buf);
+		       l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
 	chan->num_conf_req++;
 }
 
@@ -3890,7 +3896,7 @@ sendresp:
 		u8 buf[128];
 		set_bit(CONF_REQ_SENT, &chan->conf_state);
 		l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
-			       l2cap_build_conf_req(chan, buf), buf);
+			       l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
 		chan->num_conf_req++;
 	}
 
@@ -3968,7 +3974,7 @@ static int l2cap_connect_create_rsp(stru
 			break;
 
 		l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
-			       l2cap_build_conf_req(chan, req), req);
+			       l2cap_build_conf_req(chan, req, sizeof(req)), req);
 		chan->num_conf_req++;
 		break;
 
@@ -4080,7 +4086,7 @@ static inline int l2cap_config_req(struc
 	}
 
 	/* Complete config. */
-	len = l2cap_parse_conf_req(chan, rsp);
+	len = l2cap_parse_conf_req(chan, rsp, sizeof(rsp));
 	if (len < 0) {
 		l2cap_send_disconn_req(chan, ECONNRESET);
 		goto unlock;
@@ -4114,7 +4120,7 @@ static inline int l2cap_config_req(struc
 	if (!test_and_set_bit(CONF_REQ_SENT, &chan->conf_state)) {
 		u8 buf[64];
 		l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_CONF_REQ,
-			       l2cap_build_conf_req(chan, buf), buf);
+			       l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
 		chan->num_conf_req++;
 	}
 
@@ -4174,7 +4180,7 @@ static inline int l2cap_config_rsp(struc
 			char buf[64];
 
 			len = l2cap_parse_conf_rsp(chan, rsp->data, len,
-						   buf, &result);
+						   buf, sizeof(buf), &result);
 			if (len < 0) {
 				l2cap_send_disconn_req(chan, ECONNRESET);
 				goto done;
@@ -4204,7 +4210,7 @@ static inline int l2cap_config_rsp(struc
 			/* throw out any old stored conf requests */
 			result = L2CAP_CONF_SUCCESS;
 			len = l2cap_parse_conf_rsp(chan, rsp->data, len,
-						   req, &result);
+						   req, sizeof(req), &result);
 			if (len < 0) {
 				l2cap_send_disconn_req(chan, ECONNRESET);
 				goto done;
@@ -4781,7 +4787,7 @@ static void l2cap_do_create(struct l2cap
 			set_bit(CONF_REQ_SENT, &chan->conf_state);
 			l2cap_send_cmd(chan->conn, l2cap_get_ident(chan->conn),
 				       L2CAP_CONF_REQ,
-				       l2cap_build_conf_req(chan, buf), buf);
+				       l2cap_build_conf_req(chan, buf, sizeof(buf)), buf);
 			chan->num_conf_req++;
 		}
 	}
@@ -7457,7 +7463,7 @@ static void l2cap_security_cfm(struct hc
 				set_bit(CONF_REQ_SENT, &chan->conf_state);
 				l2cap_send_cmd(conn, l2cap_get_ident(conn),
 					       L2CAP_CONF_REQ,
-					       l2cap_build_conf_req(chan, buf),
+					       l2cap_build_conf_req(chan, buf, sizeof(buf)),
 					       buf);
 				chan->num_conf_req++;
 			}

[PATCH 4.9 11/14] ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt

[Greg Kroah-Hartman]

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

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

From: Marc Zyngier <marc.zyngier@arm.com>

commit 95696d292e204073433ed2ef3ff4d3d8f42a8248 upstream.

The GIC-500 integrated in the Armada-37xx SoCs is compliant with
the GICv3 architecture, and thus provides a maintenance interrupt
that is required for hypervisors to function correctly.

With the interrupt provided in the DT, KVM now works as it should.
Tested on an Espressobin system.

Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi |    1 +
 1 file changed, 1 insertion(+)

--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -170,6 +170,7 @@
 				interrupt-controller;
 				reg = <0x1d00000 0x10000>, /* GICD */
 				      <0x1d40000 0x40000>; /* GICR */
+				interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 			};
 		};
 

[PATCH 4.9 12/14] ARM: 8692/1: mm: abort uaccess retries upon fatal signal

[Greg Kroah-Hartman]

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

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

From: Mark Rutland <mark.rutland@arm.com>

commit 746a272e44141af24a02f6c9b0f65f4c4598ed42 upstream.

When there's a fatal signal pending, arm's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.

However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.

To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Steve Capper <steve.capper@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/mm/fault.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -314,8 +314,11 @@ retry:
 	 * signal first. We do not need to release the mmap_sem because
 	 * it would already be released in __lock_page_or_retry in
 	 * mm/filemap.c. */
-	if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current))
+	if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
+		if (!user_mode(regs))
+			goto no_context;
 		return 0;
+	}
 
 	/*
 	 * Major/minor page fault accounting is only done on the

[PATCH 4.9 13/14] NFS: Fix 2 use after free issues in the I/O code

[Greg Kroah-Hartman]

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

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

From: Trond Myklebust <trond.myklebust@primarydata.com>

commit 196639ebbe63a037fe9a80669140bd292d8bcd80 upstream.

The writeback code wants to send a commit after processing the pages,
which is why we want to delay releasing the struct path until after
that's done.

Also, the layout code expects that we do not free the inode before
we've put the layout segments in pnfs_writehdr_free() and
pnfs_readhdr_free()

Fixes: 919e3bd9a875 ("NFS: Ensure we commit after writeback is complete")
Fixes: 4714fb51fd03 ("nfs: remove pgio_header refcount, related cleanup")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/internal.h |    1 -
 fs/nfs/pagelist.c |   26 ++++++++++++--------------
 fs/nfs/pnfs.c     |    2 --
 3 files changed, 12 insertions(+), 17 deletions(-)

--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -248,7 +248,6 @@ int nfs_iocounter_wait(struct nfs_lock_c
 extern const struct nfs_pageio_ops nfs_pgio_rw_ops;
 struct nfs_pgio_header *nfs_pgio_header_alloc(const struct nfs_rw_ops *);
 void nfs_pgio_header_free(struct nfs_pgio_header *);
-void nfs_pgio_data_destroy(struct nfs_pgio_header *);
 int nfs_generic_pgio(struct nfs_pageio_descriptor *, struct nfs_pgio_header *);
 int nfs_initiate_pgio(struct rpc_clnt *clnt, struct nfs_pgio_header *hdr,
 		      struct rpc_cred *cred, const struct nfs_rpc_ops *rpc_ops,
--- a/fs/nfs/pagelist.c
+++ b/fs/nfs/pagelist.c
@@ -497,16 +497,6 @@ struct nfs_pgio_header *nfs_pgio_header_
 }
 EXPORT_SYMBOL_GPL(nfs_pgio_header_alloc);
 
-/*
- * nfs_pgio_header_free - Free a read or write header
- * @hdr: The header to free
- */
-void nfs_pgio_header_free(struct nfs_pgio_header *hdr)
-{
-	hdr->rw_ops->rw_free_header(hdr);
-}
-EXPORT_SYMBOL_GPL(nfs_pgio_header_free);
-
 /**
  * nfs_pgio_data_destroy - make @hdr suitable for reuse
  *
@@ -515,14 +505,24 @@ EXPORT_SYMBOL_GPL(nfs_pgio_header_free);
  *
  * @hdr: A header that has had nfs_generic_pgio called
  */
-void nfs_pgio_data_destroy(struct nfs_pgio_header *hdr)
+static void nfs_pgio_data_destroy(struct nfs_pgio_header *hdr)
 {
 	if (hdr->args.context)
 		put_nfs_open_context(hdr->args.context);
 	if (hdr->page_array.pagevec != hdr->page_array.page_array)
 		kfree(hdr->page_array.pagevec);
 }
-EXPORT_SYMBOL_GPL(nfs_pgio_data_destroy);
+
+/*
+ * nfs_pgio_header_free - Free a read or write header
+ * @hdr: The header to free
+ */
+void nfs_pgio_header_free(struct nfs_pgio_header *hdr)
+{
+	nfs_pgio_data_destroy(hdr);
+	hdr->rw_ops->rw_free_header(hdr);
+}
+EXPORT_SYMBOL_GPL(nfs_pgio_header_free);
 
 /**
  * nfs_pgio_rpcsetup - Set up arguments for a pageio call
@@ -636,7 +636,6 @@ EXPORT_SYMBOL_GPL(nfs_initiate_pgio);
 static void nfs_pgio_error(struct nfs_pgio_header *hdr)
 {
 	set_bit(NFS_IOHDR_REDO, &hdr->flags);
-	nfs_pgio_data_destroy(hdr);
 	hdr->completion_ops->completion(hdr);
 }
 
@@ -647,7 +646,6 @@ static void nfs_pgio_error(struct nfs_pg
 static void nfs_pgio_release(void *calldata)
 {
 	struct nfs_pgio_header *hdr = calldata;
-	nfs_pgio_data_destroy(hdr);
 	hdr->completion_ops->completion(hdr);
 }
 
--- a/fs/nfs/pnfs.c
+++ b/fs/nfs/pnfs.c
@@ -2145,7 +2145,6 @@ pnfs_write_through_mds(struct nfs_pageio
 		nfs_pageio_reset_write_mds(desc);
 		mirror->pg_recoalesce = 1;
 	}
-	nfs_pgio_data_destroy(hdr);
 	hdr->release(hdr);
 }
 
@@ -2257,7 +2256,6 @@ pnfs_read_through_mds(struct nfs_pageio_
 		nfs_pageio_reset_read_mds(desc);
 		mirror->pg_recoalesce = 1;
 	}
-	nfs_pgio_data_destroy(hdr);
 	hdr->release(hdr);
 }
 

[PATCH 4.9 14/14] NFS: Sync the correct byte range during synchronous writes

[Greg Kroah-Hartman]

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

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

From: tarangg@amazon.com <tarangg@amazon.com>

commit e973b1a5999e57da677ab50da5f5479fdc0f0c31 upstream.

Since commit 18290650b1c8 ("NFS: Move buffered I/O locking into
nfs_file_write()") nfs_file_write() has not flushed the correct byte
range during synchronous writes.  generic_write_sync() expects that
iocb->ki_pos points to the right edge of the range rather than the
left edge.

To replicate the problem, open a file with O_DSYNC, have the client
write at increasing offsets, and then print the successful offsets.
Block port 2049 partway through that sequence, and observe that the
client application indicates successful writes in advance of what the
server received.

Fixes: 18290650b1c8 ("NFS: Move buffered I/O locking into nfs_file_write()")
Signed-off-by: Jacob Strauss <jsstraus@amazon.com>
Signed-off-by: Tarang Gupta <tarangg@amazon.com>
Tested-by: Tarang Gupta <tarangg@amazon.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/nfs/file.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/fs/nfs/file.c
+++ b/fs/nfs/file.c
@@ -636,11 +636,11 @@ ssize_t nfs_file_write(struct kiocb *ioc
 	if (result <= 0)
 		goto out;
 
-	result = generic_write_sync(iocb, result);
-	if (result < 0)
-		goto out;
 	written = result;
 	iocb->ki_pos += written;
+	result = generic_write_sync(iocb, written);
+	if (result < 0)
+		goto out;
 
 	/* Return error values */
 	if (nfs_need_check_write(file, inode)) {

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Shuah Khan]

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

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

thanks,
-- Shuah

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Tom Gall]

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

Results from testing on Linaro’s small but growing test farm. 

------------------------------------------------------------------------
Summary
------------------------------------------------------------------------

kernel: 4.9.50-rc1
kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
kernel-branch: linux-4.9.y
kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
kernel-describe: v4.9.49-15-gedfaa5f69b96
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.49-15-gedfaa5f69b96


No regressions (compared to build v4.9.49)

Boards, architectures and test suites:
-------------------------------------------------

hi6220-hikey - arm64
* libhugetlbfs
* kselftest
* boot
* ltp-syscalls-tests

dell-poweredge-r200 - x86_64
* kselftest
* libhugetlbfs
* boot
* ltp-syscalls-tests

Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Greg Kroah-Hartman]

On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote:
> 
> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > 
> > This is the start of the stable review cycle for the 4.9.50 release.
> > There are 14 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Thu Sep 14 16:52:45 UTC 2017.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 	kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.50-rc1.gz
> > or in the git tree and branch at:
> >  git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Results from testing on Linaro’s small but growing test farm. 
> 
> ------------------------------------------------------------------------
> Summary
> ------------------------------------------------------------------------
> 
> kernel: 4.9.50-rc1
> kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> kernel-branch: linux-4.9.y
> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
> kernel-describe: v4.9.49-15-gedfaa5f69b96

Howcome 'git describe' does not show 4.9.50-rc1?

> Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.49-15-gedfaa5f69b96
> 
> 
> No regressions (compared to build v4.9.49)
> 
> Boards, architectures and test suites:
> -------------------------------------------------
> 
> hi6220-hikey - arm64
> * libhugetlbfs
> * kselftest
> * boot
> * ltp-syscalls-tests
> 
> dell-poweredge-r200 - x86_64
> * kselftest
> * libhugetlbfs
> * boot
> * ltp-syscalls-tests
> 
> Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports

Thanks for testing this tree and letting me know.

greg k-h

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Tom Gall]

On Tue, Sep 12, 2017 at 10:49 PM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
> On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote:
>>
>> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
<snip>
>>
>> Results from testing on Linaro’s small but growing test farm.
>>
>> ------------------------------------------------------------------------
>> Summary
>> ------------------------------------------------------------------------
>>
>> kernel: 4.9.50-rc1
>> kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> kernel-branch: linux-4.9.y
>> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
>> kernel-describe: v4.9.49-15-gedfaa5f69b96
>
> Howcome 'git describe' does not show 4.9.50-rc1?

git describe looks for the most recent tag.

Since there isn't a 4.9.50-rc1 tag, we get 4.9.49 + 15 patches etc.

Does it make sense to create tags for the RC(s) so git describe gets
it right? Given the right version is in the Makefile kinda feels like
that'd be a belt and suspenders approach.

<snip>




-- 
Regards,
Tom

Director, Linaro Mobile Group
Linaro.org │ Open source software for ARM SoCs
irc: tgall_foo | skype : tom_gall

"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> On Tue, Sep 12, 2017 at 10:49 PM, Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> > On Tue, Sep 12, 2017 at 09:27:45PM -0500, Tom Gall wrote:
> >>
> >> > On Sep 12, 2017, at 11:58 AM, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> <snip>
> >>
> >> Results from testing on Linaro’s small but growing test farm.
> >>
> >> ------------------------------------------------------------------------
> >> Summary
> >> ------------------------------------------------------------------------
> >>
> >> kernel: 4.9.50-rc1
> >> kernel-repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> kernel-branch: linux-4.9.y
> >> kernel-commit: edfaa5f69b96ae777b0acd2bfe1da26e21592001
> >> kernel-describe: v4.9.49-15-gedfaa5f69b96
> >
> > Howcome 'git describe' does not show 4.9.50-rc1?
> 
> git describe looks for the most recent tag.
> 
> Since there isn't a 4.9.50-rc1 tag, we get 4.9.49 + 15 patches etc.
> 
> Does it make sense to create tags for the RC(s) so git describe gets
> it right? Given the right version is in the Makefile kinda feels like
> that'd be a belt and suspenders approach.
> 
Depends. A tag only makes sense if the branch isn't rebased, otherwise
(if the tag can change) it would be misleading (as would be to report
the version number from Makefile).

I usually don't report the SHA, mostly for historic reasons
from times when I had to create the git branch myself. I sometimes
report it if/when I notice that the branch changed after the review
request e-mail.

Given that, I think reporting the SHA is better, since it reports clearly
which version was tested.

Guenter

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 848 bytes --]

On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
> On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:

> > Does it make sense to create tags for the RC(s) so git describe gets
> > it right? Given the right version is in the Makefile kinda feels like
> > that'd be a belt and suspenders approach.

> Depends. A tag only makes sense if the branch isn't rebased, otherwise
> (if the tag can change) it would be misleading (as would be to report
> the version number from Makefile).

Rebasing shouldn't be an issue for tags (they're not branches), and
changes would a disaster no matter what.

> Given that, I think reporting the SHA is better, since it reports clearly
> which version was tested.

This definitely makes sense though (especially in a generalized tool),
defensively if nothing else.  I think you ideally want both.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
> On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
> > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> 
> > > Does it make sense to create tags for the RC(s) so git describe gets
> > > it right? Given the right version is in the Makefile kinda feels like
> > > that'd be a belt and suspenders approach.
> 
> > Depends. A tag only makes sense if the branch isn't rebased, otherwise
> > (if the tag can change) it would be misleading (as would be to report
> > the version number from Makefile).
> 
> Rebasing shouldn't be an issue for tags (they're not branches), and
> changes would a disaster no matter what.
> 
I should have been more specific; my comment assumed that the tag
would be reapplied (using git tag -f) to the tip of the rebased branch.
There should be no problem if each branch update is accompanied by
a new tag.

Guenter

> > Given that, I think reporting the SHA is better, since it reports clearly
> > which version was tested.
> 
> This definitely makes sense though (especially in a generalized tool),
> defensively if nothing else.  I think you ideally want both.

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]

On Wed, Sep 13, 2017 at 11:38:02AM -0700, Guenter Roeck wrote:
> On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
> > On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:

> > > > Does it make sense to create tags for the RC(s) so git describe gets
> > > > it right? Given the right version is in the Makefile kinda feels like
> > > > that'd be a belt and suspenders approach.

> > > Depends. A tag only makes sense if the branch isn't rebased, otherwise
> > > (if the tag can change) it would be misleading (as would be to report
> > > the version number from Makefile).

> > Rebasing shouldn't be an issue for tags (they're not branches), and
> > changes would a disaster no matter what.

> I should have been more specific; my comment assumed that the tag
> would be reapplied (using git tag -f) to the tip of the rebased branch.
> There should be no problem if each branch update is accompanied by
> a new tag.

Right, my assumption here was that if the branch was rebased (eg, to
pull a patch) then that'd be a new -rc and hence a new tag name.  I
think anything that involves redoing tags is a terrible idea and you
just shouldn't do it.  But including the hash as well is definitely a
sensible idea since people are people.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Greg Kroah-Hartman]

On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
> On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
> > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> 
> > > Does it make sense to create tags for the RC(s) so git describe gets
> > > it right? Given the right version is in the Makefile kinda feels like
> > > that'd be a belt and suspenders approach.
> 
> > Depends. A tag only makes sense if the branch isn't rebased, otherwise
> > (if the tag can change) it would be misleading (as would be to report
> > the version number from Makefile).
> 
> Rebasing shouldn't be an issue for tags (they're not branches), and
> changes would a disaster no matter what.

Can you push --force a tag?  I've never tried that, don't want to mess
up a kernel.org tree by trying it out :)

Because of that, I haven't been tagging the -rc trees, as I didn't think
it was really needed.  The linux-stable-rc tree is just a "convenience"
for people to use for testing, it's not really a "cannonical" tree at
the moment because of that.

> > Given that, I think reporting the SHA is better, since it reports clearly
> > which version was tested.
> 
> This definitely makes sense though (especially in a generalized tool),
> defensively if nothing else.  I think you ideally want both.

Yes, use 'make kernelversion' to get the kernel's view of the release
number, don't use 'git describe' please, as it does not know about
changes to the Makefile (nor should it...)

thanks,

greg k-h

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

On Wed, Sep 13, 2017 at 11:55:38AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:

> > Rebasing shouldn't be an issue for tags (they're not branches), and
> > changes would a disaster no matter what.

> Can you push --force a tag?  I've never tried that, don't want to mess
> up a kernel.org tree by trying it out :)

Yes, it does work (and you can delete a tag so remove/replace would
work).  git does not make value judgements on your life choices :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Wed, Sep 13, 2017 at 11:55:38AM -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
> > On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
> > > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> > 
> > > > Does it make sense to create tags for the RC(s) so git describe gets
> > > > it right? Given the right version is in the Makefile kinda feels like
> > > > that'd be a belt and suspenders approach.
> > 
> > > Depends. A tag only makes sense if the branch isn't rebased, otherwise
> > > (if the tag can change) it would be misleading (as would be to report
> > > the version number from Makefile).
> > 
> > Rebasing shouldn't be an issue for tags (they're not branches), and
> > changes would a disaster no matter what.
> 
> Can you push --force a tag?  I've never tried that, don't want to mess
> up a kernel.org tree by trying it out :)

Yes. I don't recall if it is a direct --force or if you would have to
remove the original tag first (with git push <repo> :refs/tags/<tag>).

Guenter

> 
> Because of that, I haven't been tagging the -rc trees, as I didn't think
> it was really needed.  The linux-stable-rc tree is just a "convenience"
> for people to use for testing, it's not really a "cannonical" tree at
> the moment because of that.
> 
> > > Given that, I think reporting the SHA is better, since it reports clearly
> > > which version was tested.
> > 
> > This definitely makes sense though (especially in a generalized tool),
> > defensively if nothing else.  I think you ideally want both.
> 
> Yes, use 'make kernelversion' to get the kernel's view of the release
> number, don't use 'git describe' please, as it does not know about
> changes to the Makefile (nor should it...)
> 
> thanks,
> 
> greg k-h

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Greg Kroah-Hartman]

On Wed, Sep 13, 2017 at 12:18:12PM -0700, Guenter Roeck wrote:
> On Wed, Sep 13, 2017 at 11:55:38AM -0700, Greg Kroah-Hartman wrote:
> > On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
> > > On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
> > > > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
> > > 
> > > > > Does it make sense to create tags for the RC(s) so git describe gets
> > > > > it right? Given the right version is in the Makefile kinda feels like
> > > > > that'd be a belt and suspenders approach.
> > > 
> > > > Depends. A tag only makes sense if the branch isn't rebased, otherwise
> > > > (if the tag can change) it would be misleading (as would be to report
> > > > the version number from Makefile).
> > > 
> > > Rebasing shouldn't be an issue for tags (they're not branches), and
> > > changes would a disaster no matter what.
> > 
> > Can you push --force a tag?  I've never tried that, don't want to mess
> > up a kernel.org tree by trying it out :)
> 
> Yes. I don't recall if it is a direct --force or if you would have to
> remove the original tag first (with git push <repo> :refs/tags/<tag>).

Ah, but then if someone had pulled the old tag, they would have to
delete it locally before they can pull in the new one.  That's the main
reason I'll not do this...

Again, use the make command that we have just for this reason...

thanks,

greg k-h

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> On Wed, Sep 13, 2017 at 12:18:12PM -0700, Guenter Roeck wrote:

> > Yes. I don't recall if it is a direct --force or if you would have to
> > remove the original tag first (with git push <repo> :refs/tags/<tag>).

> Ah, but then if someone had pulled the old tag, they would have to
> delete it locally before they can pull in the new one.  That's the main
> reason I'll not do this...

If there's going to be more than one version of a given -rc isn't that
going to confuse testing reports?  I'm struggling to see the
circumstance where a tag would get replaced.

> Again, use the make command that we have just for this reason...

Not arguing with this though...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Willy Tarreau]

On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> > Yes. I don't recall if it is a direct --force or if you would have to
> > remove the original tag first (with git push <repo> :refs/tags/<tag>).
> 
> Ah, but then if someone had pulled the old tag, they would have to
> delete it locally before they can pull in the new one.  That's the main
> reason I'll not do this...

In fact not, the tags are automatically replaced upon pull. I've been
using such a crappy workflow for some time in the past, sharing human
errors with coworkers... Git is pretty tolerant to this. It's just
that it's terribly confusing because you can then have two people with
the same tag name pointing to different commit IDs, I really hate this,
it only works when all users are in the same office and you shout
"sorry I messed up, I'm pushing the tag again".

> Again, use the make command that we have just for this reason...

It also has the benefit of always reporting the same version for all
users including those only downloading the -rc patch.

Willy

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Thu, Sep 14, 2017 at 04:18:03AM +0200, Willy Tarreau wrote:
> On Wed, Sep 13, 2017 at 02:30:46PM -0700, Greg Kroah-Hartman wrote:
> > > Yes. I don't recall if it is a direct --force or if you would have to
> > > remove the original tag first (with git push <repo> :refs/tags/<tag>).
> > 
> > Ah, but then if someone had pulled the old tag, they would have to
> > delete it locally before they can pull in the new one.  That's the main
> > reason I'll not do this...
> 
> In fact not, the tags are automatically replaced upon pull. I've been
> using such a crappy workflow for some time in the past, sharing human
> errors with coworkers... Git is pretty tolerant to this. It's just
> that it's terribly confusing because you can then have two people with
> the same tag name pointing to different commit IDs, I really hate this,
> it only works when all users are in the same office and you shout
> "sorry I messed up, I'm pushing the tag again".
> 
> > Again, use the make command that we have just for this reason...
> 
> It also has the benefit of always reporting the same version for all
> users including those only downloading the -rc patch.
> 
It reports the same version, but it is not necessarily the same code.
There are cases where a rc is updated, but not the Makefile. That happens
quite a lot, actually. This is similar to mainline, which currently
claims to be v4.13.0 until -rc1, then it claims to be -rc1 until -rc2,
and so on.

Guenter

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Kevin Hilman]

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:

> On Wed, Sep 13, 2017 at 12:18:12PM -0700, Guenter Roeck wrote:
>> On Wed, Sep 13, 2017 at 11:55:38AM -0700, Greg Kroah-Hartman wrote:
>> > On Wed, Sep 13, 2017 at 09:36:55AM -0700, Mark Brown wrote:
>> > > On Wed, Sep 13, 2017 at 08:22:13AM -0700, Guenter Roeck wrote:
>> > > > On Wed, Sep 13, 2017 at 10:05:00AM -0500, Tom Gall wrote:
>> > > 
>> > > > > Does it make sense to create tags for the RC(s) so git describe gets
>> > > > > it right? Given the right version is in the Makefile kinda feels like
>> > > > > that'd be a belt and suspenders approach.
>> > > 
>> > > > Depends. A tag only makes sense if the branch isn't rebased, otherwise
>> > > > (if the tag can change) it would be misleading (as would be to report
>> > > > the version number from Makefile).
>> > > 
>> > > Rebasing shouldn't be an issue for tags (they're not branches), and
>> > > changes would a disaster no matter what.
>> > 
>> > Can you push --force a tag?  I've never tried that, don't want to mess
>> > up a kernel.org tree by trying it out :)
>> 
>> Yes. I don't recall if it is a direct --force or if you would have to
>> remove the original tag first (with git push <repo> :refs/tags/<tag>).
>
> Ah, but then if someone had pulled the old tag, they would have to
> delete it locally before they can pull in the new one.  That's the main
> reason I'll not do this...
>
> Again, use the make command that we have just for this reason...

AFAICT, the make command will not generate a unique value, so, as often
happens, a release is almost ready but one more patch is
added/removed/modified etc.  'git describe' is the only way to get a
unique value, that's also human readable.

Kevin

Re: [PATCH 4.9 00/14] 4.9.50-stable review

[Guenter Roeck]

On Tue, Sep 12, 2017 at 09:58:14AM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.50 release.
> There are 14 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Thu Sep 14 16:52:45 UTC 2017.
> Anything received after that time might be too late.
> 
Build results:
	total: 145 pass: 145 fail: 0
Qemu test results:
	total: 122 pass: 122 fail: 0

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

Guenter