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

Groups > linux.kernel > #1630592 > unrolled thread

[PATCH 4.4 00/28] 4.4.64-stable review

Back to article view | Back to linux.kernel

Contents

  [PATCH 4.4 00/28] 4.4.64-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:10 +0200
    [PATCH 4.4 12/28] VSOCK: Detach QP check should filter out non matching QPs. Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 14/28] ACPI / power: Avoid maybe-uninitialized warning Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 24/28] Drivers: hv: balloon: account for gaps in hot add regions Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 13/28] Input: elantech - add Fujitsu Lifebook E547 to force crc_enabled Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 06/28] cifs: Do not send echoes before Negotiate is complete Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
      Re: [PATCH 4.4 06/28] cifs: Do not send echoes before Negotiate is  complete Ben Hutchings <ben.hutchings@codethink.co.uk> - 2017-05-09 14:20 +0200
        RE: [PATCH 4.4 06/28] cifs: Do not send echoes before Negotiate is  complete Pavel Shilovskiy <pshilov@microsoft.com> - 2017-05-10 03:10 +0200
    [PATCH 4.4 25/28] hv: dont reset hv_context.tsc_page on crash Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 16/28] mac80211: reject ToDS broadcast data frames Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 21/28] powerpc/64: Fix flush_(d|i)cache_range() called from modules Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 19/28] x86/mce/AMD: Give a name to MCA bank 3 when accessed with legacy MSRs Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 08/28] s390/mm: fix CMMA vs KSM vs others Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:20 +0200
    [PATCH 4.4 15/28] mmc: sdhci-esdhc-imx: increase the pad I/O drive strength for DDR50 card Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 05/28] ring-buffer: Have ring_buffer_iter_empty() return true when empty Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 11/28] Drivers: hv: vmbus: Reduce the delay between retries in vmbus_post_msg() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 28/28] tipc: fix crash during node removal Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 07/28] CIFS: remove bad_network_name flag Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 04/28] tracing: Allocate the snapshot buffer before enabling probe Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 17/28] ubi/upd: Always flush after prepared for an update Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 22/28] Tools: hv: kvp: ensure kvp device fd is closed on exec Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 27/28] block: fix del_gendisk() vs blkdev_ioctl crash Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
      Re: [PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache  cache-bypass assumptions Ben Hutchings <ben.hutchings@codethink.co.uk> - 2017-05-09 19:10 +0200
        Re: [PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache  cache-bypass assumptions Dan Williams <dan.j.williams@intel.com> - 2017-05-09 19:20 +0200
    [PATCH 4.4 23/28] Drivers: hv: balloon: keep track of where ha_region starts Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 02/28] KEYS: Change the name of the dead type to ".dead" to prevent user access Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 09/28] Drivers: hv: dont leak memory in vmbus_establish_gpadl() Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 18/28] powerpc/kprobe: Fix oops when kprobed on stdu instruction Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 20/28] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    [PATCH 4.4 03/28] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-25 17:40 +0200
    Re: [PATCH 4.4 00/28] 4.4.64-stable review Shuah Khan <shuahkh@osg.samsung.com> - 2017-04-25 20:20 +0200
      Re: [PATCH 4.4 00/28] 4.4.64-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-26 10:40 +0200
    Re: [PATCH 4.4 00/28] 4.4.64-stable review Guenter Roeck <linux@roeck-us.net> - 2017-04-25 23:30 +0200
    Re: [PATCH 4.4 00/28] 4.4.64-stable review Guenter Roeck <linux@roeck-us.net> - 2017-04-26 04:30 +0200
      Re: [PATCH 4.4 00/28] 4.4.64-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-26 10:40 +0200
        Re: [PATCH 4.4 00/28] 4.4.64-stable review Guenter Roeck <linux@roeck-us.net> - 2017-04-26 15:20 +0200
          Re: [PATCH 4.4 00/28] 4.4.64-stable review Guenter Roeck <linux@roeck-us.net> - 2017-04-26 15:20 +0200
        Re: [PATCH 4.4 00/28] 4.4.64-stable review Guenter Roeck <linux@roeck-us.net> - 2017-04-26 16:40 +0200
          Re: [PATCH 4.4 00/28] 4.4.64-stable review Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-26 18:00 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1630686 — [PATCH 4.4 22/28] Tools: hv: kvp: ensure kvp device fd is closed on exec

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

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

From: Vitaly Kuznetsov <vkuznets@redhat.com>

commit 26840437cbd6d3625ea6ab34e17cd34bb810c861 upstream.

KVP daemon does fork()/exec() (with popen()) so we need to close our fds
to avoid sharing them with child processes. The immediate implication of
not doing so I see is SELinux complaining about 'ip' trying to access
'/dev/vmbus/hv_kvp'.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 tools/hv/hv_kvp_daemon.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -1433,7 +1433,7 @@ int main(int argc, char *argv[])
 	openlog("KVP", 0, LOG_USER);
 	syslog(LOG_INFO, "KVP starting; pid is:%d", getpid());
 
