* Patch "arm64: documentation: document tagged pointer stack constraints" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 14:46 UTC (permalink / raw)
To: kristina.martsenko, Dave.Martin, catalin.marinas, gregkh,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
arm64: documentation: document tagged pointer stack constraints
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm64-documentation-document-tagged-pointer-stack-constraints.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From f0e421b1bf7af97f026e1bb8bfe4c5a7a8c08f42 Mon Sep 17 00:00:00 2001
From: Kristina Martsenko <kristina.martsenko@arm.com>
Date: Wed, 3 May 2017 16:37:48 +0100
Subject: arm64: documentation: document tagged pointer stack constraints
From: Kristina Martsenko <kristina.martsenko@arm.com>
commit f0e421b1bf7af97f026e1bb8bfe4c5a7a8c08f42 upstream.
Some kernel features don't currently work if a task puts a non-zero
address tag in its stack pointer, frame pointer, or frame record entries
(FP, LR).
For example, with a tagged stack pointer, the kernel can't deliver
signals to the process, and the task is killed instead. As another
example, with a tagged frame pointer or frame records, perf fails to
generate call graphs or resolve symbols.
For now, just document these limitations, instead of finding and fixing
everything that doesn't work, as it's not known if anyone needs to use
tags in these places anyway.
In addition, as requested by Dave Martin, generalize the limitations
into a general kernel address tag policy, and refactor
tagged-pointers.txt to include it.
Fixes: d50240a5f6ce ("arm64: mm: permit use of tagged pointers at EL0")
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/arm64/tagged-pointers.txt | 66 +++++++++++++++++++++++---------
1 file changed, 49 insertions(+), 17 deletions(-)
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -11,24 +11,56 @@ in AArch64 Linux.
The kernel configures the translation tables so that translations made
via TTBR0 (i.e. userspace mappings) have the top byte (bits 63:56) of
the virtual address ignored by the translation hardware. This frees up
-this byte for application use, with the following caveats:
+this byte for application use.
- (1) The kernel requires that all user addresses passed to EL1
- are tagged with tag 0x00. This means that any syscall
- parameters containing user virtual addresses *must* have
- their top byte cleared before trapping to the kernel.
-
- (2) Non-zero tags are not preserved when delivering signals.
- This means that signal handlers in applications making use
- of tags cannot rely on the tag information for user virtual
- addresses being maintained for fields inside siginfo_t.
- One exception to this rule is for signals raised in response
- to watchpoint debug exceptions, where the tag information
- will be preserved.
-
- (3) Special care should be taken when using tagged pointers,
- since it is likely that C compilers will not hazard two
- virtual addresses differing only in the upper byte.
+
+Passing tagged addresses to the kernel
+--------------------------------------
+
+All interpretation of userspace memory addresses by the kernel assumes
+an address tag of 0x00.
+
+This includes, but is not limited to, addresses found in:
+
+ - pointer arguments to system calls, including pointers in structures
+ passed to system calls,
+
+ - the stack pointer (sp), e.g. when interpreting it to deliver a
+ signal,
+
+ - the frame pointer (x29) and frame records, e.g. when interpreting
+ them to generate a backtrace or call graph.
+
+Using non-zero address tags in any of these locations may result in an
+error code being returned, a (fatal) signal being raised, or other modes
+of failure.
+
+For these reasons, passing non-zero address tags to the kernel via
+system calls is forbidden, and using a non-zero address tag for sp is
+strongly discouraged.
+
+Programs maintaining a frame pointer and frame records that use non-zero
+address tags may suffer impaired or inaccurate debug and profiling
+visibility.
+
+
+Preserving tags
+---------------
+
+Non-zero tags are not preserved when delivering signals. This means that
+signal handlers in applications making use of tags cannot rely on the
+tag information for user virtual addresses being maintained for fields
+inside siginfo_t. One exception to this rule is for signals raised in
+response to watchpoint debug exceptions, where the tag information will
+be preserved.
The architecture prevents the use of a tagged PC, so the upper byte will
be set to a sign-extension of bit 55 on exception return.
+
+
+Other considerations
+--------------------
+
+Special care should be taken when using tagged pointers, since it is
+likely that C compilers will not hazard two virtual addresses differing
+only in the upper byte.
Patches currently in stable-queue which might be from kristina.martsenko@arm.com are
queue-4.4/arm64-documentation-document-tagged-pointer-stack-constraints.patch
^ permalink raw reply
* Patch "ARM: dts: at91: sama5d3_xplained: not all ADC channels are available" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 14:46 UTC (permalink / raw)
To: ludovic.desroches, alexandre.belloni, gregkh, nicolas.ferre
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-at91-sama5d3_xplained-not-all-adc-channels-are-available.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d3df1ec06353e51fc44563d2e7e18d42811af290 Mon Sep 17 00:00:00 2001
From: Ludovic Desroches <ludovic.desroches@microchip.com>
Date: Mon, 10 Apr 2017 10:25:17 +0200
Subject: ARM: dts: at91: sama5d3_xplained: not all ADC channels are available
From: Ludovic Desroches <ludovic.desroches@microchip.com>
commit d3df1ec06353e51fc44563d2e7e18d42811af290 upstream.
Remove ADC channels that are not available by default on the sama5d3_xplained
board (resistor not populated) in order to not create confusion.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -163,9 +163,9 @@
adc0: adc@f8018000 {
atmel,adc-vref = <3300>;
+ atmel,adc-channels-used = <0xfe>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
- &pinctrl_adc0_ad0
&pinctrl_adc0_ad1
&pinctrl_adc0_ad2
&pinctrl_adc0_ad3
@@ -173,8 +173,6 @@
&pinctrl_adc0_ad5
&pinctrl_adc0_ad6
&pinctrl_adc0_ad7
- &pinctrl_adc0_ad8
- &pinctrl_adc0_ad9
>;
status = "okay";
};
Patches currently in stable-queue which might be from ludovic.desroches@microchip.com are
queue-4.4/arm-dts-at91-sama5d3_xplained-fix-adc-vref.patch
queue-4.4/arm-dts-at91-sama5d3_xplained-not-all-adc-channels-are-available.patch
^ permalink raw reply
* Patch "ARM: dts: at91: sama5d3_xplained: fix ADC vref" has been added to the 4.4-stable tree
From: gregkh @ 2017-05-23 14:46 UTC (permalink / raw)
To: ludovic.desroches, alexandre.belloni, gregkh, nicolas.ferre
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ARM: dts: at91: sama5d3_xplained: fix ADC vref
to the 4.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
arm-dts-at91-sama5d3_xplained-fix-adc-vref.patch
and it can be found in the queue-4.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 9cdd31e5913c1f86dce7e201b086155b3f24896b Mon Sep 17 00:00:00 2001
From: Ludovic Desroches <ludovic.desroches@microchip.com>
Date: Mon, 10 Apr 2017 10:25:16 +0200
Subject: ARM: dts: at91: sama5d3_xplained: fix ADC vref
From: Ludovic Desroches <ludovic.desroches@microchip.com>
commit 9cdd31e5913c1f86dce7e201b086155b3f24896b upstream.
The voltage reference for the ADC is not 3V but 3.3V since it is connected to
VDDANA.
Signed-off-by: Ludovic Desroches <ludovic.desroches@microchip.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/boot/dts/at91-sama5d3_xplained.dts | 1 +
1 file changed, 1 insertion(+)
--- a/arch/arm/boot/dts/at91-sama5d3_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d3_xplained.dts
@@ -162,6 +162,7 @@
};
adc0: adc@f8018000 {
+ atmel,adc-vref = <3300>;
pinctrl-0 = <
&pinctrl_adc0_adtrg
&pinctrl_adc0_ad0
Patches currently in stable-queue which might be from ludovic.desroches@microchip.com are
queue-4.4/arm-dts-at91-sama5d3_xplained-fix-adc-vref.patch
queue-4.4/arm-dts-at91-sama5d3_xplained-not-all-adc-channels-are-available.patch
^ permalink raw reply
* Patch "staging: vc04_services: Fix bulk cache maintenance" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: phil, gregkh, stefan.wahren; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
staging: vc04_services: Fix bulk cache maintenance
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
staging-vc04_services-fix-bulk-cache-maintenance.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From ff92b9e3c9f85fa442c430d70bf075499e1193b7 Mon Sep 17 00:00:00 2001
From: Phil Elwell <phil@raspberrypi.org>
Date: Thu, 4 May 2017 10:58:20 +0100
Subject: staging: vc04_services: Fix bulk cache maintenance
From: Phil Elwell <phil@raspberrypi.org>
commit ff92b9e3c9f85fa442c430d70bf075499e1193b7 upstream.
vchiq_arm supports transfers less than one page and at arbitrary
alignment, using the dma-mapping API to perform its cache maintenance
(even though the VPU drives the DMA hardware). Read (DMA_FROM_DEVICE)
operations use cache invalidation for speed, falling back to
clean+invalidate on partial cache lines, with writes (DMA_TO_DEVICE)
using flushes.
If a read transfer has ends which aren't page-aligned, performing cache
maintenance as if they were whole pages can lead to memory corruption
since the partial cache lines at the ends (and any cache lines before or
after the transfer area) will be invalidated. This bug was masked until
the disabling of the cache flush in flush_dcache_page().
Honouring the requested transfer start- and end-points prevents the
corruption.
Fixes: cf9caf192988 ("staging: vc04_services: Replace dmac_map_area with dmac_map_sg")
Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c | 31 ++++++----
1 file changed, 19 insertions(+), 12 deletions(-)
--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
+++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
@@ -501,8 +501,15 @@ create_pagelist(char __user *buf, size_t
*/
sg_init_table(scatterlist, num_pages);
/* Now set the pages for each scatterlist */
- for (i = 0; i < num_pages; i++)
- sg_set_page(scatterlist + i, pages[i], PAGE_SIZE, 0);
+ for (i = 0; i < num_pages; i++) {
+ unsigned int len = PAGE_SIZE - offset;
+
+ if (len > count)
+ len = count;
+ sg_set_page(scatterlist + i, pages[i], len, offset);
+ offset = 0;
+ count -= len;
+ }
dma_buffers = dma_map_sg(g_dev,
scatterlist,
@@ -523,20 +530,20 @@ create_pagelist(char __user *buf, size_t
u32 addr = sg_dma_address(sg);
/* Note: addrs is the address + page_count - 1
- * The firmware expects the block to be page
+ * The firmware expects blocks after the first to be page-
* aligned and a multiple of the page size
*/
WARN_ON(len == 0);
- WARN_ON(len & ~PAGE_MASK);
- WARN_ON(addr & ~PAGE_MASK);
+ WARN_ON(i && (i != (dma_buffers - 1)) && (len & ~PAGE_MASK));
+ WARN_ON(i && (addr & ~PAGE_MASK));
if (k > 0 &&
- ((addrs[k - 1] & PAGE_MASK) |
- ((addrs[k - 1] & ~PAGE_MASK) + 1) << PAGE_SHIFT)
- == addr) {
- addrs[k - 1] += (len >> PAGE_SHIFT);
- } else {
- addrs[k++] = addr | ((len >> PAGE_SHIFT) - 1);
- }
+ ((addrs[k - 1] & PAGE_MASK) +
+ (((addrs[k - 1] & ~PAGE_MASK) + 1) << PAGE_SHIFT))
+ == (addr & PAGE_MASK))
+ addrs[k - 1] += ((len + PAGE_SIZE - 1) >> PAGE_SHIFT);
+ else
+ addrs[k++] = (addr & PAGE_MASK) |
+ (((len + PAGE_SIZE - 1) >> PAGE_SHIFT) - 1);
}
/* Partial cache lines (fragments) require special measures */
Patches currently in stable-queue which might be from phil@raspberrypi.org are
queue-4.11/staging-vc04_services-fix-bulk-cache-maintenance.patch
^ permalink raw reply
* Patch "uwb: fix device quirk on big-endian hosts" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: johan, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
uwb: fix device quirk on big-endian hosts
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
uwb-fix-device-quirk-on-big-endian-hosts.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 41318a2b82f5d5fe1fb408f6d6e0b22aa557111d Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan@kernel.org>
Date: Fri, 12 May 2017 12:06:32 +0200
Subject: uwb: fix device quirk on big-endian hosts
From: Johan Hovold <johan@kernel.org>
commit 41318a2b82f5d5fe1fb408f6d6e0b22aa557111d upstream.
Add missing endianness conversion when using the USB device-descriptor
idProduct field to apply a hardware quirk.
Fixes: 1ba47da52712 ("uwb: add the i1480 DFU driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/uwb/i1480/dfu/usb.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/uwb/i1480/dfu/usb.c
+++ b/drivers/uwb/i1480/dfu/usb.c
@@ -341,6 +341,7 @@ error_submit_ep1:
static
int i1480_usb_probe(struct usb_interface *iface, const struct usb_device_id *id)
{
+ struct usb_device *udev = interface_to_usbdev(iface);
struct i1480_usb *i1480_usb;
struct i1480 *i1480;
struct device *dev = &iface->dev;
@@ -352,8 +353,8 @@ int i1480_usb_probe(struct usb_interface
iface->cur_altsetting->desc.bInterfaceNumber);
goto error;
}
- if (iface->num_altsetting > 1
- && interface_to_usbdev(iface)->descriptor.idProduct == 0xbabe) {
+ if (iface->num_altsetting > 1 &&
+ le16_to_cpu(udev->descriptor.idProduct) == 0xbabe) {
/* Need altsetting #1 [HW QUIRK] or EP1 won't work */
result = usb_set_interface(interface_to_usbdev(iface), 0, 1);
if (result < 0)
Patches currently in stable-queue which might be from johan@kernel.org are
queue-4.11/cx231xx-audio-fix-null-deref-at-probe.patch
queue-4.11/usb-serial-io_ti-fix-div-by-zero-in-set_termios.patch
queue-4.11/usb-chaoskey-fix-alea-quirk-on-big-endian-hosts.patch
queue-4.11/usb-hub-fix-non-ss-hub-descriptor-handling.patch
queue-4.11/cx231xx-cards-fix-null-deref-at-probe.patch
queue-4.11/usb-serial-ftdi_sio-add-olimex-arm-usb-tiny-h-pids.patch
queue-4.11/usb-serial-ftdi_sio-fix-setting-latency-for-unprivileged-users.patch
queue-4.11/usb-iowarrior-fix-info-ioctl-on-big-endian-hosts.patch
queue-4.11/watchdog-pcwd_usb-fix-null-deref-at-probe.patch
queue-4.11/gspca-konica-add-missing-endpoint-sanity-check.patch
queue-4.11/usb-serial-qcserial-add-more-lenovo-em74xx-device-ids.patch
queue-4.11/usb-serial-option-add-telit-me910-support.patch
queue-4.11/net-irda-irda-usb-fix-firmware-name-on-big-endian-hosts.patch
queue-4.11/dib0700-fix-null-deref-at-probe.patch
queue-4.11/cx231xx-audio-fix-init-error-path.patch
queue-4.11/of-fdt-add-missing-allocation-failure-check.patch
queue-4.11/usbvision-fix-null-deref-at-probe.patch
queue-4.11/usb-serial-mct_u232-fix-big-endian-baud-rate-handling.patch
queue-4.11/uwb-fix-device-quirk-on-big-endian-hosts.patch
queue-4.11/mceusb-fix-null-deref-at-probe.patch
queue-4.11/usb-hub-fix-ss-hub-descriptor-handling.patch
queue-4.11/ath9k_htc-fix-null-deref-at-probe.patch
queue-4.11/usb-musb-fix-trying-to-suspend-while-active-for-otg-configurations.patch
^ permalink raw reply
* Patch "staging: rtl8192e: GetTs Fix invalid TID 7 warning." has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tvboxspy, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
staging: rtl8192e: GetTs Fix invalid TID 7 warning.
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
staging-rtl8192e-getts-fix-invalid-tid-7-warning.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 95d93e271d920dfda369d4740b1cc1061d41fe7f Mon Sep 17 00:00:00 2001
From: Malcolm Priestley <tvboxspy@gmail.com>
Date: Thu, 11 May 2017 18:57:46 +0100
Subject: staging: rtl8192e: GetTs Fix invalid TID 7 warning.
From: Malcolm Priestley <tvboxspy@gmail.com>
commit 95d93e271d920dfda369d4740b1cc1061d41fe7f upstream.
TID 7 is a valid value for QoS IEEE 802.11e.
The switch statement that follows states 7 is valid.
Remove function IsACValid and use the default case to filter
invalid TIDs.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8192e/rtl819x_TSProc.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
--- a/drivers/staging/rtl8192e/rtl819x_TSProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_TSProc.c
@@ -306,11 +306,6 @@ static void MakeTSEntry(struct ts_common
pTsCommonInfo->TClasNum = TCLAS_Num;
}
-static bool IsACValid(unsigned int tid)
-{
- return tid < 7;
-}
-
bool GetTs(struct rtllib_device *ieee, struct ts_common_info **ppTS,
u8 *Addr, u8 TID, enum tr_select TxRxSelect, bool bAddNewTs)
{
@@ -328,12 +323,6 @@ bool GetTs(struct rtllib_device *ieee, s
if (ieee->current_network.qos_data.supported == 0) {
UP = 0;
} else {
- if (!IsACValid(TID)) {
- netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
- __func__, TID);
- return false;
- }
-
switch (TID) {
case 0:
case 3:
@@ -351,6 +340,10 @@ bool GetTs(struct rtllib_device *ieee, s
case 7:
UP = 7;
break;
+ default:
+ netdev_warn(ieee->dev, "%s(): TID(%d) is not valid\n",
+ __func__, TID);
+ return false;
}
}
Patches currently in stable-queue which might be from tvboxspy@gmail.com are
queue-4.11/staging-rtl8192e-rtl92e_get_eeprom_size-fix-read-size-of-eprom_cmd.patch
queue-4.11/staging-rtl8192e-getts-fix-invalid-tid-7-warning.patch
queue-4.11/staging-rtl8192e-rtl92e_fill_tx_desc-fix-write-to-mapped-out-memory.patch
queue-4.11/staging-rtl8192e-fix-2-byte-alignment-of-register-bssidr.patch
^ permalink raw reply
* Patch "staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD." has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tvboxspy, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
staging-rtl8192e-rtl92e_get_eeprom_size-fix-read-size-of-eprom_cmd.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 90be652c9f157d44b9c2803f902a8839796c090d Mon Sep 17 00:00:00 2001
From: Malcolm Priestley <tvboxspy@gmail.com>
Date: Thu, 11 May 2017 18:57:45 +0100
Subject: staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.
From: Malcolm Priestley <tvboxspy@gmail.com>
commit 90be652c9f157d44b9c2803f902a8839796c090d upstream.
EPROM_CMD is 2 byte aligned on PCI map so calling with rtl92e_readl
will return invalid data so use rtl92e_readw.
The device is unable to select the right eeprom type.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -627,7 +627,7 @@ void rtl92e_get_eeprom_size(struct net_d
struct r8192_priv *priv = rtllib_priv(dev);
RT_TRACE(COMP_INIT, "===========>%s()\n", __func__);
- curCR = rtl92e_readl(dev, EPROM_CMD);
+ curCR = rtl92e_readw(dev, EPROM_CMD);
RT_TRACE(COMP_INIT, "read from Reg Cmd9346CR(%x):%x\n", EPROM_CMD,
curCR);
priv->epromtype = (curCR & EPROM_CMD_9356SEL) ? EEPROM_93C56 :
Patches currently in stable-queue which might be from tvboxspy@gmail.com are
queue-4.11/staging-rtl8192e-rtl92e_get_eeprom_size-fix-read-size-of-eprom_cmd.patch
queue-4.11/staging-rtl8192e-getts-fix-invalid-tid-7-warning.patch
queue-4.11/staging-rtl8192e-rtl92e_fill_tx_desc-fix-write-to-mapped-out-memory.patch
queue-4.11/staging-rtl8192e-fix-2-byte-alignment-of-register-bssidr.patch
^ permalink raw reply
* Patch "staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory." has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tvboxspy, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory.
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
staging-rtl8192e-rtl92e_fill_tx_desc-fix-write-to-mapped-out-memory.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From baabd567f87be05330faa5140f72a91960e7405a Mon Sep 17 00:00:00 2001
From: Malcolm Priestley <tvboxspy@gmail.com>
Date: Thu, 11 May 2017 18:57:43 +0100
Subject: staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory.
From: Malcolm Priestley <tvboxspy@gmail.com>
commit baabd567f87be05330faa5140f72a91960e7405a upstream.
The driver attempts to alter memory that is mapped to PCI device.
This is because tx_fwinfo_8190pci points to skb->data
Move the pci_map_single to when completed buffer is ready to be mapped with
psdec is empty to drop on mapping error.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -1184,8 +1184,7 @@ void rtl92e_fill_tx_desc(struct net_dev
struct cb_desc *cb_desc, struct sk_buff *skb)
{
struct r8192_priv *priv = rtllib_priv(dev);
- dma_addr_t mapping = pci_map_single(priv->pdev, skb->data, skb->len,
- PCI_DMA_TODEVICE);
+ dma_addr_t mapping;
struct tx_fwinfo_8190pci *pTxFwInfo;
pTxFwInfo = (struct tx_fwinfo_8190pci *)skb->data;
@@ -1196,8 +1195,6 @@ void rtl92e_fill_tx_desc(struct net_dev
pTxFwInfo->Short = _rtl92e_query_is_short(pTxFwInfo->TxHT,
pTxFwInfo->TxRate, cb_desc);
- if (pci_dma_mapping_error(priv->pdev, mapping))
- netdev_err(dev, "%s(): DMA Mapping error\n", __func__);
if (cb_desc->bAMPDUEnable) {
pTxFwInfo->AllowAggregation = 1;
pTxFwInfo->RxMF = cb_desc->ampdu_factor;
@@ -1232,6 +1229,14 @@ void rtl92e_fill_tx_desc(struct net_dev
}
memset((u8 *)pdesc, 0, 12);
+
+ mapping = pci_map_single(priv->pdev, skb->data, skb->len,
+ PCI_DMA_TODEVICE);
+ if (pci_dma_mapping_error(priv->pdev, mapping)) {
+ netdev_err(dev, "%s(): DMA Mapping error\n", __func__);
+ return;
+ }
+
pdesc->LINIP = 0;
pdesc->CmdInit = 1;
pdesc->Offset = sizeof(struct tx_fwinfo_8190pci) + 8;
Patches currently in stable-queue which might be from tvboxspy@gmail.com are
queue-4.11/staging-rtl8192e-rtl92e_get_eeprom_size-fix-read-size-of-eprom_cmd.patch
queue-4.11/staging-rtl8192e-getts-fix-invalid-tid-7-warning.patch
queue-4.11/staging-rtl8192e-rtl92e_fill_tx_desc-fix-write-to-mapped-out-memory.patch
queue-4.11/staging-rtl8192e-fix-2-byte-alignment-of-register-bssidr.patch
^ permalink raw reply
* Patch "powerpc/tm: Fix FP and VMX register corruption" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mikey, gregkh, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/tm: Fix FP and VMX register corruption
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-tm-fix-fp-and-vmx-register-corruption.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From f48e91e87e67b56bef63393d1a02c6e22c1d7078 Mon Sep 17 00:00:00 2001
From: Michael Neuling <mikey@neuling.org>
Date: Mon, 8 May 2017 17:16:26 +1000
Subject: powerpc/tm: Fix FP and VMX register corruption
From: Michael Neuling <mikey@neuling.org>
commit f48e91e87e67b56bef63393d1a02c6e22c1d7078 upstream.
In commit dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state
to store live registers"), a section of code was removed that copied
the current state to checkpointed state. That code should not have been
removed.
When an FP (Floating Point) unavailable is taken inside a transaction,
we need to abort the transaction. This is because at the time of the
tbegin, the FP state is bogus so the state stored in the checkpointed
registers is incorrect. To fix this, we treclaim (to get the
checkpointed GPRs) and then copy the thread_struct FP live state into
the checkpointed state. We then trecheckpoint so that the FP state is
correctly restored into the CPU.
The copying of the FP registers from live to checkpointed is what was
missing.
This simplifies the logic slightly from the original patch.
tm_reclaim_thread() will now always write the checkpointed FP
state. Either the checkpointed FP state will be written as part of
the actual treclaim (in tm.S), or it'll be a copy of the live
state. Which one we use is based on MSR[FP] from userspace.
Similarly for VMX.
Fixes: dc3106690b20 ("powerpc: tm: Always use fp_state and vr_state to store live registers")
Signed-off-by: Michael Neuling <mikey@neuling.org>
Reviewed-by: cyrilbur@gmail.com
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/process.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -864,6 +864,25 @@ static void tm_reclaim_thread(struct thr
if (!MSR_TM_SUSPENDED(mfmsr()))
return;
+ /*
+ * If we are in a transaction and FP is off then we can't have
+ * used FP inside that transaction. Hence the checkpointed
+ * state is the same as the live state. We need to copy the
+ * live state to the checkpointed state so that when the
+ * transaction is restored, the checkpointed state is correct
+ * and the aborted transaction sees the correct state. We use
+ * ckpt_regs.msr here as that's what tm_reclaim will use to
+ * determine if it's going to write the checkpointed state or
+ * not. So either this will write the checkpointed registers,
+ * or reclaim will. Similarly for VMX.
+ */
+ if ((thr->ckpt_regs.msr & MSR_FP) == 0)
+ memcpy(&thr->ckfp_state, &thr->fp_state,
+ sizeof(struct thread_fp_state));
+ if ((thr->ckpt_regs.msr & MSR_VEC) == 0)
+ memcpy(&thr->ckvr_state, &thr->vr_state,
+ sizeof(struct thread_vr_state));
+
giveup_all(container_of(thr, struct task_struct, thread));
tm_reclaim(thr, thr->ckpt_regs.msr, cause);
Patches currently in stable-queue which might be from mikey@neuling.org are
queue-4.11/powerpc-tm-fix-fp-and-vmx-register-corruption.patch
^ permalink raw reply
* Patch "staging: rtl8192e: fix 2 byte alignment of register BSSIDR." has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tvboxspy, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
staging-rtl8192e-fix-2-byte-alignment-of-register-bssidr.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 867510bde14e7b7fc6dd0f50b48f6753cfbd227a Mon Sep 17 00:00:00 2001
From: Malcolm Priestley <tvboxspy@gmail.com>
Date: Thu, 11 May 2017 18:57:44 +0100
Subject: staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
From: Malcolm Priestley <tvboxspy@gmail.com>
commit 867510bde14e7b7fc6dd0f50b48f6753cfbd227a upstream.
BSSIDR has two byte alignment on PCI ioremap correct the write
by swapping to 16 bits first.
This fixes a problem that the device associates fail because
the filter is not set correctly.
Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
@@ -97,8 +97,9 @@ void rtl92e_set_reg(struct net_device *d
switch (variable) {
case HW_VAR_BSSID:
- rtl92e_writel(dev, BSSIDR, ((u32 *)(val))[0]);
- rtl92e_writew(dev, BSSIDR+2, ((u16 *)(val+2))[0]);
+ /* BSSIDR 2 byte alignment */
+ rtl92e_writew(dev, BSSIDR, *(u16 *)val);
+ rtl92e_writel(dev, BSSIDR + 2, *(u32 *)(val + 2));
break;
case HW_VAR_MEDIA_STATUS:
@@ -963,8 +964,8 @@ static void _rtl92e_net_update(struct ne
rtl92e_config_rate(dev, &rate_config);
priv->dot11CurrentPreambleMode = PREAMBLE_AUTO;
priv->basic_rate = rate_config &= 0x15f;
- rtl92e_writel(dev, BSSIDR, ((u32 *)net->bssid)[0]);
- rtl92e_writew(dev, BSSIDR+4, ((u16 *)net->bssid)[2]);
+ rtl92e_writew(dev, BSSIDR, *(u16 *)net->bssid);
+ rtl92e_writel(dev, BSSIDR + 2, *(u32 *)(net->bssid + 2));
if (priv->rtllib->iw_mode == IW_MODE_ADHOC) {
rtl92e_writew(dev, ATIMWND, 2);
Patches currently in stable-queue which might be from tvboxspy@gmail.com are
queue-4.11/staging-rtl8192e-rtl92e_get_eeprom_size-fix-read-size-of-eprom_cmd.patch
queue-4.11/staging-rtl8192e-getts-fix-invalid-tid-7-warning.patch
queue-4.11/staging-rtl8192e-rtl92e_fill_tx_desc-fix-write-to-mapped-out-memory.patch
queue-4.11/staging-rtl8192e-fix-2-byte-alignment-of-register-bssidr.patch
^ permalink raw reply
* Patch "stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: danielmicay, arjan, gregkh, keescook, mingo, peterz, riel, tglx,
torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 Mon Sep 17 00:00:00 2001
From: Daniel Micay <danielmicay@gmail.com>
Date: Thu, 4 May 2017 09:32:09 -0400
Subject: stackprotector: Increase the per-task stack canary's random range from 32 bits to 64 bits on 64-bit platforms
From: Daniel Micay <danielmicay@gmail.com>
commit 5ea30e4e58040cfd6434c2f33dc3ea76e2c15b05 upstream.
The stack canary is an 'unsigned long' and should be fully initialized to
random data rather than only 32 bits of random data.
Signed-off-by: Daniel Micay <danielmicay@gmail.com>
Acked-by: Arjan van de Ven <arjan@linux.intel.com>
Acked-by: Rik van Riel <riel@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Arjan van Ven <arjan@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-hardening@lists.openwall.com
Link: http://lkml.kernel.org/r/20170504133209.3053-1-danielmicay@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/fork.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -536,7 +536,7 @@ static struct task_struct *dup_task_stru
set_task_stack_end_magic(tsk);
#ifdef CONFIG_CC_STACKPROTECTOR
- tsk->stack_canary = get_random_int();
+ tsk->stack_canary = get_random_long();
#endif
/*
Patches currently in stable-queue which might be from danielmicay@gmail.com are
queue-4.11/stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
^ permalink raw reply
* Patch "powerpc/sysfs: Fix reference leak of cpu device_nodes present at boot" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tyreld, gregkh, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/sysfs: Fix reference leak of cpu device_nodes present at boot
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-sysfs-fix-reference-leak-of-cpu-device_nodes-present-at-boot.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From e76ca27790a514590af782f83f6eae49e0ccf8c9 Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date: Mon, 17 Apr 2017 20:24:39 -0400
Subject: powerpc/sysfs: Fix reference leak of cpu device_nodes present at boot
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
commit e76ca27790a514590af782f83f6eae49e0ccf8c9 upstream.
For CPUs present at boot each logical CPU acquires a reference to the
associated device node of the core. This happens in register_cpu() which
is called by topology_init(). The result of this is that we end up with
a reference held by each thread of the core. However, these references
are never freed if the CPU core is DLPAR removed.
This patch fixes the reference leaks by acquiring and releasing the references
in the CPU hotplug callbacks un/register_cpu_online(). With this patch symmetric
reference counting is observed with both CPUs present at boot, and those DLPAR
added after boot.
Fixes: f86e4718f24b ("driver/core: cpu: initialize of_node in cpu's device struture")
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/sysfs.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -710,6 +710,10 @@ static int register_cpu_online(unsigned
struct device_attribute *attrs, *pmc_attrs;
int i, nattrs;
+ /* For cpus present at boot a reference was already grabbed in register_cpu() */
+ if (!s->of_node)
+ s->of_node = of_get_cpu_node(cpu, NULL);
+
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SMT))
device_create_file(s, &dev_attr_smt_snooze_delay);
@@ -864,6 +868,8 @@ static int unregister_cpu_online(unsigne
}
#endif
cacheinfo_cpu_offline(cpu);
+ of_node_put(s->of_node);
+ s->of_node = NULL;
#endif /* CONFIG_HOTPLUG_CPU */
return 0;
}
Patches currently in stable-queue which might be from tyreld@linux.vnet.ibm.com are
queue-4.11/powerpc-sysfs-fix-reference-leak-of-cpu-device_nodes-present-at-boot.patch
queue-4.11/of-fix-cpus-reference-leak-in-of_numa_parse_cpu_nodes.patch
queue-4.11/powerpc-pseries-fix-of_node_put-underflow-during-dlpar-remove.patch
^ permalink raw reply
* Patch "powerpc/powernv: Fix TCE kill on NVLink2" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: alistair, gregkh, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/powernv: Fix TCE kill on NVLink2
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-powernv-fix-tce-kill-on-nvlink2.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 6b3d12a948d27977816a15eb48409a298902a548 Mon Sep 17 00:00:00 2001
From: Alistair Popple <alistair@popple.id.au>
Date: Wed, 3 May 2017 13:24:08 +1000
Subject: powerpc/powernv: Fix TCE kill on NVLink2
From: Alistair Popple <alistair@popple.id.au>
commit 6b3d12a948d27977816a15eb48409a298902a548 upstream.
Commit 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on
NVLink2") forced all TCE kills to go via the OPAL call for
NVLink2. However the PHB3 implementation of TCE kill was still being
called directly from some functions which in some circumstances caused
a machine check.
This patch adds an equivalent IODA2 version of the function which uses
the correct invalidation method depending on PHB model and changes all
external callers to use it instead.
Fixes: 616badd2fb49 ("powerpc/powernv: Use OPAL call for TCE kill on NVLink2")
Signed-off-by: Alistair Popple <alistair@popple.id.au>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/powernv/npu-dma.c | 8 ++++----
arch/powerpc/platforms/powernv/pci-ioda.c | 10 +++++++++-
arch/powerpc/platforms/powernv/pci.h | 2 +-
3 files changed, 14 insertions(+), 6 deletions(-)
--- a/arch/powerpc/platforms/powernv/npu-dma.c
+++ b/arch/powerpc/platforms/powernv/npu-dma.c
@@ -180,7 +180,7 @@ long pnv_npu_set_window(struct pnv_ioda_
pe_err(npe, "Failed to configure TCE table, err %lld\n", rc);
return rc;
}
- pnv_pci_phb3_tce_invalidate_entire(phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
/* Add the table to the list so its TCE cache will get invalidated */
pnv_pci_link_table_and_group(phb->hose->node, num,
@@ -204,7 +204,7 @@ long pnv_npu_unset_window(struct pnv_iod
pe_err(npe, "Unmapping failed, ret = %lld\n", rc);
return rc;
}
- pnv_pci_phb3_tce_invalidate_entire(phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
pnv_pci_unlink_table_and_group(npe->table_group.tables[num],
&npe->table_group);
@@ -270,7 +270,7 @@ static int pnv_npu_dma_set_bypass(struct
0 /* bypass base */, top);
if (rc == OPAL_SUCCESS)
- pnv_pci_phb3_tce_invalidate_entire(phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(phb, false);
return rc;
}
@@ -334,7 +334,7 @@ void pnv_npu_take_ownership(struct pnv_i
pe_err(npe, "Failed to disable bypass, err %lld\n", rc);
return;
}
- pnv_pci_phb3_tce_invalidate_entire(npe->phb, false);
+ pnv_pci_ioda2_tce_invalidate_entire(npe->phb, false);
}
struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe)
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1883,7 +1883,7 @@ static struct iommu_table_ops pnv_ioda1_
#define PHB3_TCE_KILL_INVAL_PE PPC_BIT(1)
#define PHB3_TCE_KILL_INVAL_ONE PPC_BIT(2)
-void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+static void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
{
__be64 __iomem *invalidate = pnv_ioda_get_inval_reg(phb, rm);
const unsigned long val = PHB3_TCE_KILL_INVAL_ALL;
@@ -1979,6 +1979,14 @@ static void pnv_pci_ioda2_tce_invalidate
}
}
+void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm)
+{
+ if (phb->model == PNV_PHB_MODEL_NPU || phb->model == PNV_PHB_MODEL_PHB3)
+ pnv_pci_phb3_tce_invalidate_entire(phb, rm);
+ else
+ opal_pci_tce_kill(phb->opal_id, OPAL_PCI_TCE_KILL, 0, 0, 0, 0);
+}
+
static int pnv_ioda2_tce_build(struct iommu_table *tbl, long index,
long npages, unsigned long uaddr,
enum dma_data_direction direction,
--- a/arch/powerpc/platforms/powernv/pci.h
+++ b/arch/powerpc/platforms/powernv/pci.h
@@ -229,7 +229,7 @@ extern void pe_level_printk(const struct
/* Nvlink functions */
extern void pnv_npu_try_dma_set_bypass(struct pci_dev *gpdev, bool bypass);
-extern void pnv_pci_phb3_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
+extern void pnv_pci_ioda2_tce_invalidate_entire(struct pnv_phb *phb, bool rm);
extern struct pnv_ioda_pe *pnv_pci_npu_setup_iommu(struct pnv_ioda_pe *npe);
extern long pnv_npu_set_window(struct pnv_ioda_pe *npe, int num,
struct iommu_table *tbl);
Patches currently in stable-queue which might be from alistair@popple.id.au are
queue-4.11/powerpc-powernv-fix-tce-kill-on-nvlink2.patch
^ permalink raw reply
* Patch "powerpc/pseries: Fix of_node_put() underflow during DLPAR remove" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: tyreld; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/pseries: Fix of_node_put() underflow during DLPAR remove
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-pseries-fix-of_node_put-underflow-during-dlpar-remove.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 68baf692c435339e6295cb470ea5545cbc28160e Mon Sep 17 00:00:00 2001
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
Date: Mon, 17 Apr 2017 20:21:40 -0400
Subject: powerpc/pseries: Fix of_node_put() underflow during DLPAR remove
From: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
commit 68baf692c435339e6295cb470ea5545cbc28160e upstream.
Historically struct device_node references were tracked using a kref embedded as
a struct field. Commit 75b57ecf9d1d ("of: Make device nodes kobjects so they
show up in sysfs") (Mar 2014) refactored device_nodes to be kobjects such that
the device tree could by more simply exposed to userspace using sysfs.
Commit 0829f6d1f69e ("of: device_node kobject lifecycle fixes") (Mar 2014)
followed up these changes to better control the kobject lifecycle and in
particular the referecne counting via of_node_get(), of_node_put(), and
of_node_init().
A result of this second commit was that it introduced an of_node_put() call when
a dynamic node is detached, in of_node_remove(), that removes the initial kobj
reference created by of_node_init().
Traditionally as the original dynamic device node user the pseries code had
assumed responsibilty for releasing this final reference in its platform
specific DLPAR detach code.
This patch fixes a refcount underflow introduced by commit 0829f6d1f6, and
recently exposed by the upstreaming of the recount API.
Messages like the following are no longer seen in the kernel log with this
patch following DLPAR remove operations of cpus and pci devices.
rpadlpar_io: slot PHB 72 removed
refcount_t: underflow; use-after-free.
------------[ cut here ]------------
WARNING: CPU: 5 PID: 3335 at lib/refcount.c:128 refcount_sub_and_test+0xf4/0x110
Fixes: 0829f6d1f69e ("of: device_node kobject lifecycle fixes")
Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
[mpe: Make change log commit references more verbose]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/platforms/pseries/dlpar.c | 1 -
1 file changed, 1 deletion(-)
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -288,7 +288,6 @@ int dlpar_detach_node(struct device_node
if (rc)
return rc;
- of_node_put(dn); /* Must decrement the refcount */
return 0;
}
Patches currently in stable-queue which might be from tyreld@linux.vnet.ibm.com are
queue-4.11/powerpc-sysfs-fix-reference-leak-of-cpu-device_nodes-present-at-boot.patch
queue-4.11/of-fix-cpus-reference-leak-in-of_numa_parse_cpu_nodes.patch
queue-4.11/powerpc-pseries-fix-of_node_put-underflow-during-dlpar-remove.patch
^ permalink raw reply
* Patch "powerpc/mm: Ensure IRQs are off in switch_mm()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: david, gregkh, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/mm: Ensure IRQs are off in switch_mm()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-mm-ensure-irqs-are-off-in-switch_mm.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 9765ad134a00a01cbcc69c78ff6defbfad209bc5 Mon Sep 17 00:00:00 2001
From: David Gibson <david@gibson.dropbear.id.au>
Date: Wed, 19 Apr 2017 16:38:26 +1000
Subject: powerpc/mm: Ensure IRQs are off in switch_mm()
From: David Gibson <david@gibson.dropbear.id.au>
commit 9765ad134a00a01cbcc69c78ff6defbfad209bc5 upstream.
powerpc expects IRQs to already be (soft) disabled when switch_mm() is
called, as made clear in the commit message of 9c1e105238c4 ("powerpc: Allow
perf_counters to access user memory at interrupt time").
Aside from any race conditions that might exist between switch_mm() and an IRQ,
there is also an unconditional hard_irq_disable() in switch_slb(). If that isn't
followed at some point by an IRQ enable then interrupts will remain disabled
until we return to userspace.
It is true that when switch_mm() is called from the scheduler IRQs are off, but
not when it's called by use_mm(). Looking closer we see that last year in commit
f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler")
this was made more explicit by the addition of switch_mm_irqs_off() which is now
called by the scheduler, vs switch_mm() which is used by use_mm().
Arguably it is a bug in use_mm() to call switch_mm() in a different context than
it expects, but fixing that will take time.
This was discovered recently when vhost started throwing warnings such as:
BUG: sleeping function called from invalid context at kernel/mutex.c:578
in_atomic(): 0, irqs_disabled(): 1, pid: 10768, name: vhost-10760
no locks held by vhost-10760/10768.
irq event stamp: 10
hardirqs last enabled at (9): _raw_spin_unlock_irq+0x40/0x80
hardirqs last disabled at (10): switch_slb+0x2e4/0x490
softirqs last enabled at (0): copy_process+0x5e8/0x1260
softirqs last disabled at (0): (null)
Call Trace:
show_stack+0x88/0x390 (unreliable)
dump_stack+0x30/0x44
__might_sleep+0x1c4/0x2d0
mutex_lock_nested+0x74/0x5c0
cgroup_attach_task_all+0x5c/0x180
vhost_attach_cgroups_work+0x58/0x80 [vhost]
vhost_worker+0x24c/0x3d0 [vhost]
kthread+0xec/0x100
ret_from_kernel_thread+0x5c/0xd4
Prior to commit 04b96e5528ca ("vhost: lockless enqueuing") (Aug 2016) the
vhost_worker() would do a spin_unlock_irq() not long after calling use_mm(),
which had the effect of reenabling IRQs. Since that commit removed the locking
in vhost_worker() the body of the vhost_worker() loop now runs with interrupts
off causing the warnings.
This patch addresses the problem by making the powerpc code mirror the x86 code,
ie. we disable interrupts in switch_mm(), and optimise the scheduler case by
defining switch_mm_irqs_off().
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[mpe: Flesh out/rewrite change log, add stable]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/mmu_context.h | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -70,8 +70,9 @@ extern void drop_cop(unsigned long acop,
* switch_mm is the entry point called from the architecture independent
* code in kernel/sched/core.c
*/
-static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
- struct task_struct *tsk)
+static inline void switch_mm_irqs_off(struct mm_struct *prev,
+ struct mm_struct *next,
+ struct task_struct *tsk)
{
/* Mark this context has been used on the new CPU */
if (!cpumask_test_cpu(smp_processor_id(), mm_cpumask(next)))
@@ -110,6 +111,18 @@ static inline void switch_mm(struct mm_s
switch_mmu_context(prev, next, tsk);
}
+static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
+ struct task_struct *tsk)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ switch_mm_irqs_off(prev, next, tsk);
+ local_irq_restore(flags);
+}
+#define switch_mm_irqs_off switch_mm_irqs_off
+
+
#define deactivate_mm(tsk,mm) do { } while (0)
/*
Patches currently in stable-queue which might be from david@gibson.dropbear.id.au are
queue-4.11/powerpc-mm-ensure-irqs-are-off-in-switch_mm.patch
^ permalink raw reply
* Patch "powerpc/mm: Fix crash in page table dump with huge pages" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mpe, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/mm: Fix crash in page table dump with huge pages
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-mm-fix-crash-in-page-table-dump-with-huge-pages.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From bfb9956ab4d8242f4594b5f4bee534b935384fd9 Mon Sep 17 00:00:00 2001
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Tue, 16 May 2017 20:42:53 +1000
Subject: powerpc/mm: Fix crash in page table dump with huge pages
From: Michael Ellerman <mpe@ellerman.id.au>
commit bfb9956ab4d8242f4594b5f4bee534b935384fd9 upstream.
The page table dump code doesn't know about huge pages, so currently
it crashes (or walks random memory, usually leading to a crash), if it
finds a huge page. On Book3S we only see huge pages in the Linux page
tables when we're using the P9 Radix MMU.
Teaching the code to properly handle huge pages is a bit more involved,
so for now just prevent the crash.
Fixes: 8eb07b187000 ("powerpc/mm: Dump linux pagetables")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/mm/dump_linuxpagetables.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/arch/powerpc/mm/dump_linuxpagetables.c
+++ b/arch/powerpc/mm/dump_linuxpagetables.c
@@ -16,6 +16,7 @@
*/
#include <linux/debugfs.h>
#include <linux/fs.h>
+#include <linux/hugetlb.h>
#include <linux/io.h>
#include <linux/mm.h>
#include <linux/sched.h>
@@ -331,7 +332,7 @@ static void walk_pmd(struct pg_state *st
for (i = 0; i < PTRS_PER_PMD; i++, pmd++) {
addr = start + i * PMD_SIZE;
- if (!pmd_none(*pmd))
+ if (!pmd_none(*pmd) && !pmd_huge(*pmd))
/* pmd exists */
walk_pte(st, pmd, addr);
else
@@ -347,7 +348,7 @@ static void walk_pud(struct pg_state *st
for (i = 0; i < PTRS_PER_PUD; i++, pud++) {
addr = start + i * PUD_SIZE;
- if (!pud_none(*pud))
+ if (!pud_none(*pud) && !pud_huge(*pud))
/* pud exists */
walk_pmd(st, pud, addr);
else
@@ -367,7 +368,7 @@ static void walk_pagetables(struct pg_st
*/
for (i = 0; i < PTRS_PER_PGD; i++, pgd++) {
addr = KERN_VIRT_START + i * PGDIR_SIZE;
- if (!pgd_none(*pgd))
+ if (!pgd_none(*pgd) && !pgd_huge(*pgd))
/* pgd exists */
walk_pud(st, pgd, addr);
else
Patches currently in stable-queue which might be from mpe@ellerman.id.au are
queue-4.11/powerpc-book3s-mce-move-add_taint-later-in-virtual-mode.patch
queue-4.11/powerpc-mm-fix-crash-in-page-table-dump-with-huge-pages.patch
queue-4.11/powerpc-tm-fix-fp-and-vmx-register-corruption.patch
queue-4.11/powerpc-sysfs-fix-reference-leak-of-cpu-device_nodes-present-at-boot.patch
queue-4.11/powerpc-powernv-fix-tce-kill-on-nvlink2.patch
queue-4.11/cxl-force-context-lock-during-eeh-flow.patch
queue-4.11/cxl-route-eeh-events-to-all-drivers-in-cxl_pci_error_detected.patch
queue-4.11/powerpc-pseries-fix-of_node_put-underflow-during-dlpar-remove.patch
queue-4.11/powerpc-iommu-do-not-call-pagetranshuge-on-tail-pages.patch
queue-4.11/powerpc-mm-ensure-irqs-are-off-in-switch_mm.patch
queue-4.11/powerpc-eeh-avoid-use-after-free-in-eeh_handle_special_event.patch
^ permalink raw reply
* Patch "powerpc/iommu: Do not call PageTransHuge() on tail pages" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: aik, bsingharora, gregkh, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/iommu: Do not call PageTransHuge() on tail pages
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-iommu-do-not-call-pagetranshuge-on-tail-pages.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From e889e96e98e8da97bd39e46b7253615eabe14397 Mon Sep 17 00:00:00 2001
From: Alexey Kardashevskiy <aik@ozlabs.ru>
Date: Tue, 11 Apr 2017 17:54:57 +1000
Subject: powerpc/iommu: Do not call PageTransHuge() on tail pages
From: Alexey Kardashevskiy <aik@ozlabs.ru>
commit e889e96e98e8da97bd39e46b7253615eabe14397 upstream.
The CMA pages migration code does not support compound pages at
the moment so it performs few tests before proceeding to actual page
migration.
One of the tests - PageTransHuge() - has VM_BUG_ON_PAGE(PageTail()) as
it is designed to be called on head pages only. Since we also test for
PageCompound(), and it contains PageTail() and PageHead(), we can
simplify the check by leaving just PageCompound() and therefore avoid
possible VM_BUG_ON_PAGE.
Fixes: 2e5bbb5461f1 ("KVM: PPC: Book3S HV: Migrate pinned pages out of CMA")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/mm/mmu_context_iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/mm/mmu_context_iommu.c
+++ b/arch/powerpc/mm/mmu_context_iommu.c
@@ -81,7 +81,7 @@ struct page *new_iommu_non_cma_page(stru
gfp_t gfp_mask = GFP_USER;
struct page *new_page;
- if (PageHuge(page) || PageTransHuge(page) || PageCompound(page))
+ if (PageCompound(page))
return NULL;
if (PageHighMem(page))
@@ -100,7 +100,7 @@ static int mm_iommu_move_page_from_cma(s
LIST_HEAD(cma_migrate_pages);
/* Ignore huge pages for now */
- if (PageHuge(page) || PageTransHuge(page) || PageCompound(page))
+ if (PageCompound(page))
return -EBUSY;
lru_add_drain();
Patches currently in stable-queue which might be from aik@ozlabs.ru are
queue-4.11/powerpc-iommu-do-not-call-pagetranshuge-on-tail-pages.patch
queue-4.11/powerpc-eeh-avoid-use-after-free-in-eeh_handle_special_event.patch
^ permalink raw reply
* Patch "powerpc/eeh: Avoid use after free in eeh_handle_special_event()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: ruscur, aik, gregkh, gwshan, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/eeh: Avoid use after free in eeh_handle_special_event()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-eeh-avoid-use-after-free-in-eeh_handle_special_event.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From daeba2956f32f91f3493788ff6ee02fb1b2f02fa Mon Sep 17 00:00:00 2001
From: Russell Currey <ruscur@russell.cc>
Date: Wed, 19 Apr 2017 17:39:26 +1000
Subject: powerpc/eeh: Avoid use after free in eeh_handle_special_event()
From: Russell Currey <ruscur@russell.cc>
commit daeba2956f32f91f3493788ff6ee02fb1b2f02fa upstream.
eeh_handle_special_event() is called when an EEH event is detected but
can't be narrowed down to a specific PE. This function looks through
every PE to find one in an erroneous state, then calls the regular event
handler eeh_handle_normal_event() once it knows which PE has an error.
However, if eeh_handle_normal_event() found that the PE cannot possibly
be recovered, it will free it, rendering the passed PE stale.
This leads to a use after free in eeh_handle_special_event() as it attempts to
clear the "recovering" state on the PE after eeh_handle_normal_event() returns.
Thus, make sure the PE is valid when attempting to clear state in
eeh_handle_special_event().
Fixes: 8a6b1bc70dbb ("powerpc/eeh: EEH core to handle special event")
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Russell Currey <ruscur@russell.cc>
Reviewed-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/eeh_driver.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
--- a/arch/powerpc/kernel/eeh_driver.c
+++ b/arch/powerpc/kernel/eeh_driver.c
@@ -724,7 +724,7 @@ static int eeh_reset_device(struct eeh_p
*/
#define MAX_WAIT_FOR_RECOVERY 300
-static void eeh_handle_normal_event(struct eeh_pe *pe)
+static bool eeh_handle_normal_event(struct eeh_pe *pe)
{
struct pci_bus *frozen_bus;
struct eeh_dev *edev, *tmp;
@@ -736,7 +736,7 @@ static void eeh_handle_normal_event(stru
if (!frozen_bus) {
pr_err("%s: Cannot find PCI bus for PHB#%x-PE#%x\n",
__func__, pe->phb->global_number, pe->addr);
- return;
+ return false;
}
eeh_pe_update_time_stamp(pe);
@@ -870,7 +870,7 @@ static void eeh_handle_normal_event(stru
pr_info("EEH: Notify device driver to resume\n");
eeh_pe_dev_traverse(pe, eeh_report_resume, NULL);
- return;
+ return false;
excess_failures:
/*
@@ -915,8 +915,12 @@ perm_error:
pci_lock_rescan_remove();
pci_hp_remove_devices(frozen_bus);
pci_unlock_rescan_remove();
+
+ /* The passed PE should no longer be used */
+ return true;
}
}
+ return false;
}
static void eeh_handle_special_event(void)
@@ -982,7 +986,14 @@ static void eeh_handle_special_event(voi
*/
if (rc == EEH_NEXT_ERR_FROZEN_PE ||
rc == EEH_NEXT_ERR_FENCED_PHB) {
- eeh_handle_normal_event(pe);
+ /*
+ * eeh_handle_normal_event() can make the PE stale if it
+ * determines that the PE cannot possibly be recovered.
+ * Don't modify the PE state if that's the case.
+ */
+ if (eeh_handle_normal_event(pe))
+ continue;
+
eeh_pe_state_clear(pe, EEH_PE_RECOVERING);
} else {
pci_lock_rescan_remove();
Patches currently in stable-queue which might be from ruscur@russell.cc are
queue-4.11/powerpc-eeh-avoid-use-after-free-in-eeh_handle_special_event.patch
^ permalink raw reply
* Patch "powerpc/64e: Fix hang when debugging programs with relocated kernel" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: liu.hailong6, gregkh, huang.jian, jiang.biao2, jiang.xuexin,
liu.song11, oss
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/64e: Fix hang when debugging programs with relocated kernel
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-64e-fix-hang-when-debugging-programs-with-relocated-kernel.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From fd615f69a18a9d4aa5ef02a1dc83f319f75da8e7 Mon Sep 17 00:00:00 2001
From: LiuHailong <liu.hailong6@zte.com.cn>
Date: Tue, 7 Feb 2017 10:35:52 +0800
Subject: powerpc/64e: Fix hang when debugging programs with relocated kernel
From: LiuHailong <liu.hailong6@zte.com.cn>
commit fd615f69a18a9d4aa5ef02a1dc83f319f75da8e7 upstream.
Debug interrupts can be taken during interrupt entry, since interrupt
entry does not automatically turn them off. The kernel will check
whether the faulting instruction is between [interrupt_base_book3e,
__end_interrupts], and if so clear MSR[DE] and return.
However, when the kernel is built with CONFIG_RELOCATABLE, it can't use
LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e) and
LOAD_REG_IMMEDIATE(r15,__end_interrupts), as they ignore relocation.
Thus, if the kernel is actually running at a different address than it
was built at, the address comparison will fail, and the exception entry
code will hang at kernel_dbg_exc.
r2(toc) is also not usable here, as r2 still holds data from the
interrupted context, so LOAD_REG_ADDR() doesn't work either. So we use
the *name@got* to get the EV of two labels directly.
Test programs test.c shows as follows:
int main(int argc, char *argv[])
{
if (access("/proc/sys/kernel/perf_event_paranoid", F_OK) == -1)
printf("Kernel doesn't have perf_event support\n");
}
Steps to reproduce the bug, for example:
1) ./gdb ./test
2) (gdb) b access
3) (gdb) r
4) (gdb) s
Signed-off-by: Liu Hailong <liu.hailong6@zte.com.cn>
Signed-off-by: Jiang Xuexin <jiang.xuexin@zte.com.cn>
Reviewed-by: Jiang Biao <jiang.biao2@zte.com.cn>
Reviewed-by: Liu Song <liu.song11@zte.com.cn>
Reviewed-by: Huang Jian <huang.jian@zte.com.cn>
[scottwood: cleaned up commit message, and specified bad behavior
as a hang rather than an oops to correspond to mainline kernel behavior]
Fixes: 1cb6e0649248 ("powerpc/book3e: support CONFIG_RELOCATABLE")
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/exceptions-64e.S | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/powerpc/kernel/exceptions-64e.S
+++ b/arch/powerpc/kernel/exceptions-64e.S
@@ -735,8 +735,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
andis. r15,r14,(DBSR_IC|DBSR_BT)@h
beq+ 1f
+#ifdef CONFIG_RELOCATABLE
+ ld r15,PACATOC(r13)
+ ld r14,interrupt_base_book3e@got(r15)
+ ld r15,__end_interrupts@got(r15)
+#else
LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
LOAD_REG_IMMEDIATE(r15,__end_interrupts)
+#endif
cmpld cr0,r10,r14
cmpld cr1,r10,r15
blt+ cr0,1f
@@ -799,8 +805,14 @@ kernel_dbg_exc:
andis. r15,r14,(DBSR_IC|DBSR_BT)@h
beq+ 1f
+#ifdef CONFIG_RELOCATABLE
+ ld r15,PACATOC(r13)
+ ld r14,interrupt_base_book3e@got(r15)
+ ld r15,__end_interrupts@got(r15)
+#else
LOAD_REG_IMMEDIATE(r14,interrupt_base_book3e)
LOAD_REG_IMMEDIATE(r15,__end_interrupts)
+#endif
cmpld cr0,r10,r14
cmpld cr1,r10,r15
blt+ cr0,1f
Patches currently in stable-queue which might be from liu.hailong6@zte.com.cn are
queue-4.11/powerpc-64e-fix-hang-when-debugging-programs-with-relocated-kernel.patch
^ permalink raw reply
* Patch "powerpc/book3s/mce: Move add_taint() later in virtual mode" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: mahesh, gregkh, mpe; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
powerpc/book3s/mce: Move add_taint() later in virtual mode
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
powerpc-book3s-mce-move-add_taint-later-in-virtual-mode.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From d93b0ac01a9ce276ec39644be47001873d3d183c Mon Sep 17 00:00:00 2001
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Date: Tue, 18 Apr 2017 22:08:17 +0530
Subject: powerpc/book3s/mce: Move add_taint() later in virtual mode
From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
commit d93b0ac01a9ce276ec39644be47001873d3d183c upstream.
machine_check_early() gets called in real mode. The very first time when
add_taint() is called, it prints a warning which ends up calling opal
call (that uses OPAL_CALL wrapper) for writing it to console. If we get a
very first machine check while we are in opal we are doomed. OPAL_CALL
overwrites the PACASAVEDMSR in r13 and in this case when we are done with
MCE handling the original opal call will use this new MSR on it's way
back to opal_return. This usually leads to unexpected behaviour or the
kernel to panic. Instead move the add_taint() call later in the virtual
mode where it is safe to call.
This is broken with current FW level. We got lucky so far for not getting
very first MCE hit while in OPAL. But easily reproducible on Mambo.
Fixes: 27ea2c420cad ("powerpc: Set the correct kernel taint on machine check errors.")
Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/mce.c | 2 ++
arch/powerpc/kernel/traps.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -221,6 +221,8 @@ static void machine_check_process_queued
{
int index;
+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
+
/*
* For now just print it to console.
* TODO: log this error event to FSP or nvram.
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -306,8 +306,6 @@ long machine_check_early(struct pt_regs
__this_cpu_inc(irq_stat.mce_exceptions);
- add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
-
if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
handled = cur_cpu_spec->machine_check_early(regs);
return handled;
@@ -741,6 +739,8 @@ void machine_check_exception(struct pt_r
__this_cpu_inc(irq_stat.mce_exceptions);
+ add_taint(TAINT_MACHINE_CHECK, LOCKDEP_NOW_UNRELIABLE);
+
/* See if any machine dependent calls. In theory, we would want
* to call the CPU first, and call the ppc_md. one if the CPU
* one returns a positive number. However there is existing code
Patches currently in stable-queue which might be from mahesh@linux.vnet.ibm.com are
queue-4.11/powerpc-book3s-mce-move-add_taint-later-in-virtual-mode.patch
^ permalink raw reply
* Patch "MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: chenhc, Steven.Hill, gregkh, john, ralf, wuzhangjin, zhangfx
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-loongson-3-select-mips_l1_cache_shift_6.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 17c99d9421695a0e0de18bf1e7091d859e20ec1d Mon Sep 17 00:00:00 2001
From: Huacai Chen <chenhc@lemote.com>
Date: Thu, 16 Mar 2017 21:00:28 +0800
Subject: MIPS: Loongson-3: Select MIPS_L1_CACHE_SHIFT_6
From: Huacai Chen <chenhc@lemote.com>
commit 17c99d9421695a0e0de18bf1e7091d859e20ec1d upstream.
Some newer Loongson-3 have 64 bytes cache lines, so select
MIPS_L1_CACHE_SHIFT_6.
Signed-off-by: Huacai Chen <chenhc@lemote.com>
Cc: John Crispin <john@phrozen.org>
Cc: Steven J . Hill <Steven.Hill@caviumnetworks.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15755/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1373,6 +1373,7 @@ config CPU_LOONGSON3
select WEAK_ORDERING
select WEAK_REORDERING_BEYOND_LLSC
select MIPS_PGD_C0_CONTEXT
+ select MIPS_L1_CACHE_SHIFT_6
select GPIOLIB
help
The Loongson 3 processor implements the MIPS64R2 instruction
Patches currently in stable-queue which might be from chenhc@lemote.com are
queue-4.11/mips-loongson-3-select-mips_l1_cache_shift_6.patch
^ permalink raw reply
* Patch "nvme: unmap CMB and remove sysfs file in reset path" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: jonathan.derrick, axboe, gregkh, hch, keith.busch, sbates
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
nvme: unmap CMB and remove sysfs file in reset path
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
nvme-unmap-cmb-and-remove-sysfs-file-in-reset-path.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From f63572dff1421b6ca6abce71d46e03411e605c94 Mon Sep 17 00:00:00 2001
From: Jon Derrick <jonathan.derrick@intel.com>
Date: Fri, 5 May 2017 14:52:06 -0600
Subject: nvme: unmap CMB and remove sysfs file in reset path
From: Jon Derrick <jonathan.derrick@intel.com>
commit f63572dff1421b6ca6abce71d46e03411e605c94 upstream.
CMB doesn't get unmapped until removal while getting remapped on every
reset. Add the unmapping and sysfs file removal to the reset path in
nvme_pci_disable to match the mapping path in nvme_pci_enable.
Fixes: 202021c1a ("nvme : Add sysfs entry for NVMe CMBs when appropriate")
Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
Acked-by: Keith Busch <keith.busch@intel.com>
Reviewed-By: Stephen Bates <sbates@raithlin.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvme/host/pci.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -1394,6 +1394,11 @@ static inline void nvme_release_cmb(stru
if (dev->cmb) {
iounmap(dev->cmb);
dev->cmb = NULL;
+ if (dev->cmbsz) {
+ sysfs_remove_file_from_group(&dev->ctrl.device->kobj,
+ &dev_attr_cmb.attr, NULL);
+ dev->cmbsz = 0;
+ }
}
}
@@ -1665,6 +1670,7 @@ static void nvme_pci_disable(struct nvme
{
struct pci_dev *pdev = to_pci_dev(dev->dev);
+ nvme_release_cmb(dev);
pci_free_irq_vectors(pdev);
if (pci_is_enabled(pdev)) {
@@ -2062,7 +2068,6 @@ static void nvme_remove(struct pci_dev *
nvme_dev_disable(dev, true);
nvme_dev_remove_admin(dev);
nvme_free_queues(dev, 0);
- nvme_release_cmb(dev);
nvme_release_prp_pools(dev);
nvme_dev_unmap(dev);
nvme_put_ctrl(&dev->ctrl);
Patches currently in stable-queue which might be from jonathan.derrick@intel.com are
queue-4.11/nvme-unmap-cmb-and-remove-sysfs-file-in-reset-path.patch
^ permalink raw reply
* Patch "metag/uaccess: Fix access_ok()" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: james.hogan, gregkh, viro; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
metag/uaccess: Fix access_ok()
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
metag-uaccess-fix-access_ok.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 8a8b56638bcac4e64cccc88bf95a0f9f4b19a2fb Mon Sep 17 00:00:00 2001
From: James Hogan <james.hogan@imgtec.com>
Date: Fri, 28 Apr 2017 10:50:26 +0100
Subject: metag/uaccess: Fix access_ok()
From: James Hogan <james.hogan@imgtec.com>
commit 8a8b56638bcac4e64cccc88bf95a0f9f4b19a2fb upstream.
The __user_bad() macro used by access_ok() has a few corner cases
noticed by Al Viro where it doesn't behave correctly:
- The kernel range check has off by 1 errors which permit access to the
first and last byte of the kernel mapped range.
- The kernel range check ends at LINCORE_BASE rather than
META_MEMORY_LIMIT, which is ineffective when the kernel is in global
space (an extremely uncommon configuration).
There are a couple of other shortcomings here too:
- Access to the whole of the other address space is permitted (i.e. the
global half of the address space when the kernel is in local space).
This isn't ideal as it could theoretically still contain privileged
mappings set up by the bootloader.
- The size argument is unused, permitting user copies which start on
valid pages at the end of the user address range and cross the
boundary into the kernel address space (e.g. addr = 0x3ffffff0, size
> 0x10).
It isn't very convenient to add size checks when disallowing certain
regions, and it seems far safer to be sure and explicit about what
userland is able to access, so invert the logic to allow certain regions
instead, and fix the off by 1 errors and missing size checks. This also
allows the get_fs() == KERNEL_DS check to be more easily optimised into
the user address range case.
We now have 3 such allowed regions:
- The user address range (incorporating the get_fs() == KERNEL_DS
check).
- NULL (some kernel code expects this to work, and we'll always catch
the fault anyway).
- The core code memory region.
Fixes: 373cd784d0fc ("metag: Memory handling")
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/metag/include/asm/uaccess.h | 40 +++++++++++++++++++++++----------------
1 file changed, 24 insertions(+), 16 deletions(-)
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -28,24 +28,32 @@
#define segment_eq(a, b) ((a).seg == (b).seg)
-#define __kernel_ok (segment_eq(get_fs(), KERNEL_DS))
-/*
- * Explicitly allow NULL pointers here. Parts of the kernel such
- * as readv/writev use access_ok to validate pointers, but want
- * to allow NULL pointers for various reasons. NULL pointers are
- * safe to allow through because the first page is not mappable on
- * Meta.
- *
- * We also wish to avoid letting user code access the system area
- * and the kernel half of the address space.
- */
-#define __user_bad(addr, size) (((addr) > 0 && (addr) < META_MEMORY_BASE) || \
- ((addr) > PAGE_OFFSET && \
- (addr) < LINCORE_BASE))
-
static inline int __access_ok(unsigned long addr, unsigned long size)
{
- return __kernel_ok || !__user_bad(addr, size);
+ /*
+ * Allow access to the user mapped memory area, but not the system area
+ * before it. The check extends to the top of the address space when
+ * kernel access is allowed (there's no real reason to user copy to the
+ * system area in any case).
+ */
+ if (likely(addr >= META_MEMORY_BASE && addr < get_fs().seg &&
+ size <= get_fs().seg - addr))
+ return true;
+ /*
+ * Explicitly allow NULL pointers here. Parts of the kernel such
+ * as readv/writev use access_ok to validate pointers, but want
+ * to allow NULL pointers for various reasons. NULL pointers are
+ * safe to allow through because the first page is not mappable on
+ * Meta.
+ */
+ if (!addr)
+ return true;
+ /* Allow access to core code memory area... */
+ if (addr >= LINCORE_CODE_BASE && addr <= LINCORE_CODE_LIMIT &&
+ size <= LINCORE_CODE_LIMIT + 1 - addr)
+ return true;
+ /* ... but no other areas. */
+ return false;
}
#define access_ok(type, addr, size) __access_ok((unsigned long)(addr), \
Patches currently in stable-queue which might be from james.hogan@imgtec.com are
queue-4.11/metag-uaccess-check-access_ok-in-strncpy_from_user.patch
queue-4.11/metag-uaccess-fix-access_ok.patch
^ permalink raw reply
* Patch "KVM: arm: plug potential guest hardware debug leakage" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: zhichao.huang, alex.bennee, cdall, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
KVM: arm: plug potential guest hardware debug leakage
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-arm-plug-potential-guest-hardware-debug-leakage.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 661e6b02b5aa82db31897f36e96324b77450fd7a Mon Sep 17 00:00:00 2001
From: Zhichao Huang <zhichao.huang@linaro.org>
Date: Thu, 11 May 2017 13:46:11 +0100
Subject: KVM: arm: plug potential guest hardware debug leakage
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Zhichao Huang <zhichao.huang@linaro.org>
commit 661e6b02b5aa82db31897f36e96324b77450fd7a upstream.
Hardware debugging in guests is not intercepted currently, it means
that a malicious guest can bring down the entire machine by writing
to the debug registers.
This patch enable trapping of all debug registers, preventing the
guests to access the debug registers. This includes access to the
debug mode(DBGDSCR) in the guest world all the time which could
otherwise mess with the host state. Reads return 0 and writes are
ignored (RAZ_WI).
The result is the guest cannot detect any working hardware based debug
support. As debug exceptions are still routed to the guest normal
debug using software based breakpoints still works.
To support debugging using hardware registers we need to implement a
debug register aware world switch as well as special trapping for
registers that may affect the host state.
Signed-off-by: Zhichao Huang <zhichao.huang@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/kvm_coproc.h | 3 -
arch/arm/kvm/coproc.c | 77 +++++++++++++++++++++++++++++---------
arch/arm/kvm/handle_exit.c | 4 -
arch/arm/kvm/hyp/switch.c | 4 +
4 files changed, 66 insertions(+), 22 deletions(-)
--- a/arch/arm/include/asm/kvm_coproc.h
+++ b/arch/arm/include/asm/kvm_coproc.h
@@ -31,7 +31,8 @@ void kvm_register_target_coproc_table(st
int kvm_handle_cp10_id(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp_0_13_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp14_load_store(struct kvm_vcpu *vcpu, struct kvm_run *run);
-int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
+int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);
int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run);
--- a/arch/arm/kvm/coproc.c
+++ b/arch/arm/kvm/coproc.c
@@ -93,12 +93,6 @@ int kvm_handle_cp14_load_store(struct kv
return 1;
}
-int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run)
-{
- kvm_inject_undefined(vcpu);
- return 1;
-}
-
static void reset_mpidr(struct kvm_vcpu *vcpu, const struct coproc_reg *r)
{
/*
@@ -514,12 +508,7 @@ static int emulate_cp15(struct kvm_vcpu
return 1;
}
-/**
- * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
- * @vcpu: The VCPU pointer
- * @run: The kvm_run struct
- */
-int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static struct coproc_params decode_64bit_hsr(struct kvm_vcpu *vcpu)
{
struct coproc_params params;
@@ -533,9 +522,38 @@ int kvm_handle_cp15_64(struct kvm_vcpu *
params.Rt2 = (kvm_vcpu_get_hsr(vcpu) >> 10) & 0xf;
params.CRm = 0;
+ return params;
+}
+
+/**
+ * kvm_handle_cp15_64 -- handles a mrrc/mcrr trap on a guest CP15 access
+ * @vcpu: The VCPU pointer
+ * @run: The kvm_run struct
+ */
+int kvm_handle_cp15_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ struct coproc_params params = decode_64bit_hsr(vcpu);
+
return emulate_cp15(vcpu, ¶ms);
}
+/**
+ * kvm_handle_cp14_64 -- handles a mrrc/mcrr trap on a guest CP14 access
+ * @vcpu: The VCPU pointer
+ * @run: The kvm_run struct
+ */
+int kvm_handle_cp14_64(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ struct coproc_params params = decode_64bit_hsr(vcpu);
+
+ /* raz_wi cp14 */
+ pm_fake(vcpu, ¶ms, NULL);
+
+ /* handled */
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+ return 1;
+}
+
static void reset_coproc_regs(struct kvm_vcpu *vcpu,
const struct coproc_reg *table, size_t num)
{
@@ -546,12 +564,7 @@ static void reset_coproc_regs(struct kvm
table[i].reset(vcpu, &table[i]);
}
-/**
- * kvm_handle_cp15_32 -- handles a mrc/mcr trap on a guest CP15 access
- * @vcpu: The VCPU pointer
- * @run: The kvm_run struct
- */
-int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run)
+static struct coproc_params decode_32bit_hsr(struct kvm_vcpu *vcpu)
{
struct coproc_params params;
@@ -565,9 +578,37 @@ int kvm_handle_cp15_32(struct kvm_vcpu *
params.Op2 = (kvm_vcpu_get_hsr(vcpu) >> 17) & 0x7;
params.Rt2 = 0;
+ return params;
+}
+
+/**
+ * kvm_handle_cp15_32 -- handles a mrc/mcr trap on a guest CP15 access
+ * @vcpu: The VCPU pointer
+ * @run: The kvm_run struct
+ */
+int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ struct coproc_params params = decode_32bit_hsr(vcpu);
return emulate_cp15(vcpu, ¶ms);
}
+/**
+ * kvm_handle_cp14_32 -- handles a mrc/mcr trap on a guest CP14 access
+ * @vcpu: The VCPU pointer
+ * @run: The kvm_run struct
+ */
+int kvm_handle_cp14_32(struct kvm_vcpu *vcpu, struct kvm_run *run)
+{
+ struct coproc_params params = decode_32bit_hsr(vcpu);
+
+ /* raz_wi cp14 */
+ pm_fake(vcpu, ¶ms, NULL);
+
+ /* handled */
+ kvm_skip_instr(vcpu, kvm_vcpu_trap_il_is32bit(vcpu));
+ return 1;
+}
+
/******************************************************************************
* Userspace API
*****************************************************************************/
--- a/arch/arm/kvm/handle_exit.c
+++ b/arch/arm/kvm/handle_exit.c
@@ -95,9 +95,9 @@ static exit_handle_fn arm_exit_handlers[
[HSR_EC_WFI] = kvm_handle_wfx,
[HSR_EC_CP15_32] = kvm_handle_cp15_32,
[HSR_EC_CP15_64] = kvm_handle_cp15_64,
- [HSR_EC_CP14_MR] = kvm_handle_cp14_access,
+ [HSR_EC_CP14_MR] = kvm_handle_cp14_32,
[HSR_EC_CP14_LS] = kvm_handle_cp14_load_store,
- [HSR_EC_CP14_64] = kvm_handle_cp14_access,
+ [HSR_EC_CP14_64] = kvm_handle_cp14_64,
[HSR_EC_CP_0_13] = kvm_handle_cp_0_13_access,
[HSR_EC_CP10_ID] = kvm_handle_cp10_id,
[HSR_EC_HVC] = handle_hvc,
--- a/arch/arm/kvm/hyp/switch.c
+++ b/arch/arm/kvm/hyp/switch.c
@@ -48,7 +48,9 @@ static void __hyp_text __activate_traps(
write_sysreg(HSTR_T(15), HSTR);
write_sysreg(HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11), HCPTR);
val = read_sysreg(HDCR);
- write_sysreg(val | HDCR_TPM | HDCR_TPMCR, HDCR);
+ val |= HDCR_TPM | HDCR_TPMCR; /* trap performance monitors */
+ val |= HDCR_TDRA | HDCR_TDOSA | HDCR_TDA; /* trap debug regs */
+ write_sysreg(val, HDCR);
}
static void __hyp_text __deactivate_traps(struct kvm_vcpu *vcpu)
Patches currently in stable-queue which might be from zhichao.huang@linaro.org are
queue-4.11/kvm-arm-plug-potential-guest-hardware-debug-leakage.patch
^ permalink raw reply
* Patch "metag/uaccess: Check access_ok in strncpy_from_user" has been added to the 4.11-stable tree
From: gregkh @ 2017-05-23 14:45 UTC (permalink / raw)
To: james.hogan, gregkh, viro; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
metag/uaccess: Check access_ok in strncpy_from_user
to the 4.11-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
metag-uaccess-check-access_ok-in-strncpy_from_user.patch
and it can be found in the queue-4.11 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From 3a158a62da0673db918b53ac1440845a5b64fd90 Mon Sep 17 00:00:00 2001
From: James Hogan <james.hogan@imgtec.com>
Date: Tue, 2 May 2017 19:41:06 +0100
Subject: metag/uaccess: Check access_ok in strncpy_from_user
From: James Hogan <james.hogan@imgtec.com>
commit 3a158a62da0673db918b53ac1440845a5b64fd90 upstream.
The metag implementation of strncpy_from_user() doesn't validate the src
pointer, which could allow reading of arbitrary kernel memory. Add a
short access_ok() check to prevent that.
Its still possible for it to read across the user/kernel boundary, but
it will invariably reach a NUL character after only 9 bytes, leaking
only a static kernel address being loaded into D0Re0 at the beginning of
__start, which is acceptable for the immediate fix.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-metag@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/metag/include/asm/uaccess.h | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
--- a/arch/metag/include/asm/uaccess.h
+++ b/arch/metag/include/asm/uaccess.h
@@ -194,8 +194,13 @@ do {
extern long __must_check __strncpy_from_user(char *dst, const char __user *src,
long count);
-#define strncpy_from_user(dst, src, count) __strncpy_from_user(dst, src, count)
-
+static inline long
+strncpy_from_user(char *dst, const char __user *src, long count)
+{
+ if (!access_ok(VERIFY_READ, src, 1))
+ return -EFAULT;
+ return __strncpy_from_user(dst, src, count);
+}
/*
* Return the size of a string (including the ending 0)
*
Patches currently in stable-queue which might be from james.hogan@imgtec.com are
queue-4.11/metag-uaccess-check-access_ok-in-strncpy_from_user.patch
queue-4.11/metag-uaccess-fix-access_ok.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox