Skip to contentSkip to conversation

4.9.50-stable review

PATCH In review Greg Kroah-Hartman 7 participants 31 messages Sep 12, 2017 – Sep 14, 2017 Stable branch

lore
Share & tools
lore
author maintainer
#6 lore raw

PATCH 6/14 selftests/x86/fsgsbase: Test selectors 1, 2, and 3

In reply to Greg Kroah-Hartman

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

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

From: Andy Lutomirski <[email protected]>

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

Cc Borislav Petkov <[email protected]>
Cc Borislav Petkov <[email protected]>
Cc Brian Gerst <[email protected]>
Cc Chang Seok <[email protected]>
Cc Denys Vlasenko <[email protected]>
Cc H. Peter Anvin <[email protected]>
Cc Josh Poimboeuf <[email protected]>
Cc Linus Torvalds <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc Thomas Gleixner <[email protected]>
---
 tools/testing/selftests/x86/fsgsbase.c |   41 ++++++++++++++++++++++++++++-----
 1 file changed, 35 insertions(+), 6 deletions(-)
tools/testing/selftests/x86/fsgsbase.c +35 -6
@@ -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]);
+			}
 		}
 	}
 
author maintainer
#7 lore raw

PATCH 7/14 mm/memory.c: fix mem_cgroup_oom_disable() call missing

In reply to Greg Kroah-Hartman

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

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

From: Laurent Dufour <[email protected]>

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.

---
 mm/memory.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
mm/memory.c +5 -5
@@ -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
author maintainer
#12 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Trond Myklebust <[email protected]>

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")
---
 fs/nfs/internal.h |    1 -
 fs/nfs/pagelist.c |   26 ++++++++++++--------------
 fs/nfs/pnfs.c     |    2 --
 3 files changed, 12 insertions(+), 17 deletions(-)
fs/nfs/internal.h +0 -1
@@ -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,
fs/nfs/pagelist.c +12 -14
@@ -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);
 }
 
fs/nfs/pnfs.c +0 -2
@@ -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);
 }
 

Greg Kroah-Hartman

author maintainer
#0 lore raw

cover 4.9.50-stable review

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 <[email protected]>

    Linux 4.9.50-rc1

[email protected] <[email protected]>
NFS: Sync the correct byte range during synchronous writes

Trond Myklebust <[email protected]>
NFS: Fix 2 use after free issues in the I/O code

Mark Rutland <[email protected]>
ARM: 8692/1: mm: abort uaccess retries upon fatal signal

Marc Zyngier <[email protected]>
ARM64: dts: marvell: armada-37xx: Fix GIC maintenance interrupt

Ben Seri <[email protected]>
Bluetooth: Properly check L2CAP config option output buffer length

Takashi Iwai <[email protected]>
ALSA: msnd: Optimize / harden DSP and MIDI loops

Yang Shi <[email protected]>
locktorture: Fix potential memory leak with rw lock test

Laurent Dufour <[email protected]>
mm/memory.c: fix mem_cgroup_oom_disable() call missing

Andy Lutomirski <[email protected]>
selftests/x86/fsgsbase: Test selectors 1, 2, and 3

Aleksa Sarai <[email protected]>
btrfs: resume qgroup rescan on rw remount

Daniel Verkamp <[email protected]>
nvme-fabrics: generate spec-compliant UUID NQNs

Abhishek Sahu <[email protected]>
mtd: nand: qcom: fix config error for BCH

Abhishek Sahu <[email protected]>
mtd: nand: qcom: fix read failure without complete bootchain

Boris Brezillon <[email protected]>
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(-)
author maintainer
#1 lore raw

PATCH 1/14 mtd: nand: mxc: Fix mxc_v1 ooblayout

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

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

From: Boris Brezillon <[email protected]>

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.

Fixes a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
---
 drivers/mtd/nand/mxc_nand.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/mtd/nand/mxc_nand.c +4 -3
@@ -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;
author maintainer
#9 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Ben Seri <[email protected]>

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.

---
 net/bluetooth/l2cap_core.c |   80 ++++++++++++++++++++++++---------------------
 1 file changed, 43 insertions(+), 37 deletions(-)
net/bluetooth/l2cap_core.c +43 -37
@@ -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++;
 			}
author maintainer
#10 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Marc Zyngier <[email protected]>

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")
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi |    1 +
 1 file changed, 1 insertion(+)
arch/arm64/boot/dts/marvell/armada-37xx.dtsi +1 -0
@@ -170,6 +170,7 @@
 				interrupt-controller;
 				reg = <0x1d00000 0x10000>, /* GICD */
 				      <0x1d40000 0x40000>; /* GICR */
+				interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
 			};
 		};
 
author maintainer
#11 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: Mark Rutland <[email protected]>

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.

---
 arch/arm/mm/fault.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)
arch/arm/mm/fault.c +4 -1
@@ -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
author maintainer
#13 lore raw

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

In reply to Greg Kroah-Hartman

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

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

From: [email protected] <[email protected]>

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()")
---
 fs/nfs/file.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
fs/nfs/file.c +3 -3
@@ -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)) {
author maintainer
#2 lore raw

PATCH 2/14 mtd: nand: qcom: fix read failure without complete bootchain

In reply to Greg Kroah-Hartman

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

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

From: Abhishek Sahu <[email protected]>

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")
---
 drivers/mtd/nand/qcom_nandc.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)
drivers/mtd/nand/qcom_nandc.c +12 -4
@@ -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;
 }
author maintainer
#3 lore raw

PATCH 3/14 mtd: nand: qcom: fix config error for BCH

