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

Groups > linux.kernel > #1731084 > unrolled thread

[PATCH 4.9 00/14] 4.9.50-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.9 00/14] 4.9.50-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-12 19:20 +0200
    [PATCH 4.9 10/14] Bluetooth: Properly check L2CAP config option output buffer length Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-12 19:20 +0200
    [PATCH 4.9 02/14] mtd: nand: qcom: fix read failure without complete bootchain Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-12 19:20 +0200
    [PATCH 4.9 14/14] NFS: Sync the correct byte range during synchronous writes Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-12 19:20 +0200
    Re: [PATCH 4.9 00/14] 4.9.50-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-09-13 02:20 +0200
    Re: [PATCH 4.9 00/14] 4.9.50-stable review Tom Gall <tom.gall@linaro.org> - 2017-09-13 04:30 +0200
      Re: [PATCH 4.9 00/14] 4.9.50-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-13 05:50 +0200
        Re: [PATCH 4.9 00/14] 4.9.50-stable review Tom Gall <tom.gall@linaro.org> - 2017-09-13 17:10 +0200
          Re: [PATCH 4.9 00/14] 4.9.50-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-13 17:30 +0200
            Re: [PATCH 4.9 00/14] 4.9.50-stable review Mark Brown <broonie@kernel.org> - 2017-09-13 19:10 +0200
              Re: [PATCH 4.9 00/14] 4.9.50-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-13 20:40 +0200
                Re: [PATCH 4.9 00/14] 4.9.50-stable review Mark Brown <broonie@kernel.org> - 2017-09-13 21:00 +0200
              Re: [PATCH 4.9 00/14] 4.9.50-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-13 21:00 +0200
                Re: [PATCH 4.9 00/14] 4.9.50-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-13 21:20 +0200
                  Re: [PATCH 4.9 00/14] 4.9.50-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-09-13 23:40 +0200
                    Re: [PATCH 4.9 00/14] 4.9.50-stable review Mark Brown <broonie@kernel.org> - 2017-09-14 00:10 +0200
                    Re: [PATCH 4.9 00/14] 4.9.50-stable review Willy Tarreau <w@1wt.eu> - 2017-09-14 04:20 +0200
                      Re: [PATCH 4.9 00/14] 4.9.50-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-14 07:40 +0200
                    Re: [PATCH 4.9 00/14] 4.9.50-stable review Kevin Hilman <khilman@baylibre.com> - 2017-09-15 01:00 +0200
                Re: [PATCH 4.9 00/14] 4.9.50-stable review Mark Brown <broonie@kernel.org> - 2017-09-13 21:20 +0200
    Re: [PATCH 4.9 00/14] 4.9.50-stable review Guenter Roeck <linux@roeck-us.net> - 2017-09-13 16:40 +0200

Page 1 of 2  [1] 2  Next page →

#1731084 — [PATCH 4.9 00/14] 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 <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(-)

[toc] | [next] | [standalone]

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

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++;
 			}

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

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

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;
 }

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

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

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

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

#1731303

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

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

#1731337

> 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

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

#1731355

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

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

#1731659

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

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

#1731682

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

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

#1731728

[Multipart message — attachments visible in raw view] — view raw

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.

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

#1731771

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.

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

#1731785

[Multipart message — attachments visible in raw view] — view raw

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.

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

#1731783

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

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

#1731798

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

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

#1731911

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

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

#1731959

[Multipart message — attachments visible in raw view] — view raw

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

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

#1732019

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

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

#1732050

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

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

#1732631

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

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

#1731800

[Multipart message — attachments visible in raw view] — view raw

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

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web