-	kvp_fd = open("/dev/vmbus/hv_kvp", O_RDWR);
+	kvp_fd = open("/dev/vmbus/hv_kvp", O_RDWR | O_CLOEXEC);
 
 	if (kvp_fd < 0) {
 		syslog(LOG_ERR, "open /dev/vmbus/hv_kvp failed; error: %d %s",

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

#1630687 — [PATCH 4.4 27/28] block: fix del_gendisk() vs blkdev_ioctl crash

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

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

From: Dan Williams <dan.j.williams@intel.com>

commit ac34f15e0c6d2fd58480052b6985f6991fb53bcc upstream.

When tearing down a block device early in its lifetime, userspace may
still be performing discovery actions like blkdev_ioctl() to re-read
partitions.

The nvdimm_revalidate_disk() implementation depends on
disk->driverfs_dev to be valid at entry.  However, it is set to NULL in
del_gendisk() and fatally this is happening *before* the disk device is
deleted from userspace view.

There's no reason for del_gendisk() to clear ->driverfs_dev.  That
device is the parent of the disk.  It is guaranteed to not be freed
until the disk, as a child, drops its ->parent reference.

We could also fix this issue locally in nvdimm_revalidate_disk() by
using disk_to_dev(disk)->parent, but lets fix it globally since
->driverfs_dev follows the lifetime of the parent.  Longer term we
should probably just add a @parent parameter to add_disk(), and stop
carrying this pointer in the gendisk.

 BUG: unable to handle kernel NULL pointer dereference at           (null)
 IP: [<ffffffffa00340a8>] nvdimm_revalidate_disk+0x18/0x90 [libnvdimm]
 CPU: 2 PID: 538 Comm: systemd-udevd Tainted: G           O    4.4.0-rc5 #2257
 [..]
 Call Trace:
  [<ffffffff8143e5c7>] rescan_partitions+0x87/0x2c0
  [<ffffffff810f37f9>] ? __lock_is_held+0x49/0x70
  [<ffffffff81438c62>] __blkdev_reread_part+0x72/0xb0
  [<ffffffff81438cc5>] blkdev_reread_part+0x25/0x40
  [<ffffffff8143982d>] blkdev_ioctl+0x4fd/0x9c0
  [<ffffffff811246c9>] ? current_kernel_time64+0x69/0xd0
  [<ffffffff812916dd>] block_ioctl+0x3d/0x50
  [<ffffffff81264c38>] do_vfs_ioctl+0x308/0x560
  [<ffffffff8115dbd1>] ? __audit_syscall_entry+0xb1/0x100
  [<ffffffff810031d6>] ? do_audit_syscall_entry+0x66/0x70
  [<ffffffff81264f09>] SyS_ioctl+0x79/0x90
  [<ffffffff81902672>] entry_SYSCALL_64_fastpath+0x12/0x76

Cc: Jan Kara <jack@suse.cz>
Cc: Jens Axboe <axboe@fb.com>
Reported-by: Robert Hu <robert.hu@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 block/genhd.c |    1 -
 1 file changed, 1 deletion(-)

--- a/block/genhd.c
+++ b/block/genhd.c
@@ -664,7 +664,6 @@ void del_gendisk(struct gendisk *disk)
 
 	kobject_put(disk->part0.holder_dir);
 	kobject_put(disk->slave_dir);
-	disk->driverfs_dev = NULL;
 	if (!sysfs_deprecated)
 		sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk)));
 	pm_runtime_set_memalloc_noio(disk_to_dev(disk), false);

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

#1630688 — [PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions

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

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

From: Dan Williams <dan.j.williams@intel.com>

commit 11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd upstream.

Before we rework the "pmem api" to stop abusing __copy_user_nocache()
for memcpy_to_pmem() we need to fix cases where we may strand dirty data
in the cpu cache. The problem occurs when copy_from_iter_pmem() is used
for arbitrary data transfers from userspace. There is no guarantee that
these transfers, performed by dax_iomap_actor(), will have aligned
destinations or aligned transfer lengths. Backstop the usage
__copy_user_nocache() with explicit cache management in these unaligned
cases.

Yes, copy_from_iter_pmem() is now too big for an inline, but addressing
that is saved for a later patch that moves the entirety of the "pmem
api" into the pmem driver directly.

Fixes: 5de490daec8b ("pmem: add copy_from_iter_pmem() and clear_pmem()")
Cc: <x86@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/x86/include/asm/pmem.h |   45 +++++++++++++++++++++++++++++++-------------
 1 file changed, 32 insertions(+), 13 deletions(-)

--- a/arch/x86/include/asm/pmem.h
+++ b/arch/x86/include/asm/pmem.h
@@ -72,8 +72,8 @@ static inline void arch_wmb_pmem(void)
  * @size:	number of bytes to write back
  *
  * Write back a cache range using the CLWB (cache line write back)
