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

Groups > linux.kernel > #1401846 > unrolled thread

[PATCH 3.14 00/17] 3.14.70-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 3.14 00/17] 3.14.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 03:20 +0200
    [PATCH 3.14 05/17] drm/radeon: fix PLL sharing on DCE6.1 (v2) Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 03:20 +0200
    [PATCH 3.14 08/17] decnet: Do not build routes to devices without decnet private data. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 03:20 +0200
    [PATCH 3.14 14/17] VSOCK: do not disconnect socket when peer has shutdown SEND only Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 03:20 +0200
    [PATCH 3.14 16/17] net: fix a kernel infoleak in x25 module Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 03/17] Input: max8997-haptic - fix NULL pointer dereference Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 09/17] route: do not cache fib route info on local routes with oif Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 01/17] crypto: hash - Fix page length clamping in hash walk Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 04/17] asmlinkage, pnp: Make variables used from assembler code visible Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 15/17] net: bridge: fix old ioctl unlocked net device walk Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
      Re: [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack  area "Jon Medhurst (Tixy)" <tixy@linaro.org> - 2016-05-17 12:00 +0200
        Re: [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack  area Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 22:40 +0200
    [PATCH 3.14 02/17] get_rock_ridge_filename(): handle malformed NM entries Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    [PATCH 3.14 11/17] atl2: Disable unimplemented scatter/gather feature Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 04:10 +0200
    Re: [PATCH 3.14 00/17] 3.14.70-stable review Guenter Roeck <linux@roeck-us.net> - 2016-05-17 06:10 +0200
      Re: [PATCH 3.14 00/17] 3.14.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 22:40 +0200
    Re: [PATCH 3.14 00/17] 3.14.70-stable review Guenter Roeck <linux@roeck-us.net> - 2016-05-17 19:30 +0200
      Re: [PATCH 3.14 00/17] 3.14.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 22:40 +0200
    Re: [PATCH 3.14 00/17] 3.14.70-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2016-05-17 19:30 +0200
      Re: [PATCH 3.14 00/17] 3.14.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-17 22:40 +0200
    Re: [PATCH 3.14 00/17] 3.14.70-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2016-05-19 06:00 +0200

Page 1 of 2  [1] 2  Next page →

#1401846 — [PATCH 3.14 00/17] 3.14.70-stable review

This is the start of the stable review cycle for the 3.14.70 release.
There are 17 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 May 19 01:13:32 UTC 2016.
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/v3.x/stable-review/patch-3.14.70-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

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

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

Jon Medhurst <tixy@linaro.org>
    arm64: Make arch_randomize_brk avoid stack area

Kangjie Lu <kangjielu@gmail.com>
    net: fix a kernel infoleak in x25 module

Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
    net: bridge: fix old ioctl unlocked net device walk

Ian Campbell <ian.campbell@docker.com>
    VSOCK: do not disconnect socket when peer has shutdown SEND only

Kangjie Lu <kangjielu@gmail.com>
    net: fix infoleak in rtnetlink

Kangjie Lu <kangjielu@gmail.com>
    net: fix infoleak in llc

Ben Hutchings <ben@decadent.org.uk>
    atl2: Disable unimplemented scatter/gather feature

Mathias Krause <minipli@googlemail.com>
    packet: fix heap info leak in PACKET_DIAG_MCLIST sock_diag interface

Chris Friesen <chris.friesen@windriver.com>
    route: do not cache fib route info on local routes with oif

David S. Miller <davem@davemloft.net>
    decnet: Do not build routes to devices without decnet private data.

Tony Lindgren <tony@atomide.com>
    ARM: OMAP3: Fix booting with thumb2 kernel

Daniel Vetter <daniel.vetter@ffwll.ch>
    drm/i915: Bail out of pipe config compute loop on LPT

Lucas Stach <dev@lynxeye.de>
    drm/radeon: fix PLL sharing on DCE6.1 (v2)

Andi Kleen <ak@linux.intel.com>
    asmlinkage, pnp: Make variables used from assembler code visible

Marek Szyprowski <m.szyprowski@samsung.com>
    Input: max8997-haptic - fix NULL pointer dereference

Al Viro <viro@zeniv.linux.org.uk>
    get_rock_ridge_filename(): handle malformed NM entries

Herbert Xu <herbert@gondor.apana.org.au>
    crypto: hash - Fix page length clamping in hash walk


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

Diffstat:

 Makefile                                 |  4 ++--
 arch/arm/mach-omap2/sleep34xx.S          | 22 ++--------------------
 arch/arm64/kernel/process.c              | 24 ++++++++++++++++++------
 crypto/ahash.c                           |  3 ++-
 drivers/gpu/drm/i915/intel_crt.c         |  8 +++++++-
 drivers/gpu/drm/radeon/atombios_crtc.c   | 10 ++++++++++
 drivers/input/misc/max8997_haptic.c      |  6 ++++--
 drivers/net/ethernet/atheros/atlx/atl2.c |  2 +-
 drivers/pnp/pnpbios/bioscalls.c          |  9 +++++----
 fs/isofs/rock.c                          | 13 ++++++++++---
 net/bridge/br_ioctl.c                    |  5 +++--
 net/core/rtnetlink.c                     | 18 ++++++++++--------
 net/decnet/dn_route.c                    |  9 ++++++++-
 net/ipv4/route.c                         | 12 ++++++++++++
 net/llc/af_llc.c                         |  1 +
 net/packet/af_packet.c                   |  1 +
 net/vmw_vsock/af_vsock.c                 | 21 +--------------------
 net/x25/x25_facilities.c                 |  1 +
 18 files changed, 98 insertions(+), 71 deletions(-)

[toc] | [next] | [standalone]

#1401850 — [PATCH 3.14 05/17] drm/radeon: fix PLL sharing on DCE6.1 (v2)

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

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

From: Lucas Stach <dev@lynxeye.de>

commit e3c00d87845ab375f90fa6e10a5e72a3a5778cd3 upstream.

On DCE6.1 PPLL2 is exclusively available to UNIPHYA, so it should not
be taken into consideration when looking for an already enabled PLL
to be shared with other outputs.

This fixes the broken VGA port (TRAVIS DP->VGA bridge) on my Richland
based laptop, where the internal display is connected to UNIPHYA through
a TRAVIS DP->LVDS bridge.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=78987

v2: agd: add check in radeon_get_shared_nondp_ppll as well, drop
    extra parameter.

Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/gpu/drm/radeon/atombios_crtc.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1600,6 +1600,7 @@ static u32 radeon_get_pll_use_mask(struc
 static int radeon_get_shared_dp_ppll(struct drm_crtc *crtc)
 {
 	struct drm_device *dev = crtc->dev;
+	struct radeon_device *rdev = dev->dev_private;
 	struct drm_crtc *test_crtc;
 	struct radeon_crtc *test_radeon_crtc;
 
@@ -1609,6 +1610,10 @@ static int radeon_get_shared_dp_ppll(str
 		test_radeon_crtc = to_radeon_crtc(test_crtc);
 		if (test_radeon_crtc->encoder &&
 		    ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
+			/* PPLL2 is exclusive to UNIPHYA on DCE61 */
+			if (ASIC_IS_DCE61(rdev) && !ASIC_IS_DCE8(rdev) &&
+			    test_radeon_crtc->pll_id == ATOM_PPLL2)
+				continue;
 			/* for DP use the same PLL for all */
 			if (test_radeon_crtc->pll_id != ATOM_PPLL_INVALID)
 				return test_radeon_crtc->pll_id;
@@ -1630,6 +1635,7 @@ static int radeon_get_shared_nondp_ppll(
 {
 	struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
 	struct drm_device *dev = crtc->dev;
+	struct radeon_device *rdev = dev->dev_private;
 	struct drm_crtc *test_crtc;
 	struct radeon_crtc *test_radeon_crtc;
 	u32 adjusted_clock, test_adjusted_clock;
@@ -1645,6 +1651,10 @@ static int radeon_get_shared_nondp_ppll(
 		test_radeon_crtc = to_radeon_crtc(test_crtc);
 		if (test_radeon_crtc->encoder &&
 		    !ENCODER_MODE_IS_DP(atombios_get_encoder_mode(test_radeon_crtc->encoder))) {
+			/* PPLL2 is exclusive to UNIPHYA on DCE61 */
+			if (ASIC_IS_DCE61(rdev) && !ASIC_IS_DCE8(rdev) &&
+			    test_radeon_crtc->pll_id == ATOM_PPLL2)
+				continue;
 			/* check if we are already driving this connector with another crtc */
 			if (test_radeon_crtc->connector == radeon_crtc->connector) {
 				/* if we are, return that pll */

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

#1401859 — [PATCH 3.14 08/17] decnet: Do not build routes to devices without decnet private data.

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

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

From: "David S. Miller" <davem@davemloft.net>

[ Upstream commit a36a0d4008488fa545c74445d69eaf56377d5d4e ]

In particular, make sure we check for decnet private presence
for loopback devices.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/decnet/dn_route.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -1030,10 +1030,13 @@ source_ok:
 	if (!fld.daddr) {
 		fld.daddr = fld.saddr;
 
-		err = -EADDRNOTAVAIL;
 		if (dev_out)
 			dev_put(dev_out);
+		err = -EINVAL;
 		dev_out = init_net.loopback_dev;
+		if (!dev_out->dn_ptr)
+			goto out;
+		err = -EADDRNOTAVAIL;
 		dev_hold(dev_out);
 		if (!fld.daddr) {
 			fld.daddr =
@@ -1106,6 +1109,8 @@ source_ok:
 		if (dev_out == NULL)
 			goto out;
 		dn_db = rcu_dereference_raw(dev_out->dn_ptr);
+		if (!dn_db)
+			goto e_inval;
 		/* Possible improvement - check all devices for local addr */
 		if (dn_dev_islocal(dev_out, fld.daddr)) {
 			dev_put(dev_out);
@@ -1147,6 +1152,8 @@ select_source:
 			dev_put(dev_out);
 		dev_out = init_net.loopback_dev;
 		dev_hold(dev_out);
+		if (!dev_out->dn_ptr)
+			goto e_inval;
 		fld.flowidn_oif = dev_out->ifindex;
 		if (res.fi)
 			dn_fib_info_put(res.fi);

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

#1401864 — [PATCH 3.14 14/17] VSOCK: do not disconnect socket when peer has shutdown SEND only

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

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

From: Ian Campbell <ian.campbell@docker.com>

[ Upstream commit dedc58e067d8c379a15a8a183c5db318201295bb ]

The peer may be expecting a reply having sent a request and then done a
shutdown(SHUT_WR), so tearing down the whole socket at this point seems
wrong and breaks for me with a client which does a SHUT_WR.

Looking at other socket family's stream_recvmsg callbacks doing a shutdown
here does not seem to be the norm and removing it does not seem to have
had any adverse effects that I can see.

I'm using Stefan's RFC virtio transport patches, I'm unsure of the impact
on the vmci transport.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
Cc: Andy King <acking@vmware.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Cc: Jorgen Hansen <jhansen@vmware.com>
Cc: Adit Ranadive <aditr@vmware.com>
Cc: netdev@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/vmw_vsock/af_vsock.c |   21 +--------------------
 1 file changed, 1 insertion(+), 20 deletions(-)

--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1796,27 +1796,8 @@ vsock_stream_recvmsg(struct kiocb *kiocb
 	else if (sk->sk_shutdown & RCV_SHUTDOWN)
 		err = 0;
 
-	if (copied > 0) {
-		/* We only do these additional bookkeeping/notification steps
-		 * if we actually copied something out of the queue pair
-		 * instead of just peeking ahead.
-		 */
-
-		if (!(flags & MSG_PEEK)) {
-			/* If the other side has shutdown for sending and there
-			 * is nothing more to read, then modify the socket
-			 * state.
-			 */
-			if (vsk->peer_shutdown & SEND_SHUTDOWN) {
-				if (vsock_stream_has_data(vsk) <= 0) {
-					sk->sk_state = SS_UNCONNECTED;
-					sock_set_flag(sk, SOCK_DONE);
-					sk->sk_state_change(sk);
-				}
-			}
-		}
+	if (copied > 0)
 		err = copied;
-	}
 
 out_wait:
 	finish_wait(sk_sleep(sk), &wait);

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

#1402018 — [PATCH 3.14 16/17] net: fix a kernel infoleak in x25 module

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

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

From: Kangjie Lu <kangjielu@gmail.com>

[ Upstream commit 79e48650320e6fba48369fccf13fd045315b19b8 ]

Stack object "dte_facilities" is allocated in x25_rx_call_request(),
which is supposed to be initialized in x25_negotiate_facilities.
However, 5 fields (8 bytes in total) are not initialized. This
object is then copied to userland via copy_to_user, thus infoleak
occurs.

Signed-off-by: Kangjie Lu <kjlu@gatech.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/x25/x25_facilities.c |    1 +
 1 file changed, 1 insertion(+)

--- a/net/x25/x25_facilities.c
+++ b/net/x25/x25_facilities.c
@@ -277,6 +277,7 @@ int x25_negotiate_facilities(struct sk_b
 
 	memset(&theirs, 0, sizeof(theirs));
 	memcpy(new, ours, sizeof(*new));
+	memset(dte, 0, sizeof(*dte));
 
 	len = x25_parse_facilities(skb, &theirs, dte, &x25->vc_facil_mask);
 	if (len < 0)

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

#1402020 — [PATCH 3.14 03/17] Input: max8997-haptic - fix NULL pointer dereference

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

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

From: Marek Szyprowski <m.szyprowski@samsung.com>

commit 6ae645d5fa385f3787bf1723639cd907fe5865e7 upstream.

NULL pointer derefence happens when booting with DTB because the
platform data for haptic device is not set in supplied data from parent
MFD device.

The MFD device creates only platform data (from Device Tree) for itself,
not for haptic child.

Unable to handle kernel NULL pointer dereference at virtual address 0000009c
pgd = c0004000
	[0000009c] *pgd=00000000
	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
	(max8997_haptic_probe) from [<c03f9cec>] (platform_drv_probe+0x4c/0xb0)
	(platform_drv_probe) from [<c03f8440>] (driver_probe_device+0x214/0x2c0)
	(driver_probe_device) from [<c03f8598>] (__driver_attach+0xac/0xb0)
	(__driver_attach) from [<c03f67ac>] (bus_for_each_dev+0x68/0x9c)
	(bus_for_each_dev) from [<c03f7a38>] (bus_add_driver+0x1a0/0x218)
	(bus_add_driver) from [<c03f8db0>] (driver_register+0x78/0xf8)
	(driver_register) from [<c0101774>] (do_one_initcall+0x90/0x1d8)
	(do_one_initcall) from [<c0a00dbc>] (kernel_init_freeable+0x15c/0x1fc)
	(kernel_init_freeable) from [<c06bb5b4>] (kernel_init+0x8/0x114)
	(kernel_init) from [<c0107938>] (ret_from_fork+0x14/0x3c)

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 104594b01ce7 ("Input: add driver support for MAX8997-haptic")
[k.kozlowski: Write commit message, add CC-stable]
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/input/misc/max8997_haptic.c |    6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/input/misc/max8997_haptic.c
+++ b/drivers/input/misc/max8997_haptic.c
@@ -245,12 +245,14 @@ static int max8997_haptic_probe(struct p
 	struct max8997_dev *iodev = dev_get_drvdata(pdev->dev.parent);
 	const struct max8997_platform_data *pdata =
 					dev_get_platdata(iodev->dev);
-	const struct max8997_haptic_platform_data *haptic_pdata =
-					pdata->haptic_pdata;
+	const struct max8997_haptic_platform_data *haptic_pdata = NULL;
 	struct max8997_haptic *chip;
 	struct input_dev *input_dev;
 	int error;
 
+	if (pdata)
+		haptic_pdata = pdata->haptic_pdata;
+
 	if (!haptic_pdata) {
 		dev_err(&pdev->dev, "no haptic platform data\n");
 		return -EINVAL;

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

#1402021 — [PATCH 3.14 09/17] route: do not cache fib route info on local routes with oif

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

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

From: Chris Friesen <chris.friesen@windriver.com>

[ Upstream commit d6d5e999e5df67f8ec20b6be45e2229455ee3699 ]

For local routes that require a particular output interface we do not want
to cache the result.  Caching the result causes incorrect behaviour when
there are multiple source addresses on the interface.  The end result
being that if the intended recipient is waiting on that interface for the
packet he won't receive it because it will be delivered on the loopback
interface and the IP_PKTINFO ipi_ifindex will be set to the loopback
interface as well.

This can be tested by running a program such as "dhcp_release" which
attempts to inject a packet on a particular interface so that it is
received by another program on the same board.  The receiving process
should see an IP_PKTINFO ipi_ifndex value of the source interface
(e.g., eth1) instead of the loopback interface (e.g., lo).  The packet
will still appear on the loopback interface in tcpdump but the important
aspect is that the CMSG info is correct.

Sample dhcp_release command line:

   dhcp_release eth1 192.168.204.222 02:11:33:22:44:66

Signed-off-by: Allain Legacy <allain.legacy@windriver.com>
Signed off-by: Chris Friesen <chris.friesen@windriver.com>
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/ipv4/route.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1926,6 +1926,18 @@ static struct rtable *__mkroute_output(c
 		 */
 		if (fi && res->prefixlen < 4)
 			fi = NULL;
+	} else if ((type == RTN_LOCAL) && (orig_oif != 0) &&
+		   (orig_oif != dev_out->ifindex)) {
+		/* For local routes that require a particular output interface
+		 * we do not want to cache the result.  Caching the result
+		 * causes incorrect behaviour when there are multiple source
+		 * addresses on the interface, the end result being that if the
+		 * intended recipient is waiting on that interface for the
+		 * packet he won't receive it because it will be delivered on
+		 * the loopback interface and the IP_PKTINFO ipi_ifindex will
+		 * be set to the loopback interface as well.
+		 */
+		fi = NULL;
 	}
 
 	fnhe = NULL;

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

#1402022 — [PATCH 3.14 01/17] crypto: hash - Fix page length clamping in hash walk

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

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

From: Herbert Xu <herbert@gondor.apana.org.au>

commit 13f4bb78cf6a312bbdec367ba3da044b09bf0e29 upstream.

The crypto hash walk code is broken when supplied with an offset
greater than or equal to PAGE_SIZE.  This patch fixes it by adjusting
walk->pg and walk->offset when this happens.

Reported-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 crypto/ahash.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/crypto/ahash.c
+++ b/crypto/ahash.c
@@ -64,8 +64,9 @@ static int hash_walk_new_entry(struct cr
 	struct scatterlist *sg;
 
 	sg = walk->sg;
-	walk->pg = sg_page(sg);
 	walk->offset = sg->offset;
+	walk->pg = sg_page(walk->sg) + (walk->offset >> PAGE_SHIFT);
+	walk->offset = offset_in_page(walk->offset);
 	walk->entrylen = sg->length;
 
 	if (walk->entrylen > walk->total)

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

#1402023 — [PATCH 3.14 04/17] asmlinkage, pnp: Make variables used from assembler code visible

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

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

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

commit a99aa42d0253f033cbb85096d3f2bd82201321e6 upstream.

Mark variables referenced from assembler files visible.

This fixes compile problems with LTO.

Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/1391845930-28580-4-git-send-email-ak@linux.intel.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/pnp/pnpbios/bioscalls.c |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

--- a/drivers/pnp/pnpbios/bioscalls.c
+++ b/drivers/pnp/pnpbios/bioscalls.c
@@ -21,7 +21,7 @@
 
 #include "pnpbios.h"
 
-static struct {
+__visible struct {
 	u16 offset;
 	u16 segment;
 } pnp_bios_callpoint;
@@ -41,6 +41,7 @@ asmlinkage void pnp_bios_callfunc(void);
 
 __asm__(".text			\n"
 	__ALIGN_STR "\n"
+	".globl pnp_bios_callfunc\n"
 	"pnp_bios_callfunc:\n"
 	"	pushl %edx	\n"
 	"	pushl %ecx	\n"
@@ -66,9 +67,9 @@ static struct desc_struct bad_bios_desc
  * after PnP BIOS oopses.
  */
 
-u32 pnp_bios_fault_esp;
-u32 pnp_bios_fault_eip;
-u32 pnp_bios_is_utter_crap = 0;
+__visible u32 pnp_bios_fault_esp;
+__visible u32 pnp_bios_fault_eip;
+__visible u32 pnp_bios_is_utter_crap = 0;
 
 static spinlock_t pnp_bios_lock;
 

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

#1402024 — [PATCH 3.14 15/17] net: bridge: fix old ioctl unlocked net device walk

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

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

From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

[ Upstream commit 31ca0458a61a502adb7ed192bf9716c6d05791a5 ]

get_bridge_ifindices() is used from the old "deviceless" bridge ioctl
calls which aren't called with rtnl held. The comment above says that it is
called with rtnl but that is not really the case.
Here's a sample output from a test ASSERT_RTNL() which I put in
get_bridge_ifindices and executed "brctl show":
[  957.422726] RTNL: assertion failed at net/bridge//br_ioctl.c (30)
[  957.422925] CPU: 0 PID: 1862 Comm: brctl Tainted: G        W  O
4.6.0-rc4+ #157
[  957.423009] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.8.1-20150318_183358- 04/01/2014
[  957.423009]  0000000000000000 ffff880058adfdf0 ffffffff8138dec5
0000000000000400
[  957.423009]  ffffffff81ce8380 ffff880058adfe58 ffffffffa05ead32
0000000000000001
[  957.423009]  00007ffec1a444b0 0000000000000400 ffff880053c19130
0000000000008940
[  957.423009] Call Trace:
[  957.423009]  [<ffffffff8138dec5>] dump_stack+0x85/0xc0
[  957.423009]  [<ffffffffa05ead32>]
br_ioctl_deviceless_stub+0x212/0x2e0 [bridge]
[  957.423009]  [<ffffffff81515beb>] sock_ioctl+0x22b/0x290
[  957.423009]  [<ffffffff8126ba75>] do_vfs_ioctl+0x95/0x700
[  957.423009]  [<ffffffff8126c159>] SyS_ioctl+0x79/0x90
[  957.423009]  [<ffffffff8163a4c0>] entry_SYSCALL_64_fastpath+0x23/0xc1

Since it only reads bridge ifindices, we can use rcu to safely walk the net
device list. Also remove the wrong rtnl comment above.

Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/bridge/br_ioctl.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

--- a/net/bridge/br_ioctl.c
+++ b/net/bridge/br_ioctl.c
@@ -21,18 +21,19 @@
 #include <asm/uaccess.h>
 #include "br_private.h"
 
-/* called with RTNL */
 static int get_bridge_ifindices(struct net *net, int *indices, int num)
 {
 	struct net_device *dev;
 	int i = 0;
 
-	for_each_netdev(net, dev) {
+	rcu_read_lock();
+	for_each_netdev_rcu(net, dev) {
 		if (i >= num)
 			break;
 		if (dev->priv_flags & IFF_EBRIDGE)
 			indices[i++] = dev->ifindex;
 	}
+	rcu_read_unlock();
 
 	return i;
 }

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

#1402025 — [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

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

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


From: Jon Medhurst <tixy@linaro.org>

[As mentioned in the commit message, the problem this patch fixes can't
occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later.,
but earlier kernel versions need this fix.]

When a process is created, various address randomisations could end up
colluding to place the address of brk in the stack memory. This would
mean processes making small heap based memory allocations are in danger
of having them overwriting, or overwritten by, the stack.

Another consequence, is that even for processes that make no use of
brk, the output of /proc/*/maps may show the stack area listed as
'[heap]' rather than '[stack]'. Apart from being misleading this causes
fatal errors with the Android run-time like:
"No [stack] line found in /proc/self/task/*/maps"

To prevent this problem pick a limit for brk that allows for the stack's
memory. At the same time we remove randomize_base() as that was only
used by arch_randomize_brk().

Note, in practice, since commit d1fd836dcf00 ("mm: split ET_DYN ASLR
from mmap ASLR") this problem shouldn't occur because the address chosen
for loading binaries is well clear of the stack, however, prior to that
the problem does occur because of the following...

The memory layout of a task is determined by arch_pick_mmap_layout. If
address randomisation is enabled (task has flag PF_RANDOMIZE) this sets
mmap_base to a random address at the top of task memory just below a
region calculated to allow for a stack which itself may have a random
base address. Any mmap operations that then happen which require an
address allocating will use the topdown allocation method, i.e. the
first allocated memory will be at the top of memory, just below the
area set aside for the stack.

When a relocatable binary is loaded into a new process by
load_elf_binary and randomised address are enabled, it uses a
'load_bias' of zero, so that when mmap is called to create a memory
region for it, a new address is picked (address zero not being
available). As this is the first memory region in the task, it gets the
region just below the stack, as described previously.

The loader then set's brk to the end of the elf data section, which will
be near the end of the loaded binary and then it calls
arch_randomize_brk. As this currently stands, this adds a random amount
to brk, which unfortunately may take it into the address range where the
stack lies.

Testing:

These changes have been tested on Linux 3.18 (where the collision of brk
and stack can happen) using 100000 invocations of a program [1] that can
display the offset of a process's brk...

$for i in $(seq 100000); do ./aslr --report brk ; done

This shows values of brk are evenly distributed over a 1GB range before
this change is applied. After this change the distribution shows a slope
where lower values for brk are more common and upper values have about
half the frequency of those.

[1] http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/2499/scripts/kernel-security/aslr/

Signed-off-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---


I originally posted this to the ARM kernel list and arm64 maintainers,
see http://www.spinics.net/lists/arm-kernel/msg502238.html

 arch/arm64/kernel/process.c |   24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -350,15 +350,27 @@ unsigned long arch_align_stack(unsigned
 	return sp & ~0xf;
 }
 
-static unsigned long randomize_base(unsigned long base)
+unsigned long arch_randomize_brk(struct mm_struct *mm)
 {
+	unsigned long base = mm->brk;
 	unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1;
-	return randomize_range(base, range_end, 0) ? : base;
-}
+	unsigned long max_stack, range_limit;
 
-unsigned long arch_randomize_brk(struct mm_struct *mm)
-{
-	return randomize_base(mm->brk);
+	/*
+	 * Determine how much room we need to leave available for the stack.
+	 * We limit this to a reasonable value, because extremely large or
+	 * unlimited stacks are always going to bump up against brk at some
+	 * point and we don't want to fail to randomise brk in those cases.
+	 */
+	max_stack = rlimit(RLIMIT_STACK);
+	if (max_stack > SZ_128M)
+		max_stack = SZ_128M;
+
+	range_limit = mm->start_stack - max_stack - 1;
+	if (range_end > range_limit)
+		range_end = range_limit;
+
+	return randomize_range(base, range_end, 0) ? : base;
 }
 
 unsigned long randomize_et_dyn(unsigned long base)

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

#1402245 — Re: [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

On Mon, 2016-05-16 at 18:14 -0700, Greg Kroah-Hartman wrote:
> 3.14-stable review patch.  If anyone has any objections, please let me know.

As reported by Guenter Roeck, this patch doesn't compile on 3.14 because
it deleted randomize_base which is still used by the macro
ELF_ET_DYN_BASE. That use was removed in 3.18 by commit 92980405f353
("arm64: ASLR: Don't randomise text when randomise_va_space == 0")

Looking at that commit it seems to be what caused the bug $subject patch
fixes because it stopped the arm64 implementation putting loaded
binaries 2/3rds the way up a task's address range.

So it seems to me, either $subject patch should only be applied to 
Linux versions 3.18 through 4.0 inclusive; or the fix in commit
92980405f353 also needs backporting to stable kernels before 3.18. (Or
some more other solution.)

Either way, it seems $subject patch also needs...

Fixes: 92980405f353 ("arm64: ASLR: Don't randomise text when randomise_va_space == 0")

Leaving patch quoted below for reference...
> 
> From: Jon Medhurst <tixy@linaro.org>
> 
> [As mentioned in the commit message, the problem this patch fixes can't
> occur in kernels with commit d1fd836dcf00, i.e Linux 4.1 and later.,
> but earlier kernel versions need this fix.]
> 
> When a process is created, various address randomisations could end up
> colluding to place the address of brk in the stack memory. This would
> mean processes making small heap based memory allocations are in danger
> of having them overwriting, or overwritten by, the stack.
> 
> Another consequence, is that even for processes that make no use of
> brk, the output of /proc/*/maps may show the stack area listed as
> '[heap]' rather than '[stack]'. Apart from being misleading this causes
> fatal errors with the Android run-time like:
> "No [stack] line found in /proc/self/task/*/maps"
> 
> To prevent this problem pick a limit for brk that allows for the stack's
> memory. At the same time we remove randomize_base() as that was only
> used by arch_randomize_brk().
> 
> Note, in practice, since commit d1fd836dcf00 ("mm: split ET_DYN ASLR
> from mmap ASLR") this problem shouldn't occur because the address chosen
> for loading binaries is well clear of the stack, however, prior to that
> the problem does occur because of the following...
> 
> The memory layout of a task is determined by arch_pick_mmap_layout. If
> address randomisation is enabled (task has flag PF_RANDOMIZE) this sets
> mmap_base to a random address at the top of task memory just below a
> region calculated to allow for a stack which itself may have a random
> base address. Any mmap operations that then happen which require an
> address allocating will use the topdown allocation method, i.e. the
> first allocated memory will be at the top of memory, just below the
> area set aside for the stack.
> 
> When a relocatable binary is loaded into a new process by
> load_elf_binary and randomised address are enabled, it uses a
> 'load_bias' of zero, so that when mmap is called to create a memory
> region for it, a new address is picked (address zero not being
> available). As this is the first memory region in the task, it gets the
> region just below the stack, as described previously.
> 
> The loader then set's brk to the end of the elf data section, which will
> be near the end of the loaded binary and then it calls
> arch_randomize_brk. As this currently stands, this adds a random amount
> to brk, which unfortunately may take it into the address range where the
> stack lies.
> 
> Testing:
> 
> These changes have been tested on Linux 3.18 (where the collision of brk
> and stack can happen) using 100000 invocations of a program [1] that can
> display the offset of a process's brk...
> 
> $for i in $(seq 100000); do ./aslr --report brk ; done
> 
> This shows values of brk are evenly distributed over a 1GB range before
> this change is applied. After this change the distribution shows a slope
> where lower values for brk are more common and upper values have about
> half the frequency of those.
> 
> [1] http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files/2499/scripts/kernel-security/aslr/
> 
> Signed-off-by: Jon Medhurst <tixy@linaro.org>
> Acked-by: Kees Cook <keescook@chromium.org>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> 
> 
> I originally posted this to the ARM kernel list and arm64 maintainers,
> see http://www.spinics.net/lists/arm-kernel/msg502238.html
> 
>  arch/arm64/kernel/process.c |   24 ++++++++++++++++++------
>  1 file changed, 18 insertions(+), 6 deletions(-)
> 
> --- a/arch/arm64/kernel/process.c
> +++ b/arch/arm64/kernel/process.c
> @@ -350,15 +350,27 @@ unsigned long arch_align_stack(unsigned
>  	return sp & ~0xf;
>  }
>  
> -static unsigned long randomize_base(unsigned long base)
> +unsigned long arch_randomize_brk(struct mm_struct *mm)
>  {
> +	unsigned long base = mm->brk;
>  	unsigned long range_end = base + (STACK_RND_MASK << PAGE_SHIFT) + 1;
> -	return randomize_range(base, range_end, 0) ? : base;
> -}
> +	unsigned long max_stack, range_limit;
>  
> -unsigned long arch_randomize_brk(struct mm_struct *mm)
> -{
> -	return randomize_base(mm->brk);
> +	/*
> +	 * Determine how much room we need to leave available for the stack.
> +	 * We limit this to a reasonable value, because extremely large or
> +	 * unlimited stacks are always going to bump up against brk at some
> +	 * point and we don't want to fail to randomise brk in those cases.
> +	 */
> +	max_stack = rlimit(RLIMIT_STACK);
> +	if (max_stack > SZ_128M)
> +		max_stack = SZ_128M;
> +
> +	range_limit = mm->start_stack - max_stack - 1;
> +	if (range_end > range_limit)
> +		range_end = range_limit;
> +
> +	return randomize_range(base, range_end, 0) ? : base;
>  }
>  
>  unsigned long randomize_et_dyn(unsigned long base)
> 
> 

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

#1402582 — Re: [PATCH 3.14 17/17] arm64: Make arch_randomize_brk avoid stack area

On Tue, May 17, 2016 at 10:49:23AM +0100, Jon Medhurst (Tixy) wrote:
> On Mon, 2016-05-16 at 18:14 -0700, Greg Kroah-Hartman wrote:
> > 3.14-stable review patch.  If anyone has any objections, please let me know.
> 
> As reported by Guenter Roeck, this patch doesn't compile on 3.14 because
> it deleted randomize_base which is still used by the macro
> ELF_ET_DYN_BASE. That use was removed in 3.18 by commit 92980405f353
> ("arm64: ASLR: Don't randomise text when randomise_va_space == 0")
> 
> Looking at that commit it seems to be what caused the bug $subject patch
> fixes because it stopped the arm64 implementation putting loaded
> binaries 2/3rds the way up a task's address range.
> 
> So it seems to me, either $subject patch should only be applied to 
> Linux versions 3.18 through 4.0 inclusive; or the fix in commit
> 92980405f353 also needs backporting to stable kernels before 3.18. (Or
> some more other solution.)

Thanks, I'll just drop this from 3.14-stable, as it doesn't seem to make
much sense for it to be backported there.

greg k-h

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

#1402027 — [PATCH 3.14 02/17] get_rock_ridge_filename(): handle malformed NM entries

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

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

From: Al Viro <viro@zeniv.linux.org.uk>

commit 99d825822eade8d827a1817357cbf3f889a552d6 upstream.

Payloads of NM entries are not supposed to contain NUL.  When we run
into such, only the part prior to the first NUL goes into the
concatenation (i.e. the directory entry name being encoded by a bunch
of NM entries).  We do stop when the amount collected so far + the
claimed amount in the current NM entry exceed 254.  So far, so good,
but what we return as the total length is the sum of *claimed*
sizes, not the actual amount collected.  And that can grow pretty
large - not unlimited, since you'd need to put CE entries in
between to be able to get more than the maximum that could be
contained in one isofs directory entry / continuation chunk and
we are stop once we'd encountered 32 CEs, but you can get about 8Kb
easily.  And that's what will be passed to readdir callback as the
name length.  8Kb __copy_to_user() from a buffer allocated by
__get_free_page()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 fs/isofs/rock.c |   13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

--- a/fs/isofs/rock.c
+++ b/fs/isofs/rock.c
@@ -203,6 +203,8 @@ int get_rock_ridge_filename(struct iso_d
 	int retnamlen = 0;
 	int truncate = 0;
 	int ret = 0;
+	char *p;
+	int len;
 
 	if (!ISOFS_SB(inode->i_sb)->s_rock)
 		return 0;
@@ -267,12 +269,17 @@ repeat:
 					rr->u.NM.flags);
 				break;
 			}
-			if ((strlen(retname) + rr->len - 5) >= 254) {
+			len = rr->len - 5;
+			if (retnamlen + len >= 254) {
 				truncate = 1;
 				break;
 			}
-			strncat(retname, rr->u.NM.name, rr->len - 5);
-			retnamlen += rr->len - 5;
+			p = memchr(rr->u.NM.name, '\0', len);
+			if (unlikely(p))
+				len = p - rr->u.NM.name;
+			memcpy(retname + retnamlen, rr->u.NM.name, len);
+			retnamlen += len;
+			retname[retnamlen] = '\0';
 			break;
 		case SIG('R', 'E'):
 			kfree(rs.buffer);

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

#1402030 — [PATCH 3.14 11/17] atl2: Disable unimplemented scatter/gather feature

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

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

From: Ben Hutchings <ben@decadent.org.uk>

[ Upstream commit f43bfaeddc79effbf3d0fcb53ca477cca66f3db8 ]

atl2 includes NETIF_F_SG in hw_features even though it has no support
for non-linear skbs.  This bug was originally harmless since the
driver does not claim to implement checksum offload and that used to
be a requirement for SG.

Now that SG and checksum offload are independent features, if you
explicitly enable SG *and* use one of the rare protocols that can use
SG without checkusm offload, this potentially leaks sensitive
information (before you notice that it just isn't working).  Therefore
this obscure bug has been designated CVE-2016-2117.

Reported-by: Justin Yackoski <jyackoski@crypto-nite.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: ec5f06156423 ("net: Kill link between CSUM and SG features.")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/net/ethernet/atheros/atlx/atl2.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/atheros/atlx/atl2.c
+++ b/drivers/net/ethernet/atheros/atlx/atl2.c
@@ -1413,7 +1413,7 @@ static int atl2_probe(struct pci_dev *pd
 
 	err = -EIO;
 
-	netdev->hw_features = NETIF_F_SG | NETIF_F_HW_VLAN_CTAG_RX;
+	netdev->hw_features = NETIF_F_HW_VLAN_CTAG_RX;
 	netdev->features |= (NETIF_F_HW_VLAN_CTAG_TX | NETIF_F_HW_VLAN_CTAG_RX);
 
 	/* Init PHY as early as possible due to power saving issue  */

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

#1402092

On 05/16/2016 06:14 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.70 release.
> There are 17 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 May 19 01:13:32 UTC 2016.
> Anything received after that time might be too late.
>

Early feedback: Commit 'arm64: Make arch_randomize_brk avoid stack area'
breaks arm64 builds.

arch/arm64/kernel/process.c: In function ‘randomize_et_dyn’:
arch/arm64/kernel/process.c:378:9: error: implicit declaration of function ‘randomize_base’

Guenter

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

#1402580

On Mon, May 16, 2016 at 09:06:51PM -0700, Guenter Roeck wrote:
> On 05/16/2016 06:14 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.14.70 release.
> > There are 17 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 May 19 01:13:32 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> Early feedback: Commit 'arm64: Make arch_randomize_brk avoid stack area'
> breaks arm64 builds.
> 
> arch/arm64/kernel/process.c: In function ‘randomize_et_dyn’:
> arch/arm64/kernel/process.c:378:9: error: implicit declaration of function ‘randomize_base’

Thanks for the report, I've now dropped it from the tree.

greg k-h

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

#1402481

On Mon, May 16, 2016 at 06:14:01PM -0700, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.70 release.
> There are 17 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 May 19 01:13:32 UTC 2016.
> Anything received after that time might be too late.
> 

Build results:
	total: 131 pass: 129 fail: 2
Failed builds:
	arm64:allnoconfig
	arm64:allmodconfig

Qemu test results:
	total: 89 pass: 87 fail: 2
Failed tests:
	arm64:smp:defconfig
	arm64:nosmp:defconfig

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

The failures have already been discussed separately.

Guenter

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

#1402583

On Tue, May 17, 2016 at 10:25:33AM -0700, Guenter Roeck wrote:
> On Mon, May 16, 2016 at 06:14:01PM -0700, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.14.70 release.
> > There are 17 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 May 19 01:13:32 UTC 2016.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 131 pass: 129 fail: 2
> Failed builds:
> 	arm64:allnoconfig
> 	arm64:allmodconfig
> 
> Qemu test results:
> 	total: 89 pass: 87 fail: 2
> Failed tests:
> 	arm64:smp:defconfig
> 	arm64:nosmp:defconfig
> 
> Details are available at http://kerneltests.org/builders.
> 
> The failures have already been discussed separately.

Thanks for the reports for all of these, this build error should now
also be resolved.

greg k-h

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

#1402489

On 05/16/2016 07:14 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.70 release.
> There are 17 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 May 19 01:13:32 UTC 2016.
> 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/v3.x/stable-review/patch-3.14.70-rc1.gz
> 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]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web