In reply to Greg Kroah-Hartman

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

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

From: Abhishek Sahu <[email protected]>

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")
---
 drivers/mtd/nand/qcom_nandc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mtd/nand/qcom_nandc.c +1 -1
@@ -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
author maintainer
#4 lore raw

PATCH 4/14 nvme-fabrics: generate spec-compliant UUID NQNs

In reply to Greg Kroah-Hartman

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

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

From: Daniel Verkamp <[email protected]>

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.

---
 drivers/nvme/host/fabrics.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/nvme/host/fabrics.c +1 -1
@@ -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);
author maintainer
#5 lore raw

PATCH 5/14 btrfs: resume qgroup rescan on rw remount

In reply to Greg Kroah-Hartman

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

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

From: Aleksa Sarai <[email protected]>

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 <[email protected]>
Fixes b382a324b60f ("Btrfs: fix qgroup rescan resume on mount")
---
 fs/btrfs/super.c |    2 ++
 1 file changed, 2 insertions(+)
fs/btrfs/super.c +2 -0
@@ -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);
author maintainer
#8 lore raw

PATCH 9/14 ALSA: msnd: Optimize / harden DSP and MIDI loops

In reply to Greg Kroah-Hartman

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

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

From: Takashi Iwai <[email protected]>

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

---
 sound/isa/msnd/msnd_midi.c     |   28 ++++++++++++++--------------
 sound/isa/msnd/msnd_pinnacle.c |   23 ++++++++++++-----------
 2 files changed, 26 insertions(+), 25 deletions(-)
sound/isa/msnd/msnd_midi.c +14 -14
@@ -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);
sound/isa/msnd/msnd_pinnacle.c +12 -11
@@ -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;
#14 lore raw
In reply to Greg Kroah-Hartman
Quoted 9 lines · 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:

Quoted 9 lines
	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

#15 lore raw
In reply to Greg Kroah-Hartman
Quoted 12 lines · 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:

Quoted 8 lines
	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

author maintainer
#16 lore raw
Quoted 27 lines · Tom Gall
Quoted 12 lines · 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:

Quoted 8 lines
	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
------------------------------------------------------------------------

Quoted 5 lines

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?

Quoted 14 lines

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

Quoted 7 lines

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

#30 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · 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.

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

#17 lore raw
In reply to Greg Kroah-Hartman
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Tom Gall
Quoted 2 lines · Greg Kroah-Hartman

<snip>

Quoted 7 lines
Quoted 7 lines

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

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

Quoted 7 lines
Quoted 5 lines

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>

Signature · 9 lines
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
#18 lore raw
Quoted 21 lines · Tom Gall
Quoted 3 lines · Greg Kroah-Hartman
Quoted 2 lines · Tom Gall
Quoted 2 lines · Greg Kroah-Hartman

<snip>

Quoted 7 lines
Quoted 7 lines

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

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

Quoted 7 lines
Quoted 5 lines

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?

Quoted 8 lines

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

#19 lore raw
Quoted 9 lines · Guenter Roeck
Quoted 3 lines · Tom Gall

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.

Quoted 2 lines

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.

#20 lore raw
Quoted 7 lines · Mark Brown
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Tom Gall

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.

Quoted 7 lines
Quoted 3 lines

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

Quoted 5 lines
Quoted 2 lines

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.

author maintainer
#22 lore raw
In reply to Mark Brown
Quoted 7 lines · Mark Brown
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Tom Gall

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 5 lines
Quoted 2 lines

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

#21 lore raw
In reply to Guenter Roeck
Quoted 11 lines · Guenter Roeck
Quoted 9 lines · Mark Brown
Quoted 7 lines · Guenter Roeck
Quoted 3 lines

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

Quoted 7 lines
Quoted 2 lines

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.

#23 lore raw
In reply to Greg Kroah-Hartman
Quoted 7 lines · Greg Kroah-Hartman
Quoted 2 lines · Mark Brown

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

#24 lore raw
In reply to Greg Kroah-Hartman
Quoted 12 lines · Greg Kroah-Hartman
Quoted 11 lines · Mark Brown
Quoted 9 lines · Guenter Roeck
Quoted 3 lines · Tom Gall

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

Quoted 5 lines
Quoted 2 lines

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

Quoted 19 lines

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.

Quoted 5 lines
Quoted 2 lines

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

author maintainer
#25 lore raw
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Greg Kroah-Hartman
Quoted 11 lines · Mark Brown
Quoted 9 lines · Guenter Roeck
Quoted 3 lines · Tom Gall

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

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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

#26 lore raw
Quoted 8 lines · Greg Kroah-Hartman
Quoted 2 lines · Guenter Roeck

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.

Quoted 1 line

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

Not arguing with this though...

#27 lore raw
In reply to Greg Kroah-Hartman
Quoted 6 lines · Greg Kroah-Hartman
Quoted 2 lines

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

Quoted 1 line

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

#28 lore raw
Quoted 16 lines · Willy Tarreau
Quoted 6 lines · Greg Kroah-Hartman
Quoted 2 lines

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

Quoted 5 lines
Quoted 1 line

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

#29 lore raw
In reply to Greg Kroah-Hartman
Quoted 20 lines · Greg Kroah-Hartman
Quoted 19 lines · Guenter Roeck
Quoted 17 lines · Greg Kroah-Hartman
Quoted 7 lines · Mark Brown
Quoted 5 lines · Guenter Roeck
Quoted 3 lines · Tom Gall

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.

Quoted 6 lines
Quoted 3 lines

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

Quoted 8 lines
Quoted 2 lines

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