This is a note to let you know that I've just added the patch titled
X.509: fix comparisons of ->pkey_algo
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x.509-fix-comparisons-of-pkey_algo.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 54c1fb39fe0495f846539ab765925b008f86801c Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Fri, 8 Dec 2017 15:13:29 +0000
Subject: X.509: fix comparisons of ->pkey_algo
From: Eric Biggers <ebiggers(a)google.com>
commit 54c1fb39fe0495f846539ab765925b008f86801c upstream.
->pkey_algo used to be an enum, but was changed to a string by commit
4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum"). But
two comparisons were not updated. Fix them to use strcmp().
This bug broke signature verification in certain configurations,
depending on whether the string constants were deduplicated or not.
Fixes: 4e8ae72a75aa ("X.509: Make algo identifiers text instead of enum")
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: David Howells <dhowells(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/asymmetric_keys/pkcs7_verify.c | 2 +-
crypto/asymmetric_keys/x509_public_key.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -150,7 +150,7 @@ static int pkcs7_find_key(struct pkcs7_m
pr_devel("Sig %u: Found cert serial match X.509[%u]\n",
sinfo->index, certix);
- if (x509->pub->pkey_algo != sinfo->sig->pkey_algo) {
+ if (strcmp(x509->pub->pkey_algo, sinfo->sig->pkey_algo) != 0) {
pr_warn("Sig %u: X.509 algo and PKCS#7 sig algo don't match\n",
sinfo->index);
continue;
--- a/crypto/asymmetric_keys/x509_public_key.c
+++ b/crypto/asymmetric_keys/x509_public_key.c
@@ -125,7 +125,7 @@ int x509_check_for_self_signed(struct x5
}
ret = -EKEYREJECTED;
- if (cert->pub->pkey_algo != cert->sig->pkey_algo)
+ if (strcmp(cert->pub->pkey_algo, cert->sig->pkey_algo) != 0)
goto out;
ret = public_key_verify_signature(cert->pub, cert->sig);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/x.509-reject-invalid-bit-string-for-subjectpublickey.patch
queue-4.9/asn.1-check-for-error-from-asn1_op_end__act-actions.patch
queue-4.9/keys-add-missing-permission-check-for-request_key-destination.patch
queue-4.9/asn.1-fix-out-of-bounds-read-when-parsing-indefinite-length-item.patch
queue-4.9/x.509-fix-comparisons-of-pkey_algo.patch
This is a note to let you know that I've just added the patch titled
virtio: release virtio index when fail to device_register
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
virtio-release-virtio-index-when-fail-to-device_register.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e60ea67bb60459b95a50a156296041a13e0e380e Mon Sep 17 00:00:00 2001
From: weiping zhang <zwp10758(a)gmail.com>
Date: Wed, 29 Nov 2017 09:23:01 +0800
Subject: virtio: release virtio index when fail to device_register
From: weiping zhang <zwp10758(a)gmail.com>
commit e60ea67bb60459b95a50a156296041a13e0e380e upstream.
index can be reused by other virtio device.
Signed-off-by: weiping zhang <zhangweiping(a)didichuxing.com>
Reviewed-by: Cornelia Huck <cohuck(a)redhat.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/virtio/virtio.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -323,6 +323,8 @@ int register_virtio_device(struct virtio
/* device_register() causes the bus infrastructure to look for a
* matching driver. */
err = device_register(&dev->dev);
+ if (err)
+ ida_simple_remove(&virtio_index_ida, dev->index);
out:
if (err)
add_status(dev, VIRTIO_CONFIG_S_FAILED);
Patches currently in stable-queue which might be from zwp10758(a)gmail.com are
queue-4.9/virtio-release-virtio-index-when-fail-to-device_register.patch
This is a note to let you know that I've just added the patch titled
smp/hotplug: Move step CPUHP_AP_SMPCFD_DYING to the correct place
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
smp-hotplug-move-step-cpuhp_ap_smpcfd_dying-to-the-correct-place.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 46febd37f9c758b05cd25feae8512f22584742fe Mon Sep 17 00:00:00 2001
From: Lai Jiangshan <jiangshanlai(a)gmail.com>
Date: Tue, 28 Nov 2017 21:19:53 +0800
Subject: smp/hotplug: Move step CPUHP_AP_SMPCFD_DYING to the correct place
From: Lai Jiangshan <jiangshanlai(a)gmail.com>
commit 46febd37f9c758b05cd25feae8512f22584742fe upstream.
Commit 31487f8328f2 ("smp/cfd: Convert core to hotplug state machine")
accidently put this step on the wrong place. The step should be at the
cpuhp_ap_states[] rather than the cpuhp_bp_states[].
grep smpcfd /sys/devices/system/cpu/hotplug/states
40: smpcfd:prepare
129: smpcfd:dying
"smpcfd:dying" was missing before.
So was the invocation of the function smpcfd_dying_cpu().
Fixes: 31487f8328f2 ("smp/cfd: Convert core to hotplug state machine")
Signed-off-by: Lai Jiangshan <jiangshanlai(a)gmail.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Richard Weinberger <richard(a)nod.at>
Cc: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Link: https://lkml.kernel.org/r/20171128131954.81229-1-jiangshanlai@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/cpu.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -1321,11 +1321,6 @@ static struct cpuhp_step cpuhp_bp_states
.teardown.single = NULL,
.cant_stop = true,
},
- [CPUHP_AP_SMPCFD_DYING] = {
- .name = "smpcfd:dying",
- .startup.single = NULL,
- .teardown.single = smpcfd_dying_cpu,
- },
/*
* Handled on controll processor until the plugged processor manages
* this itself.
@@ -1367,6 +1362,11 @@ static struct cpuhp_step cpuhp_ap_states
.startup.single = NULL,
.teardown.single = rcutree_dying_cpu,
},
+ [CPUHP_AP_SMPCFD_DYING] = {
+ .name = "smpcfd:dying",
+ .startup.single = NULL,
+ .teardown.single = smpcfd_dying_cpu,
+ },
/* Entry state on starting. Interrupts enabled from here on. Transient
* state for synchronsization */
[CPUHP_AP_ONLINE] = {
Patches currently in stable-queue which might be from jiangshanlai(a)gmail.com are
queue-4.9/smp-hotplug-move-step-cpuhp_ap_smpcfd_dying-to-the-correct-place.patch
This is a note to let you know that I've just added the patch titled
scsi: libsas: align sata_device's rps_resp on a cacheline
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From c2e8fbf908afd81ad502b567a6639598f92c9b9d Mon Sep 17 00:00:00 2001
From: Huacai Chen <chenhc(a)lemote.com>
Date: Tue, 21 Nov 2017 14:23:39 +0100
Subject: scsi: libsas: align sata_device's rps_resp on a cacheline
From: Huacai Chen <chenhc(a)lemote.com>
commit c2e8fbf908afd81ad502b567a6639598f92c9b9d upstream.
The rps_resp buffer in ata_device is a DMA target, but it isn't
explicitly cacheline aligned. Due to this, adjacent fields can be
overwritten with stale data from memory on non-coherent architectures.
As a result, the kernel is sometimes unable to communicate with an SATA
device behind a SAS expander.
Fix this by ensuring that the rps_resp buffer is cacheline aligned.
This issue is similar to that fixed by Commit 84bda12af31f93 ("libata:
align ap->sector_buf") and Commit 4ee34ea3a12396f35b26 ("libata: Align
ata_device's id on a cacheline").
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/scsi/libsas.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -165,11 +165,11 @@ struct expander_device {
struct sata_device {
unsigned int class;
- struct smp_resp rps_resp; /* report_phy_sata_resp */
u8 port_no; /* port number, if this is a PM (Port) */
struct ata_port *ap;
struct ata_host ata_host;
+ struct smp_resp rps_resp ____cacheline_aligned; /* report_phy_sata_resp */
u8 fis[ATA_RESP_FIS_SIZE];
};
Patches currently in stable-queue which might be from chenhc(a)lemote.com are
queue-4.9/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch
queue-4.9/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch
This is a note to let you know that I've just added the patch titled
scsi: use dma_get_cache_alignment() as minimum DMA alignment
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 90addc6b3c9cda0146fbd62a08e234c2b224a80c Mon Sep 17 00:00:00 2001
From: Huacai Chen <chenhc(a)lemote.com>
Date: Tue, 21 Nov 2017 14:23:38 +0100
Subject: scsi: use dma_get_cache_alignment() as minimum DMA alignment
From: Huacai Chen <chenhc(a)lemote.com>
commit 90addc6b3c9cda0146fbd62a08e234c2b224a80c upstream.
In non-coherent DMA mode, kernel uses cache flushing operations to
maintain I/O coherency, so scsi's block queue should be aligned to the
value returned by dma_get_cache_alignment(). Otherwise, If a DMA buffer
and a kernel structure share a same cache line, and if the kernel
structure has dirty data, cache_invalidate (no writeback) will cause
data corruption.
Signed-off-by: Huacai Chen <chenhc(a)lemote.com>
[hch: rebased and updated the comment and changelog]
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/scsi/scsi_lib.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2041,11 +2041,13 @@ static void __scsi_init_queue(struct Scs
q->limits.cluster = 0;
/*
- * set a reasonable default alignment on word boundaries: the
- * host and device may alter it using
- * blk_queue_update_dma_alignment() later.
+ * Set a reasonable default alignment: The larger of 32-byte (dword),
+ * which is a common minimum for HBAs, and the minimum DMA alignment,
+ * which is set by the platform.
+ *
+ * Devices that require a bigger alignment can increase it later.
*/
- blk_queue_dma_alignment(q, 0x03);
+ blk_queue_dma_alignment(q, max(4, dma_get_cache_alignment()) - 1);
}
struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost,
Patches currently in stable-queue which might be from chenhc(a)lemote.com are
queue-4.9/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch
queue-4.9/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch
This is a note to let you know that I've just added the patch titled
s390: fix compat system call table
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
s390-fix-compat-system-call-table.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e779498df587dd2189b30fe5b9245aefab870eb8 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Date: Wed, 6 Dec 2017 16:11:27 +0100
Subject: s390: fix compat system call table
From: Heiko Carstens <heiko.carstens(a)de.ibm.com>
commit e779498df587dd2189b30fe5b9245aefab870eb8 upstream.
When wiring up the socket system calls the compat entries were
incorrectly set. Not all of them point to the corresponding compat
wrapper functions, which clear the upper 33 bits of user space
pointers, like it is required.
Fixes: 977108f89c989 ("s390: wire up separate socketcalls system calls")
Signed-off-by: Heiko Carstens <heiko.carstens(a)de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/s390/kernel/syscalls.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/s390/kernel/syscalls.S
+++ b/arch/s390/kernel/syscalls.S
@@ -369,10 +369,10 @@ SYSCALL(sys_recvmmsg,compat_sys_recvmmsg
SYSCALL(sys_sendmmsg,compat_sys_sendmmsg)
SYSCALL(sys_socket,sys_socket)
SYSCALL(sys_socketpair,compat_sys_socketpair) /* 360 */
-SYSCALL(sys_bind,sys_bind)
-SYSCALL(sys_connect,sys_connect)
+SYSCALL(sys_bind,compat_sys_bind)
+SYSCALL(sys_connect,compat_sys_connect)
SYSCALL(sys_listen,sys_listen)
-SYSCALL(sys_accept4,sys_accept4)
+SYSCALL(sys_accept4,compat_sys_accept4)
SYSCALL(sys_getsockopt,compat_sys_getsockopt) /* 365 */
SYSCALL(sys_setsockopt,compat_sys_setsockopt)
SYSCALL(sys_getsockname,compat_sys_getsockname)
Patches currently in stable-queue which might be from heiko.carstens(a)de.ibm.com are
queue-4.9/s390-fix-compat-system-call-table.patch
This is a note to let you know that I've just added the patch titled
scsi: dma-mapping: always provide dma_get_cache_alignment
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
scsi-dma-mapping-always-provide-dma_get_cache_alignment.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 860dd4424f344400b491b212ee4acb3a358ba9d9 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <hch(a)lst.de>
Date: Tue, 21 Nov 2017 14:23:37 +0100
Subject: scsi: dma-mapping: always provide dma_get_cache_alignment
From: Christoph Hellwig <hch(a)lst.de>
commit 860dd4424f344400b491b212ee4acb3a358ba9d9 upstream.
Provide the dummy version of dma_get_cache_alignment that always returns
1 even if CONFIG_HAS_DMA is not set, so that drivers and subsystems can
use it without ifdefs.
Signed-off-by: Christoph Hellwig <hch(a)lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/dma-mapping.h | 2 --
1 file changed, 2 deletions(-)
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -659,7 +659,6 @@ static inline void *dma_zalloc_coherent(
return ret;
}
-#ifdef CONFIG_HAS_DMA
static inline int dma_get_cache_alignment(void)
{
#ifdef ARCH_DMA_MINALIGN
@@ -667,7 +666,6 @@ static inline int dma_get_cache_alignmen
#endif
return 1;
}
-#endif
/* flags for the coherent memory api */
#define DMA_MEMORY_MAP 0x01
Patches currently in stable-queue which might be from hch(a)lst.de are
queue-4.9/scsi-use-dma_get_cache_alignment-as-minimum-dma-alignment.patch
queue-4.9/scsi-dma-mapping-always-provide-dma_get_cache_alignment.patch
queue-4.9/scsi-libsas-align-sata_device-s-rps_resp-on-a-cacheline.patch
This is a note to let you know that I've just added the patch titled
powerpc/64s: Initialize ISAv3 MMU registers before setting partition table
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 371b80447ff33ddac392c189cf884a5a3e18faeb Mon Sep 17 00:00:00 2001
From: Nicholas Piggin <npiggin(a)gmail.com>
Date: Wed, 6 Dec 2017 18:21:14 +1000
Subject: powerpc/64s: Initialize ISAv3 MMU registers before setting partition table
From: Nicholas Piggin <npiggin(a)gmail.com>
commit 371b80447ff33ddac392c189cf884a5a3e18faeb upstream.
kexec can leave MMU registers set when booting into a new kernel,
the PIDR (Process Identification Register) in particular. The boot
sequence does not zero PIDR, so it only gets set when CPUs first
switch to a userspace processes (until then it's running a kernel
thread with effective PID = 0).
This leaves a window where a process table entry and page tables are
set up due to user processes running on other CPUs, that happen to
match with a stale PID. The CPU with that PID may cause speculative
accesses that address quadrant 0 (aka userspace addresses), which will
result in cached translations and PWC (Page Walk Cache) for that
process, on a CPU which is not in the mm_cpumask and so they will not
be invalidated properly.
The most common result is the kernel hanging in infinite page fault
loops soon after kexec (usually in schedule_tail, which is usually the
first non-speculative quadrant 0 access to a new PID) due to a stale
PWC. However being a stale translation error, it could result in
anything up to security and data corruption problems.
Fix this by zeroing out PIDR at boot and kexec.
Fixes: 7e381c0ff618 ("powerpc/mm/radix: Add mmu context handling callback for radix")
Signed-off-by: Nicholas Piggin <npiggin(a)gmail.com>
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/powerpc/kernel/cpu_setup_power.S | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/powerpc/kernel/cpu_setup_power.S
+++ b/arch/powerpc/kernel/cpu_setup_power.S
@@ -97,6 +97,7 @@ _GLOBAL(__setup_cpu_power9)
beqlr
li r0,0
mtspr SPRN_LPID,r0
+ mtspr SPRN_PID,r0
mfspr r3,SPRN_LPCR
LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
or r3, r3, r4
@@ -119,6 +120,7 @@ _GLOBAL(__restore_cpu_power9)
beqlr
li r0,0
mtspr SPRN_LPID,r0
+ mtspr SPRN_PID,r0
mfspr r3,SPRN_LPCR
LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE)
or r3, r3, r4
Patches currently in stable-queue which might be from npiggin(a)gmail.com are
queue-4.9/powerpc-64s-initialize-isav3-mmu-registers-before-setting-partition-table.patch
This is a note to let you know that I've just added the patch titled
media: dvb: i2c transfers over usb cannot be done from stack
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-dvb-i2c-transfers-over-usb-cannot-be-done-from-stack.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 6d33377f2abbf9f0e561b116dd468d1c3ff36a6a Mon Sep 17 00:00:00 2001
From: Laurent Caumont <lcaumont2(a)gmail.com>
Date: Sat, 11 Nov 2017 12:44:46 -0500
Subject: media: dvb: i2c transfers over usb cannot be done from stack
From: Laurent Caumont <lcaumont2(a)gmail.com>
commit 6d33377f2abbf9f0e561b116dd468d1c3ff36a6a upstream.
Signed-off-by: Laurent Caumont <lcaumont2(a)gmail.com>
Signed-off-by: Sean Young <sean(a)mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/dvb-usb/dibusb-common.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/dvb-usb/dibusb-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-common.c
@@ -223,8 +223,20 @@ EXPORT_SYMBOL(dibusb_i2c_algo);
int dibusb_read_eeprom_byte(struct dvb_usb_device *d, u8 offs, u8 *val)
{
- u8 wbuf[1] = { offs };
- return dibusb_i2c_msg(d, 0x50, wbuf, 1, val, 1);
+ u8 *buf;
+ int rc;
+
+ buf = kmalloc(2, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ buf[0] = offs;
+
+ rc = dibusb_i2c_msg(d, 0x50, &buf[0], 1, &buf[1], 1);
+ *val = buf[1];
+ kfree(buf);
+
+ return rc;
}
EXPORT_SYMBOL(dibusb_read_eeprom_byte);
Patches currently in stable-queue which might be from lcaumont2(a)gmail.com are
queue-4.9/media-dvb-i2c-transfers-over-usb-cannot-be-done-from-stack.patch
This is a note to let you know that I've just added the patch titled
KVM: x86: fix APIC page invalidation
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-x86-fix-apic-page-invalidation.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b1394e745b9453dcb5b0671c205b770e87dedb87 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar(a)redhat.com>
Date: Thu, 30 Nov 2017 19:05:45 +0100
Subject: KVM: x86: fix APIC page invalidation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Radim Krčmář <rkrcmar(a)redhat.com>
commit b1394e745b9453dcb5b0671c205b770e87dedb87 upstream.
Implementation of the unpinned APIC page didn't update the VMCS address
cache when invalidation was done through range mmu notifiers.
This became a problem when the page notifier was removed.
Re-introduce the arch-specific helper and call it from ...range_start.
Reported-by: Fabian Grünbichler <f.gruenbichler(a)proxmox.com>
Fixes: 38b9917350cb ("kvm: vmx: Implement set_apic_access_page_addr")
Fixes: 369ea8242c0f ("mm/rmap: update to new mmu_notifier semantic v2")
Reviewed-by: Paolo Bonzini <pbonzini(a)redhat.com>
Reviewed-by: Andrea Arcangeli <aarcange(a)redhat.com>
Tested-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Tested-by: Fabian Grünbichler <f.gruenbichler(a)proxmox.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/include/asm/kvm_host.h | 3 +++
arch/x86/kvm/x86.c | 14 ++++++++++++++
virt/kvm/kvm_main.c | 8 ++++++++
3 files changed, 25 insertions(+)
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1397,4 +1397,7 @@ static inline int kvm_cpu_get_apicid(int
#endif
}
+void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+ unsigned long start, unsigned long end);
+
#endif /* _ASM_X86_KVM_HOST_H */
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6526,6 +6526,20 @@ static void kvm_vcpu_flush_tlb(struct kv
kvm_x86_ops->tlb_flush(vcpu);
}
+void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+ unsigned long start, unsigned long end)
+{
+ unsigned long apic_address;
+
+ /*
+ * The physical address of apic access page is stored in the VMCS.
+ * Update it when it becomes invalid.
+ */
+ apic_address = gfn_to_hva(kvm, APIC_DEFAULT_PHYS_BASE >> PAGE_SHIFT);
+ if (start <= apic_address && apic_address < end)
+ kvm_make_all_cpus_request(kvm, KVM_REQ_APIC_PAGE_RELOAD);
+}
+
void kvm_vcpu_reload_apic_access_page(struct kvm_vcpu *vcpu)
{
struct page *page = NULL;
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -125,6 +125,11 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
static bool largepages_enabled = true;
+__weak void kvm_arch_mmu_notifier_invalidate_range(struct kvm *kvm,
+ unsigned long start, unsigned long end)
+{
+}
+
bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
{
if (pfn_valid(pfn))
@@ -361,6 +366,9 @@ static void kvm_mmu_notifier_invalidate_
kvm_flush_remote_tlbs(kvm);
spin_unlock(&kvm->mmu_lock);
+
+ kvm_arch_mmu_notifier_invalidate_range(kvm, start, end);
+
srcu_read_unlock(&kvm->srcu, idx);
}
Patches currently in stable-queue which might be from rkrcmar(a)redhat.com are
queue-4.9/kvm-vmx-remove-i-o-port-0x80-bypass-on-intel-hosts.patch
queue-4.9/kvm-x86-fix-apic-page-invalidation.patch