- * instruction.  This function requires explicit ordering with an
- * arch_wmb_pmem() call.  This API is internal to the x86 PMEM implementation.
+ * instruction. Note that @size is internally rounded up to be cache
+ * line size aligned.
  */
 static inline void __arch_wb_cache_pmem(void *vaddr, size_t size)
 {
@@ -87,15 +87,6 @@ static inline void __arch_wb_cache_pmem(
 		clwb(p);
 }
 
-/*
- * copy_from_iter_nocache() on x86 only uses non-temporal stores for iovec
- * iterators, so for other types (bvec & kvec) we must do a cache write-back.
- */
-static inline bool __iter_needs_pmem_wb(struct iov_iter *i)
-{
-	return iter_is_iovec(i) == false;
-}
-
 /**
  * arch_copy_from_iter_pmem - copy data from an iterator to PMEM
  * @addr:	PMEM destination address
@@ -114,8 +105,36 @@ static inline size_t arch_copy_from_iter
 	/* TODO: skip the write-back by always using non-temporal stores */
 	len = copy_from_iter_nocache(vaddr, bytes, i);
 
-	if (__iter_needs_pmem_wb(i))
-		__arch_wb_cache_pmem(vaddr, bytes);
+	/*
+	 * In the iovec case on x86_64 copy_from_iter_nocache() uses
+	 * non-temporal stores for the bulk of the transfer, but we need
+	 * to manually flush if the transfer is unaligned. A cached
+	 * memory copy is used when destination or size is not naturally
+	 * aligned. That is:
+	 *   - Require 8-byte alignment when size is 8 bytes or larger.
+	 *   - Require 4-byte alignment when size is 4 bytes.
+	 *
+	 * In the non-iovec case the entire destination needs to be
+	 * flushed.
+	 */
+	if (iter_is_iovec(i)) {
+		unsigned long flushed, dest = (unsigned long) addr;
+
+		if (bytes < 8) {
+			if (!IS_ALIGNED(dest, 4) || (bytes != 4))
+				__arch_wb_cache_pmem(addr, 1);
+		} else {
+			if (!IS_ALIGNED(dest, 8)) {
+				dest = ALIGN(dest, boot_cpu_data.x86_clflush_size);
+				__arch_wb_cache_pmem(addr, 1);
+			}
+
+			flushed = dest - (unsigned long) addr;
+			if (bytes > flushed && !IS_ALIGNED(bytes - flushed, 8))
+				__arch_wb_cache_pmem(addr + bytes - 1, 1);
+		}
+	} else
+		__arch_wb_cache_pmem(addr, bytes);
 
 	return len;
 }

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

#1638299 — Re: [PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions

On Tue, 2017-04-25 at 16:08 +0100, Greg Kroah-Hartman wrote:
> 4.4-stable review patch.  If anyone has any objections, please let me know.
> 
> ------------------
> 
> From: Dan Williams <dan.j.williams@intel.com>
> 
> commit 11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd upstream.
[...]
> +	if (iter_is_iovec(i)) {
> +		unsigned long flushed, dest = (unsigned long) addr;
> +
> +		if (bytes < 8) {
> +			if (!IS_ALIGNED(dest, 4) || (bytes != 4))
> +				__arch_wb_cache_pmem(addr, 1);
[...]

What if the write crosses a cache line boundary?  I think you need the
following fix-up (untested, I don't have this kind of hardware).

Ben.

---
From: Ben Hutchings <ben.hutchings@codethink.co.uk>
Subject: x86, pmem: Fix cache flushing for iovec write < 8 bytes

Commit 11e63f6d920d added cache flushing for unaligned writes from an
iovec, covering the first and last cache line of a >= 8 byte write and
the first cache line of a < 8 byte write.  But an unaligned write of
2-7 bytes can still cover two cache lines, so make sure we flush both
in that case.

Fixes: 11e63f6d920d ("x86, pmem: fix broken __copy_user_nocache ...")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
---
 arch/x86/include/asm/pmem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
index d5a22bac9988..0ff8fe71b255 100644
--- a/arch/x86/include/asm/pmem.h
+++ b/arch/x86/include/asm/pmem.h
@@ -98,7 +98,7 @@ static inline size_t arch_copy_from_iter_pmem(void *addr, size_t bytes,
 
 		if (bytes < 8) {
 			if (!IS_ALIGNED(dest, 4) || (bytes != 4))
-				arch_wb_cache_pmem(addr, 1);
+				arch_wb_cache_pmem(addr, bytes);
 		} else {
 			if (!IS_ALIGNED(dest, 8)) {
 				dest = ALIGN(dest, boot_cpu_data.x86_clflush_size);

-- 
Ben Hutchings
Software Developer, Codethink Ltd.

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

#1638311 — Re: [PATCH 4.4 26/28] x86, pmem: fix broken __copy_user_nocache cache-bypass assumptions

On Tue, May 9, 2017 at 10:00 AM, Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Tue, 2017-04-25 at 16:08 +0100, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch.  If anyone has any objections, please let me know.
>>
>> ------------------
>>
>> From: Dan Williams <dan.j.williams@intel.com>
>>
>> commit 11e63f6d920d6f2dfd3cd421e939a4aec9a58dcd upstream.
> [...]
>> +     if (iter_is_iovec(i)) {
>> +             unsigned long flushed, dest = (unsigned long) addr;
>> +
>> +             if (bytes < 8) {
>> +                     if (!IS_ALIGNED(dest, 4) || (bytes != 4))
>> +                             __arch_wb_cache_pmem(addr, 1);
> [...]
>
> What if the write crosses a cache line boundary?  I think you need the
> following fix-up (untested, I don't have this kind of hardware).
>
> Ben.
>
> ---
> From: Ben Hutchings <ben.hutchings@codethink.co.uk>
> Subject: x86, pmem: Fix cache flushing for iovec write < 8 bytes
>
> Commit 11e63f6d920d added cache flushing for unaligned writes from an
> iovec, covering the first and last cache line of a >= 8 byte write and
> the first cache line of a < 8 byte write.  But an unaligned write of
> 2-7 bytes can still cover two cache lines, so make sure we flush both
> in that case.
>
> Fixes: 11e63f6d920d ("x86, pmem: fix broken __copy_user_nocache ...")
> Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
> ---
>  arch/x86/include/asm/pmem.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/pmem.h b/arch/x86/include/asm/pmem.h
> index d5a22bac9988..0ff8fe71b255 100644
> --- a/arch/x86/include/asm/pmem.h
> +++ b/arch/x86/include/asm/pmem.h
> @@ -98,7 +98,7 @@ static inline size_t arch_copy_from_iter_pmem(void *addr, size_t bytes,
>
>                 if (bytes < 8) {
>                         if (!IS_ALIGNED(dest, 4) || (bytes != 4))
> -                               arch_wb_cache_pmem(addr, 1);
> +                               arch_wb_cache_pmem(addr, bytes);

Yes, this looks correct to me. I deeply appreciate your attention to
detail, Ben.

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

#1630689 — [PATCH 4.4 23/28] Drivers: hv: balloon: keep track of where ha_region starts

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

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

From: Vitaly Kuznetsov <vkuznets@redhat.com>

commit 7cf3b79ec85ee1a5bbaaf936bb1d050dc652983b upstream.

Windows 2012 (non-R2) does not specify hot add region in hot add requests
and the logic in hot_add_req() is trying to find a 128Mb-aligned region
covering the request. It may also happen that host's requests are not 128Mb
aligned and the created ha_region will start before the first specified
PFN. We can't online these non-present pages but we don't remember the real
start of the region.

This is a regression introduced by the commit 5abbbb75d733 ("Drivers: hv:
hv_balloon: don't lose memory when onlining order is not natural"). While
the idea of keeping the 'moving window' was wrong (as there is no guarantee
that hot add requests come ordered) we should still keep track of
covered_start_pfn. This is not a revert, the logic is different.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 drivers/hv/hv_balloon.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -430,13 +430,14 @@ struct dm_info_msg {
  * currently hot added. We hot add in multiples of 128M
  * chunks; it is possible that we may not be able to bring
  * online all the pages in the region. The range
- * covered_end_pfn defines the pages that can
+ * covered_start_pfn:covered_end_pfn defines the pages that can
  * be brough online.
  */
 
 struct hv_hotadd_state {
 	struct list_head list;
 	unsigned long start_pfn;
+	unsigned long covered_start_pfn;
 	unsigned long covered_end_pfn;
 	unsigned long ha_end_pfn;
 	unsigned long end_pfn;
@@ -682,7 +683,8 @@ static void hv_online_page(struct page *
 
 	list_for_each(cur, &dm_device.ha_region_list) {
 		has = list_entry(cur, struct hv_hotadd_state, list);
-		cur_start_pgp = (unsigned long)pfn_to_page(has->start_pfn);
+		cur_start_pgp = (unsigned long)
+			pfn_to_page(has->covered_start_pfn);
 		cur_end_pgp = (unsigned long)pfn_to_page(has->covered_end_pfn);
 
 		if (((unsigned long)pg >= cur_start_pgp) &&
@@ -854,6 +856,7 @@ static unsigned long process_hot_add(uns
 		list_add_tail(&ha_region->list, &dm_device.ha_region_list);
 		ha_region->start_pfn = rg_start;
 		ha_region->ha_end_pfn = rg_start;
+		ha_region->covered_start_pfn = pg_start;
 		ha_region->covered_end_pfn = pg_start;
 		ha_region->end_pfn = rg_start + rg_size;
 	}

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

#1630690 — [PATCH 4.4 02/28] KEYS: Change the name of the dead type to ".dead" to prevent user access

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

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

From: David Howells <dhowells@redhat.com>

commit c1644fe041ebaf6519f6809146a77c3ead9193af upstream.

This fixes CVE-2017-6951.

Userspace should not be able to do things with the "dead" key type as it
doesn't have some of the helper functions set upon it that the kernel
needs.  Attempting to use it may cause the kernel to crash.

Fix this by changing the name of the type to ".dead" so that it's rejected
up front on userspace syscalls by key_get_type_from_user().

Though this doesn't seem to affect recent kernels, it does affect older
ones, certainly those prior to:

	commit c06cfb08b88dfbe13be44a69ae2fdc3a7c902d81
	Author: David Howells <dhowells@redhat.com>
	Date:   Tue Sep 16 17:36:06 2014 +0100
	KEYS: Remove key_type::match in favour of overriding default by match_preparse

which went in before 3.18-rc1.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 security/keys/gc.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -46,7 +46,7 @@ static unsigned long key_gc_flags;
  * immediately unlinked.
  */
 struct key_type key_type_dead = {
-	.name = "dead",
+	.name = ".dead",
 };
 
 /*

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

#1630691 — [PATCH 4.4 09/28] Drivers: hv: dont leak memory in vmbus_establish_gpadl()

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

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

From: Vitaly Kuznetsov <vkuznets@redhat.com>

commit 7cc80c98070ccc7940fc28811c92cca0a681015d upstream.

In some cases create_gpadl_header() allocates submessages but we never
free them.

[sumits] Note for stable:
Upstream commit 4d63763296ab7865a98bc29cc7d77145815ef89f:
(Drivers: hv: get rid of redundant messagecount in create_gpadl_header())
changes the list usage to initialize list header in all cases; that patch
isn't added to stable, so the current patch is modified a little bit from
the upstream commit to check if the list is valid or not.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 drivers/hv/channel.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -375,7 +375,7 @@ int vmbus_establish_gpadl(struct vmbus_c
 	struct vmbus_channel_gpadl_header *gpadlmsg;
 	struct vmbus_channel_gpadl_body *gpadl_body;
 	struct vmbus_channel_msginfo *msginfo = NULL;
-	struct vmbus_channel_msginfo *submsginfo;
+	struct vmbus_channel_msginfo *submsginfo, *tmp;
 	u32 msgcount;
 	struct list_head *curr;
 	u32 next_gpadl_handle;
@@ -437,6 +437,13 @@ cleanup:
 	list_del(&msginfo->msglistentry);
 	spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
 
+	if (msgcount > 1) {
+		list_for_each_entry_safe(submsginfo, tmp, &msginfo->submsglist,
+			 msglistentry) {
+			kfree(submsginfo);
+		}
+	}
+
 	kfree(msginfo);
 	return ret;
 }

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

#1630696 — [PATCH 4.4 18/28] powerpc/kprobe: Fix oops when kprobed on stdu instruction

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

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

From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>

commit 9e1ba4f27f018742a1aa95d11e35106feba08ec1 upstream.

If we set a kprobe on a 'stdu' instruction on powerpc64, we see a kernel
OOPS:

  Bad kernel stack pointer cd93c840 at c000000000009868
  Oops: Bad kernel stack pointer, sig: 6 [#1]
  ...
  GPR00: c000001fcd93cb30 00000000cd93c840 c0000000015c5e00 00000000cd93c840
  ...
  NIP [c000000000009868] resume_kernel+0x2c/0x58
  LR [c000000000006208] program_check_common+0x108/0x180

On a 64-bit system when the user probes on a 'stdu' instruction, the kernel does
not emulate actual store in emulate_step() because it may corrupt the exception
frame. So the kernel does the actual store operation in exception return code
i.e. resume_kernel().

resume_kernel() loads the saved stack pointer from memory using lwz, which only
loads the low 32-bits of the address, causing the kernel crash.

Fix this by loading the 64-bit value instead.

Fixes: be96f63375a1 ("powerpc: Split out instruction analysis part of emulate_step()")
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Reviewed-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Reviewed-by: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
[mpe: Change log massage, add stable tag]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/kernel/entry_64.S |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -716,7 +716,7 @@ resume_kernel:
 
 	addi	r8,r1,INT_FRAME_SIZE	/* Get the kprobed function entry */
 
-	lwz	r3,GPR1(r1)
+	ld	r3,GPR1(r1)
 	subi	r3,r3,INT_FRAME_SIZE	/* dst: Allocate a trampoline exception frame */
 	mr	r4,r1			/* src:  current exception frame */
 	mr	r1,r3			/* Reroute the trampoline frame to r1 */
@@ -730,8 +730,8 @@ resume_kernel:
 	addi	r6,r6,8
 	bdnz	2b
 
-	/* Do real store operation to complete stwu */
-	lwz	r5,GPR1(r1)
+	/* Do real store operation to complete stdu */
+	ld	r5,GPR1(r1)
 	std	r8,0(r5)
 
 	/* Clear _TIF_EMULATE_STACK_STORE flag */

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

#1630697 — [PATCH 4.4 20/28] kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd

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

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

From: Suzuki K Poulose <suzuki.poulose@arm.com>

commit 8b3405e345b5a098101b0c31b264c812bba045d9 upstream.

In kvm_free_stage2_pgd() we don't hold the kvm->mmu_lock while calling
unmap_stage2_range() on the entire memory range for the guest. This could
cause problems with other callers (e.g, munmap on a memslot) trying to
unmap a range. And since we have to unmap the entire Guest memory range
holding a spinlock, make sure we yield the lock if necessary, after we
unmap each PUD range.

Fixes: commit d5d8184d35c9 ("KVM: ARM: Memory virtualization setup")
Cc: Paolo Bonzini <pbonzin@redhat.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
[ Avoid vCPU starvation and lockup detector warnings ]
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/arm/kvm/mmu.c |   12 ++++++++++++
 1 file changed, 12 insertions(+)

--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -300,6 +300,14 @@ static void unmap_range(struct kvm *kvm,
 		next = kvm_pgd_addr_end(addr, end);
 		if (!pgd_none(*pgd))
 			unmap_puds(kvm, pgd, addr, next);
+		/*
+		 * If we are dealing with a large range in
+		 * stage2 table, release the kvm->mmu_lock
+		 * to prevent starvation and lockup detector
+		 * warnings.
+		 */
+		if (kvm && (next != end))
+			cond_resched_lock(&kvm->mmu_lock);
 	} while (pgd++, addr = next, addr != end);
 }
 
@@ -738,6 +746,7 @@ int kvm_alloc_stage2_pgd(struct kvm *kvm
  */
 static void unmap_stage2_range(struct kvm *kvm, phys_addr_t start, u64 size)
 {
+	assert_spin_locked(&kvm->mmu_lock);
 	unmap_range(kvm, kvm->arch.pgd, start, size);
 }
 
@@ -824,7 +833,10 @@ void kvm_free_stage2_pgd(struct kvm *kvm
 	if (kvm->arch.pgd == NULL)
 		return;
 
+	spin_lock(&kvm->mmu_lock);
 	unmap_stage2_range(kvm, 0, KVM_PHYS_SIZE);
+	spin_unlock(&kvm->mmu_lock);
+
 	kvm_free_hwpgd(kvm_get_hwpgd(kvm));
 	if (KVM_PREALLOC_LEVEL > 0)
 		kfree(kvm->arch.pgd);

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

#1630698 — [PATCH 4.4 03/28] KEYS: fix keyctl_set_reqkey_keyring() to not leak thread keyrings

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

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

From: Eric Biggers <ebiggers@google.com>

commit c9f838d104fed6f2f61d68164712e3204bf5271b upstream.

This fixes CVE-2017-7472.

Running the following program as an unprivileged user exhausts kernel
memory by leaking thread keyrings:

	#include <keyutils.h>

	int main()
	{
		for (;;)
			keyctl_set_reqkey_keyring(KEY_REQKEY_DEFL_THREAD_KEYRING);
	}

Fix it by only creating a new thread keyring if there wasn't one before.
To make things more consistent, make install_thread_keyring_to_cred()
and install_process_keyring_to_cred() both return 0 if the corresponding
keyring is already present.

Fixes: d84f4f992cbd ("CRED: Inaugurate COW credentials")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 security/keys/keyctl.c       |   11 +++-------
 security/keys/process_keys.c |   44 ++++++++++++++++++++++++++-----------------
 2 files changed, 31 insertions(+), 24 deletions(-)

--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1228,8 +1228,8 @@ error:
  * Read or set the default keyring in which request_key() will cache keys and
  * return the old setting.
  *
- * If a process keyring is specified then this will be created if it doesn't
- * yet exist.  The old setting will be returned if successful.
+ * If a thread or process keyring is specified then it will be created if it
+ * doesn't yet exist.  The old setting will be returned if successful.
  */
 long keyctl_set_reqkey_keyring(int reqkey_defl)
 {
@@ -1254,11 +1254,8 @@ long keyctl_set_reqkey_keyring(int reqke
 
 	case KEY_REQKEY_DEFL_PROCESS_KEYRING:
 		ret = install_process_keyring_to_cred(new);
-		if (ret < 0) {
-			if (ret != -EEXIST)
-				goto error;
-			ret = 0;
-		}
+		if (ret < 0)
+			goto error;
 		goto set;
 
 	case KEY_REQKEY_DEFL_DEFAULT:
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -125,13 +125,18 @@ error:
 }
 
 /*
- * Install a fresh thread keyring directly to new credentials.  This keyring is
- * allowed to overrun the quota.
+ * Install a thread keyring to the given credentials struct if it didn't have
+ * one already.  This is allowed to overrun the quota.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
  */
 int install_thread_keyring_to_cred(struct cred *new)
 {
 	struct key *keyring;
 
+	if (new->thread_keyring)
+		return 0;
+
 	keyring = keyring_alloc("_tid", new->uid, new->gid, new,
 				KEY_POS_ALL | KEY_USR_VIEW,
 				KEY_ALLOC_QUOTA_OVERRUN, NULL);
@@ -143,7 +148,9 @@ int install_thread_keyring_to_cred(struc
 }
 
 /*
- * Install a fresh thread keyring, discarding the old one.
+ * Install a thread keyring to the current task if it didn't have one already.
+ *
+ * Return: 0 if a thread keyring is now present; -errno on failure.
  */
 static int install_thread_keyring(void)
 {
@@ -154,8 +161,6 @@ static int install_thread_keyring(void)
 	if (!new)
 		return -ENOMEM;
 
-	BUG_ON(new->thread_keyring);
-
 	ret = install_thread_keyring_to_cred(new);
 	if (ret < 0) {
 		abort_creds(new);
@@ -166,17 +171,17 @@ static int install_thread_keyring(void)
 }
 
 /*
- * Install a process keyring directly to a credentials struct.
+ * Install a process keyring to the given credentials struct if it didn't have
+ * one already.  This is allowed to overrun the quota.
  *
- * Returns -EEXIST if there was already a process keyring, 0 if one installed,
- * and other value on any other error
+ * Return: 0 if a process keyring is now present; -errno on failure.
  */
 int install_process_keyring_to_cred(struct cred *new)
 {
 	struct key *keyring;
 
 	if (new->process_keyring)
-		return -EEXIST;
+		return 0;
 
 	keyring = keyring_alloc("_pid", new->uid, new->gid, new,
 				KEY_POS_ALL | KEY_USR_VIEW,
@@ -189,11 +194,9 @@ int install_process_keyring_to_cred(stru
 }
 
 /*
- * Make sure a process keyring is installed for the current process.  The
- * existing process keyring is not replaced.
+ * Install a process keyring to the current task if it didn't have one already.
  *
- * Returns 0 if there is a process keyring by the end of this function, some
- * error otherwise.
+ * Return: 0 if a process keyring is now present; -errno on failure.
  */
 static int install_process_keyring(void)
 {
@@ -207,14 +210,18 @@ static int install_process_keyring(void)
 	ret = install_process_keyring_to_cred(new);
 	if (ret < 0) {
 		abort_creds(new);
-		return ret != -EEXIST ? ret : 0;
+		return ret;
 	}
 
 	return commit_creds(new);
 }
 
 /*
- * Install a session keyring directly to a credentials struct.
+ * Install the given keyring as the session keyring of the given credentials
+ * struct, replacing the existing one if any.  If the given keyring is NULL,
+ * then install a new anonymous session keyring.
+ *
+ * Return: 0 on success; -errno on failure.
  */
 int install_session_keyring_to_cred(struct cred *cred, struct key *keyring)
 {
@@ -249,8 +256,11 @@ int install_session_keyring_to_cred(stru
 }
 
 /*
- * Install a session keyring, discarding the old one.  If a keyring is not
- * supplied, an empty one is invented.
+ * Install the given keyring as the session keyring of the current task,
+ * replacing the existing one if any.  If the given keyring is NULL, then
+ * install a new anonymous session keyring.
+ *
+ * Return: 0 on success; -errno on failure.
  */
 static int install_session_keyring(struct key *keyring)
 {

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

#1630858

On 04/25/2017 09:08 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.64 release.
> There are 28 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 Apr 27 15:08:00 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.4.64-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.4.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]

#1631240

On Tue, Apr 25, 2017 at 12:18:24PM -0600, Shuah Khan wrote:
> On 04/25/2017 09:08 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.64 release.
> > There are 28 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 Apr 27 15:08:00 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.4.64-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.4.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h

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

#1631009

On Tue, Apr 25, 2017 at 04:08:31PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.64 release.
> There are 28 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 Apr 27 15:08:00 UTC 2017.
> Anything received after that time might be too late.
> 
Early feedback: Various powerpc builds (defconfig, allmodconfig,
ppc64e_defconfig, cell_defconfig, maple_defconfig) fail with

arch/powerpc/kernel/misc_64.S: Assembler messages:
arch/powerpc/kernel/misc_64.S:72: Error:
	.localentry expression for `flush_icache_range' does not evaluate to a constant

This appears to be due to 'powerpc/64: Fix flush_(d|i)cache_range() called from
modules'. No idea what is wrong with it, though; maybe some context patch is
missing. Copying the author and Michael.

Guenter

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

#1631110

On 04/25/2017 08:08 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.64 release.
> There are 28 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 Apr 27 15:08:00 UTC 2017.
> Anything received after that time might be too late.
>

Build results:
	total: 149 pass: 144 fail: 5
Failed builds:
	powerpc:defconfig
	powerpc:allmodconfig
	powerpc:ppc64e_defconfig
	powerpc:cell_defconfig
	powerpc:maple_defconfig

Qemu test results:
	total: 115 pass: 110 fail: 5
Failed tests:
	powerpc:mac99:ppc64_book3s_defconfig:nosmp
	powerpc:mac99:ppc64_book3s_defconfig:smp4
	powerpc:pseries:pseries_defconfig
	powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
	powerpc:mpc8544ds:ppc64_e5500_defconfig:smp

As mentioned earlier, the failures are

arch/powerpc/kernel/misc_64.S: Assembler messages:
arch/powerpc/kernel/misc_64.S:72: Error: unknown pseudo-op: `.localentry'

or:

arch/powerpc/kernel/misc_64.S: Assembler messages:
arch/powerpc/kernel/misc_64.S:72: Error: .localentry expression for `flush_icache_range' does not evaluate to a constant

The error message depends on the compiler / binutils version.

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

Guenter

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

#1631245

On Tue, Apr 25, 2017 at 07:27:18PM -0700, Guenter Roeck wrote:
> On 04/25/2017 08:08 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.64 release.
> > There are 28 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 Apr 27 15:08:00 UTC 2017.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
> 	total: 149 pass: 144 fail: 5
> Failed builds:
> 	powerpc:defconfig
> 	powerpc:allmodconfig
> 	powerpc:ppc64e_defconfig
> 	powerpc:cell_defconfig
> 	powerpc:maple_defconfig
> 
> Qemu test results:
> 	total: 115 pass: 110 fail: 5
> Failed tests:
> 	powerpc:mac99:ppc64_book3s_defconfig:nosmp
> 	powerpc:mac99:ppc64_book3s_defconfig:smp4
> 	powerpc:pseries:pseries_defconfig
> 	powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
> 	powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
> 
> As mentioned earlier, the failures are
> 
> arch/powerpc/kernel/misc_64.S: Assembler messages:
> arch/powerpc/kernel/misc_64.S:72: Error: unknown pseudo-op: `.localentry'
> 
> or:
> 
> arch/powerpc/kernel/misc_64.S: Assembler messages:
> arch/powerpc/kernel/misc_64.S:72: Error: .localentry expression for `flush_icache_range' does not evaluate to a constant
> 
> The error message depends on the compiler / binutils version.

This patch is now dropped, so the ppc builds should now work.

thanks for testing all of these.

greg k-h

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

#1631451

On 04/26/2017 01:31 AM, Greg Kroah-Hartman wrote:
> On Tue, Apr 25, 2017 at 07:27:18PM -0700, Guenter Roeck wrote:
>> On 04/25/2017 08:08 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.4.64 release.
>>> There are 28 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 Apr 27 15:08:00 UTC 2017.
>>> Anything received after that time might be too late.
>>>
>>
>> Build results:
>> 	total: 149 pass: 144 fail: 5
>> Failed builds:
>> 	powerpc:defconfig
>> 	powerpc:allmodconfig
>> 	powerpc:ppc64e_defconfig
>> 	powerpc:cell_defconfig
>> 	powerpc:maple_defconfig
>>
>> Qemu test results:
>> 	total: 115 pass: 110 fail: 5
>> Failed tests:
>> 	powerpc:mac99:ppc64_book3s_defconfig:nosmp
>> 	powerpc:mac99:ppc64_book3s_defconfig:smp4
>> 	powerpc:pseries:pseries_defconfig
>> 	powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
>> 	powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
>>
>> As mentioned earlier, the failures are
>>
>> arch/powerpc/kernel/misc_64.S: Assembler messages:
>> arch/powerpc/kernel/misc_64.S:72: Error: unknown pseudo-op: `.localentry'
>>
>> or:
>>
>> arch/powerpc/kernel/misc_64.S: Assembler messages:
>> arch/powerpc/kernel/misc_64.S:72: Error: .localentry expression for `flush_icache_range' does not evaluate to a constant
>>
>> The error message depends on the compiler / binutils version.
>
> This patch is now dropped, so the ppc builds should now work.
>

Did you push the change ? My builder didn't pick it up.

Guenter

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

#1631452

On 04/26/2017 06:10 AM, Guenter Roeck wrote:
> On 04/26/2017 01:31 AM, Greg Kroah-Hartman wrote:
>> On Tue, Apr 25, 2017 at 07:27:18PM -0700, Guenter Roeck wrote:
>>> On 04/25/2017 08:08 AM, Greg Kroah-Hartman wrote:
>>>> This is the start of the stable review cycle for the 4.4.64 release.
>>>> There are 28 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 Apr 27 15:08:00 UTC 2017.
>>>> Anything received after that time might be too late.
>>>>
>>>
>>> Build results:
>>>     total: 149 pass: 144 fail: 5
>>> Failed builds:
>>>     powerpc:defconfig
>>>     powerpc:allmodconfig
>>>     powerpc:ppc64e_defconfig
>>>     powerpc:cell_defconfig
>>>     powerpc:maple_defconfig
>>>
>>> Qemu test results:
>>>     total: 115 pass: 110 fail: 5
>>> Failed tests:
>>>     powerpc:mac99:ppc64_book3s_defconfig:nosmp
>>>     powerpc:mac99:ppc64_book3s_defconfig:smp4
>>>     powerpc:pseries:pseries_defconfig
>>>     powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
>>>     powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
>>>
>>> As mentioned earlier, the failures are
>>>
>>> arch/powerpc/kernel/misc_64.S: Assembler messages:
>>> arch/powerpc/kernel/misc_64.S:72: Error: unknown pseudo-op: `.localentry'
>>>
>>> or:
>>>
>>> arch/powerpc/kernel/misc_64.S: Assembler messages:
>>> arch/powerpc/kernel/misc_64.S:72: Error: .localentry expression for `flush_icache_range' does not evaluate to a constant
>>>
>>> The error message depends on the compiler / binutils version.
>>
>> This patch is now dropped, so the ppc builds should now work.
>>
>
> Did you push the change ? My builder didn't pick it up.
>

Please ignore. It did.

Guenter

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

#1631492

On Wed, Apr 26, 2017 at 10:31:56AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 25, 2017 at 07:27:18PM -0700, Guenter Roeck wrote:
> > On 04/25/2017 08:08 AM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.64 release.
> > > There are 28 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 Apr 27 15:08:00 UTC 2017.
> > > Anything received after that time might be too late.
> > > 
> > 
> > Build results:
> > 	total: 149 pass: 144 fail: 5
> > Failed builds:
> > 	powerpc:defconfig
> > 	powerpc:allmodconfig
> > 	powerpc:ppc64e_defconfig
> > 	powerpc:cell_defconfig
> > 	powerpc:maple_defconfig
> > 
> > Qemu test results:
> > 	total: 115 pass: 110 fail: 5
> > Failed tests:
> > 	powerpc:mac99:ppc64_book3s_defconfig:nosmp
> > 	powerpc:mac99:ppc64_book3s_defconfig:smp4
> > 	powerpc:pseries:pseries_defconfig
> > 	powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
> > 	powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
> > 
> > As mentioned earlier, the failures are
> > 
> > arch/powerpc/kernel/misc_64.S: Assembler messages:
> > arch/powerpc/kernel/misc_64.S:72: Error: unknown pseudo-op: `.localentry'
> > 
> > or:
> > 
> > arch/powerpc/kernel/misc_64.S: Assembler messages:
> > arch/powerpc/kernel/misc_64.S:72: Error: .localentry expression for `flush_icache_range' does not evaluate to a constant
> > 
> > The error message depends on the compiler / binutils version.
> 
> This patch is now dropped, so the ppc builds should now work.
> 
Confirmed; all is good now.

Thanks,
Guenter

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

#1631566

On Wed, Apr 26, 2017 at 07:39:21AM -0700, Guenter Roeck wrote:
> On Wed, Apr 26, 2017 at 10:31:56AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 25, 2017 at 07:27:18PM -0700, Guenter Roeck wrote:
> > > On 04/25/2017 08:08 AM, Greg Kroah-Hartman wrote:
> > > > This is the start of the stable review cycle for the 4.4.64 release.
> > > > There are 28 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 Apr 27 15:08:00 UTC 2017.
> > > > Anything received after that time might be too late.
> > > > 
> > > 
> > > Build results:
> > > 	total: 149 pass: 144 fail: 5
> > > Failed builds:
> > > 	powerpc:defconfig
> > > 	powerpc:allmodconfig
> > > 	powerpc:ppc64e_defconfig
> > > 	powerpc:cell_defconfig
> > > 	powerpc:maple_defconfig
> > > 
> > > Qemu test results:
> > > 	total: 115 pass: 110 fail: 5
> > > Failed tests:
> > > 	powerpc:mac99:ppc64_book3s_defconfig:nosmp
> > > 	powerpc:mac99:ppc64_book3s_defconfig:smp4
> > > 	powerpc:pseries:pseries_defconfig
> > > 	powerpc:mpc8544ds:ppc64_e5500_defconfig:nosmp
> > > 	powerpc:mpc8544ds:ppc64_e5500_defconfig:smp
> > > 
> > > As mentioned earlier, the failures are
> > > 
> > > arch/powerpc/kernel/misc_64.S: Assembler messages:
> > > arch/powerpc/kernel/misc_64.S:72: Error: unknown pseudo-op: `.localentry'
> > > 
> > > or:
> > > 
> > > arch/powerpc/kernel/misc_64.S: Assembler messages:
> > > arch/powerpc/kernel/misc_64.S:72: Error: .localentry expression for `flush_icache_range' does not evaluate to a constant
> > > 
> > > The error message depends on the compiler / binutils version.
> > 
> > This patch is now dropped, so the ppc builds should now work.
> > 
> Confirmed; all is good now.

Wonderful, thanks for letting me know.

greg k-h

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web