The patch titled
Subject: fork: report pid exhaustion correctly
has been removed from the -mm tree. Its filename was
fork-report-pid-exhaustion-correctly.patch
This patch was dropped because it was merged into mainline or a subsystem tree
------------------------------------------------------
From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Subject: fork: report pid exhaustion correctly
Make the clone and fork syscalls return EAGAIN when the limit on the
number of pids /proc/sys/kernel/pid_max is exceeded.
Currently, when the pid_max limit is exceeded, the kernel will return
ENOSPC from the fork and clone syscalls. This is contrary to the
documented behaviour, which explicitly calls out the pid_max case as one
where EAGAIN should be returned. It also leads to really confusing error
messages in userspace programs which will complain about a lack of disk
space when they fail to create processes/threads for this reason.
This error is being returned because alloc_pid() uses the idr api to find
a new pid; when there are none available, idr_alloc_cyclic() returns
-ENOSPC, and this is being propagated back to userspace.
This behaviour has been broken before, and was explicitly fixed in
commit 35f71bc0a09a ("fork: report pid reservation failure properly"),
so I think -EAGAIN is definitely the right thing to return in this case.
The current behaviour change dates from commit 95846ecf9dac ("pid:
replace pid bitmap implementation with IDR AIP") and was I believe
unintentional.
This patch has no impact on the case where allocating a pid fails because
the child reaper for the namespace is dead; that case will still return
-ENOMEM.
Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP")
Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Gargi Sharma <gs051095(a)gmail.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c
--- a/kernel/pid.c~fork-report-pid-exhaustion-correctly
+++ a/kernel/pid.c
@@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa
idr_preload_end();
if (nr < 0) {
- retval = nr;
+ retval = (nr == -ENOSPC) ? -EAGAIN : nr;
goto out_free;
}
_
Patches currently in -mm which might be from ktsanaktsidis(a)zendesk.com are
While we currently grab a runtime PM ref in nouveau's normal connector
detection code, we apparently don't do this for MST. This means if we're
in a scenario where the GPU is suspended and userspace attempts to do a
connector probe on an MSTC connector, the probe will fail entirely due
to the DP aux channel and GPU not being woken up:
[ 316.633489] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
[ 316.635713] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
[ 316.637785] nouveau 0000:01:00.0: i2c: aux 000a: begin idle timeout ffffffff
...
So, grab a runtime PM ref here.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c94b7f42d62d..9da0bdfe1e1c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -938,9 +938,22 @@ static enum drm_connector_status
nv50_mstc_detect(struct drm_connector *connector, bool force)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
+ enum drm_connector_status conn_status;
+ int ret;
+
if (!mstc->port)
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, mstc->port->mgr, mstc->port);
+
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return connector_status_disconnected;
+
+ conn_status = drm_dp_mst_detect_port(connector, mstc->port->mgr,
+ mstc->port);
+
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ return conn_status;
}
static void
--
2.17.1
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v4.18.8, v4.14.70, v4.9.127, v4.4.156, v3.18.122,
v4.18.8: Build OK!
v4.14.70: Failed to apply! Possible dependencies:
22aac3eb0c46 ("MAINTAINERS: add entry for STM32 I2C driver")
v4.9.127: Failed to apply! Possible dependencies:
22aac3eb0c46 ("MAINTAINERS: add entry for STM32 I2C driver")
78f839029e1d ("iio: distance: srf08: add IIO driver for us ranger")
v4.4.156: Failed to apply! Possible dependencies:
22aac3eb0c46 ("MAINTAINERS: add entry for STM32 I2C driver")
78f839029e1d ("iio: distance: srf08: add IIO driver for us ranger")
v3.18.122: Failed to apply! Possible dependencies:
22aac3eb0c46 ("MAINTAINERS: add entry for STM32 I2C driver")
4193c0f1d863 ("iio: driver for Semtech SX9500 proximity solution")
78f839029e1d ("iio: distance: srf08: add IIO driver for us ranger")
Please let us know how to resolve this.
--
Thanks,
Sasha
On little endian platforms, csum_ipv6_magic() keeps len and proto in
CPU byte order. This generates a bad results leading to ICMPv6 packets
from other hosts being dropped by powerpc64le platforms.
In order to fix this, len and proto should be converted to network
byte order ie bigendian byte order. However checksumming 0x12345678
and 0x56341278 provide the exact same result so it is enough to
rotate the sum of len and proto by 1 byte.
PPC32 only support bigendian so the fix is needed for PPC64 only
Fixes: e9c4943a107b ("powerpc: Implement csum_ipv6_magic in assembly")
Reported-by: Jianlin Shi <jishi(a)redhat.com>
Reported-by: Xin Long <lucien.xin(a)gmail.com>
Cc: <stable(a)vger.kernel.org> # 4.18+
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
---
arch/powerpc/lib/checksum_64.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/lib/checksum_64.S b/arch/powerpc/lib/checksum_64.S
index 886ed94b9c13..2a68c43e13f5 100644
--- a/arch/powerpc/lib/checksum_64.S
+++ b/arch/powerpc/lib/checksum_64.S
@@ -443,6 +443,9 @@ _GLOBAL(csum_ipv6_magic)
addc r0, r8, r9
ld r10, 0(r4)
ld r11, 8(r4)
+#ifndef CONFIG_CPU_BIG_ENDIAN
+ rotldi r5, r5, 8
+#endif
adde r0, r0, r10
add r5, r5, r7
adde r0, r0, r11
--
2.13.3
We need that to adjust the len of the 2nd transfer (called data in
spi-mem) if it's too long to fit in a SPI message or SPI transfer.
Fixes: c36ff266dc82 ("spi: Extend the core to ease integration of SPI memory controllers")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Chuanhua Han <chuanhua.han(a)nxp.com>
Reviewed-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
drivers/spi/spi-mem.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index 990770dfa5cf..ec0c24e873cd 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -328,10 +328,25 @@ EXPORT_SYMBOL_GPL(spi_mem_exec_op);
int spi_mem_adjust_op_size(struct spi_mem *mem, struct spi_mem_op *op)
{
struct spi_controller *ctlr = mem->spi->controller;
+ size_t len;
+
+ len = sizeof(op->cmd.opcode) + op->addr.nbytes + op->dummy.nbytes;
if (ctlr->mem_ops && ctlr->mem_ops->adjust_op_size)
return ctlr->mem_ops->adjust_op_size(mem, op);
+ if (!ctlr->mem_ops || !ctlr->mem_ops->exec_op) {
+ if (len > spi_max_transfer_size(mem->spi))
+ return -EINVAL;
+
+ op->data.nbytes = min3((size_t)op->data.nbytes,
+ spi_max_transfer_size(mem->spi),
+ spi_max_message_size(mem->spi) -
+ len);
+ if (!op->data.nbytes)
+ return -EINVAL;
+ }
+
return 0;
}
EXPORT_SYMBOL_GPL(spi_mem_adjust_op_size);
--
2.17.1
Hello,
Tested without any problem so please picked up this for 4.4 to fix the
problem.
The patch below is slightly modified to adapt to this version.
[ Upstream commit 7616ac70d1bb4f2e9d25c1a82d283f3368a7b632 ]
The newly added Kconfig option could never work and just causes a build
error
when disabled:
security/apparmor/lsm.c:675:25: error:
'CONFIG_SECURITY_APPARMOR_HASH_DEFAULT' undeclared here (not in a
function)
bool aa_g_hash_policy = CONFIG_SECURITY_APPARMOR_HASH_DEFAULT;
The problem is that the macro undefined in this case, and we need to use
the IS_ENABLED()
helper to turn it into a boolean constant.
Another minor problem with the original patch is that the option is even
offered
in sysfs when SECURITY_APPARMOR_HASH is not enabled, so this also hides
the option
in that case.
Signed-off-by: Arnd Bergmann <arnd(a)arndb.de>
Fixes: 6059f71f1e94 ("apparmor: add parameter to control whether policy
hashing is used")
Signed-off-by: John Johansen <john.johansen(a)canonical.com>
Signed-off-by: James Morris <james.l.morris(a)oracle.com>
---
diff -Nurp a/security/apparmor/crypto.c b/security/apparmor/crypto.c
--- a/security/apparmor/crypto.c
+++ b/security/apparmor/crypto.c
@@ -39,6 +39,9 @@ int aa_calc_profile_hash(struct aa_profi
int error = -ENOMEM;
u32 le32_version = cpu_to_le32(version);
+ if (!aa_g_hash_policy)
+ return 0;
+
if (!apparmor_tfm)
return 0;
diff -Nurp a/security/apparmor/lsm.c b/security/apparmor/lsm.c
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -692,6 +692,12 @@ enum profile_mode aa_g_profile_mode = AP
module_param_call(mode, param_set_mode, param_get_mode,
&aa_g_profile_mode, S_IRUSR | S_IWUSR);
+#ifdef CONFIG_SECURITY_APPARMOR_HASH
+/* whether policy verification hashing is enabled */
+bool aa_g_hash_policy =
IS_ENABLED(CONFIG_SECURITY_APPARMOR_HASH_DEFAULT);
+module_param_named(hash_policy, aa_g_hash_policy, aabool, S_IRUSR |
S_IWUSR);
+#endif
+
/* Debug mode */
bool aa_g_debug;
module_param_named(debug, aa_g_debug, aabool, S_IRUSR | S_IWUSR);
---
Hi Doug and Jason,
Mike and Ira have identified some fixes that they would like to see land in the
RC, these are serious problems and are marked as stable.
Changes since v1:
Update Lukasz' email address and fix subject tag.
---
Ira Weiny (1):
IB/hfi1: Fix SL array bounds check
Michael J. Ruhl (3):
IB/hfi1: Invalid user input can result in crash
IB/hfi1: Fix context recovery when PBC has an UnsupportedVL
IB/hfi1: Fix destroy_qp hang after a link down
drivers/infiniband/hw/hfi1/chip.c | 6 +++-
drivers/infiniband/hw/hfi1/pio.c | 51 ++++++++++++++++++++++++++------
drivers/infiniband/hw/hfi1/pio.h | 2 +
drivers/infiniband/hw/hfi1/user_sdma.c | 2 +
drivers/infiniband/hw/hfi1/verbs.c | 8 ++++-
5 files changed, 56 insertions(+), 13 deletions(-)
--
-Denny
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, usually by returning NULL from the best_encoder
callback which in turn, causes the atomic commit to fail.
However, this is wrong in a rather subtle way. If ->best_encoder()
returns NULL, this makes ALL modesets involving the connector fail. This
includes modesets from userspace that would shut off the CRTCs being
used by the connector. Since this results in blocking any changes to a
connector's DPMS prop, it has the sideaffect of preventing legacy
modesetting users from ever disabling a CRTC that was previously enabled
for use in an MST topology. An example of this, where X tries to
change the DPMS property of an MST connector that was just detached from
the system:
[ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6]
[ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] status updated from connected to disconnected
[ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] disconnected
[ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1)
[ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
...
[ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETPROPERTY
[ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state 000000007155ba49
[ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1)
[ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1)
[ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] 0000000097a6396e state to 000000007155ba49
[ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:41:head-0] to 000000007155ba49
[ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3)
[ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4)
[ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added [CONNECTOR:82:DP-6] 0000000087427144 state to 000000007155ba49
[ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 000000007155ba49
[ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:41:head-0] active changed
[ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:82:DP-6]
[ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No suitable encoder found for [CONNECTOR:82:DP-6]
[ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for 000000007155ba49 failed: -22
[ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000007155ba49
[ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4)
[ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3)
[ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2)
[ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2)
[ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state 000000007155ba49
[ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2)
[ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22
While this doesn't usually result in any errors that would be obvious to
the user, it does result in us leaving display resources on. This in
turn leads to unwanted sideaffects like inactive GPUs being left on
(usually from the resulting leaked runtime PM ref).
So, provide an easier way of doing this that doesn't require breaking
->best_encoder(): add a common drm_dp_mst_connector_atomic_check()
function that DRM drivers can call in order to have CRTC enabling
commits fail automatically if the MST port driving the connector no
longer exists. We'll also be able to expand upon this later as well once
we add MST fallback retraining support.
Changes since v1:
- Use list_for_each_entry_safe in drm_dp_mst_connector_still_exists() -
Julia Lawall
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: Julia Lawall <julia.lawall(a)lip6.fr>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++++++++++++++++++++++++++
include/drm/drm_dp_mst_helper.h | 3 ++
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7780567aa669..58b9554711c7 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3129,6 +3129,82 @@ static const struct drm_private_state_funcs mst_state_funcs = {
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+static bool
+drm_dp_mst_connector_still_exists(struct drm_connector *connector,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_port *port, *tmp;
+ bool exists = false;
+
+ mstb = drm_dp_get_validated_mstb_ref(mgr, mstb);
+ if (!mstb)
+ return false;
+
+ list_for_each_entry_safe(port, tmp, &mstb->ports, next) {
+ port = drm_dp_get_validated_port_ref(mgr, port);
+ if (!port)
+ continue;
+
+ exists = (port->connector == connector ||
+ (port->mstb &&
+ drm_dp_mst_connector_still_exists(connector, mgr,
+ port->mstb)));
+
+ drm_dp_put_port(port);
+ if (exists)
+ break;
+ }
+
+ drm_dp_put_mst_branch_device(mstb);
+ return exists;
+}
+
+/**
+ * drm_dp_mst_connector_atomic_check - Helper for validating a new atomic
+ * state on an MST connector
+ * @connector: drm connector
+ * @connector_state: the new atomic state of @connector
+ * @mgr: the MST topology mgr for @connector
+ *
+ * This function performs various atomic checks that apply to all drivers
+ * using the DRM DP MST helpers. This should be called by all drivers at the
+ * start of the atomic_check function for their MST connectors.
+ *
+ * Return 0 for success, or negative error code on failure.
+ */
+int
+drm_dp_mst_connector_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *connector_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_atomic_state *state = connector_state->state;
+ struct drm_crtc *crtc = connector_state->crtc;
+ struct drm_crtc_state *new_crtc_state;
+
+ if (!crtc)
+ return 0;
+
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (!new_crtc_state)
+ return 0;
+
+ if (!drm_atomic_crtc_needs_modeset(new_crtc_state) ||
+ !new_crtc_state->active)
+ return 0;
+
+ /* Make sure that the port for this MST connector still exists */
+ if (!drm_dp_mst_connector_still_exists(connector, mgr,
+ mgr->mst_primary)) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] has disappeared from the MST topology\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_mst_connector_atomic_check);
+
/**
* drm_atomic_get_mst_topology_state: get MST topology state
*
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 7f78d26a0766..8e33c2c85d1e 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -625,6 +625,9 @@ void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr);
int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
+int drm_dp_mst_connector_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *connector_state,
+ struct drm_dp_mst_topology_mgr *mgr);
int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port, int pbn);
--
2.17.1
Currently the way that we prevent userspace from performing new modesets
on MST connectors that have just been destroyed is rather broken.
There's nothing in the actual DRM DP MST topology helpers that checks
whether or not a connector still exists, instead each DRM driver does
this on it's own, usually by returning NULL from the best_encoder
callback which in turn, causes the atomic commit to fail.
However, this is wrong in a rather subtle way. If ->best_encoder()
returns NULL, this makes ALL modesets involving the connector fail. This
includes modesets from userspace that would shut off the CRTCs being
used by the connector. Since this results in blocking any changes to a
connector's DPMS prop, it has the sideaffect of preventing legacy
modesetting users from ever disabling a CRTC that was previously enabled
for use in an MST topology. An example of this, where X tries to
change the DPMS property of an MST connector that was just detached from
the system:
[ 2908.320131] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6]
[ 2908.320148] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] status updated from connected to disconnected
[ 2908.320166] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:82:DP-6] disconnected
[ 2908.320193] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 111 (1)
[ 2908.320230] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
...
[ 2908.638539] [drm:drm_ioctl [drm]] pid=12928, dev=0xe201, auth=1, DRM_IOCTL_MODE_SETPROPERTY
[ 2908.638546] [drm:drm_atomic_state_init [drm]] Allocated atomic state 000000007155ba49
[ 2908.638553] [drm:drm_mode_object_get [drm]] OBJ ID: 114 (1)
[ 2908.638560] [drm:drm_mode_object_get [drm]] OBJ ID: 108 (1)
[ 2908.638568] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:41:head-0] 0000000097a6396e state to 000000007155ba49
[ 2908.638575] [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:41:head-0] to 000000007155ba49
[ 2908.638582] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (3)
[ 2908.638589] [drm:drm_mode_object_get [drm]] OBJ ID: 82 (4)
[ 2908.638596] [drm:drm_atomic_get_connector_state [drm]] Added [CONNECTOR:82:DP-6] 0000000087427144 state to 000000007155ba49
[ 2908.638603] [drm:drm_atomic_check_only [drm]] checking 000000007155ba49
[ 2908.638609] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CRTC:41:head-0] active changed
[ 2908.638613] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:82:DP-6]
[ 2908.638616] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] No suitable encoder found for [CONNECTOR:82:DP-6]
[ 2908.638623] [drm:drm_atomic_check_only [drm]] atomic driver check for 000000007155ba49 failed: -22
[ 2908.638630] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000007155ba49
[ 2908.638637] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (4)
[ 2908.638643] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (3)
[ 2908.638650] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 114 (2)
[ 2908.638656] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 108 (2)
[ 2908.638663] [drm:__drm_atomic_state_free [drm]] Freeing atomic state 000000007155ba49
[ 2908.638669] [drm:drm_mode_object_put.part.2 [drm]] OBJ ID: 82 (2)
[ 2908.638676] [drm:drm_ioctl [drm]] pid=12928, ret = -22
While this doesn't usually result in any errors that would be obvious to
the user, it does result in us leaving display resources on. This in
turn leads to unwanted sideaffects like inactive GPUs being left on
(usually from the resulting leaked runtime PM ref).
So, provide an easier way of doing this that doesn't require breaking
->best_encoder(): add a common drm_dp_mst_connector_atomic_check()
function that DRM drivers can call in order to have CRTC enabling
commits fail automatically if the MST port driving the connector no
longer exists. We'll also be able to expand upon this later as well once
we add MST fallback retraining support.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++++++++++++++++++++++++++
include/drm/drm_dp_mst_helper.h | 3 ++
2 files changed, 79 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
index 7780567aa669..0162d4bf2549 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3129,6 +3129,82 @@ static const struct drm_private_state_funcs mst_state_funcs = {
.atomic_destroy_state = drm_dp_mst_destroy_state,
};
+static bool
+drm_dp_mst_connector_still_exists(struct drm_connector *connector,
+ struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_branch *mstb)
+{
+ struct drm_dp_mst_port *port;
+ bool exists = false;
+
+ mstb = drm_dp_get_validated_mstb_ref(mgr, mstb);
+ if (!mstb)
+ return false;
+
+ list_for_each_entry(port, &mstb->ports, next) {
+ port = drm_dp_get_validated_port_ref(mgr, port);
+ if (!port)
+ continue;
+
+ exists = (port->connector == connector ||
+ (port->mstb &&
+ drm_dp_mst_connector_still_exists(connector, mgr,
+ port->mstb)));
+
+ drm_dp_put_port(port);
+ if (exists)
+ break;
+ }
+
+ drm_dp_put_mst_branch_device(mstb);
+ return exists;
+}
+
+/**
+ * drm_dp_mst_connector_atomic_check - Helper for validating a new atomic
+ * state on an MST connector
+ * @connector: drm connector
+ * @connector_state: the new atomic state of @connector
+ * @mgr: the MST topology mgr for @connector
+ *
+ * This function performs various atomic checks that apply to all drivers
+ * using the DRM DP MST helpers. This should be called by all drivers at the
+ * start of the atomic_check function for their MST connectors.
+ *
+ * Return 0 for success, or negative error code on failure.
+ */
+int
+drm_dp_mst_connector_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *connector_state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_atomic_state *state = connector_state->state;
+ struct drm_crtc *crtc = connector_state->crtc;
+ struct drm_crtc_state *new_crtc_state;
+
+ if (!crtc)
+ return 0;
+
+ new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+ if (!new_crtc_state)
+ return 0;
+
+ if (!drm_atomic_crtc_needs_modeset(new_crtc_state) ||
+ !new_crtc_state->active)
+ return 0;
+
+ /* Make sure that the port for this MST connector still exists */
+ if (!drm_dp_mst_connector_still_exists(connector, mgr,
+ mgr->mst_primary)) {
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] has disappeared from the MST topology\n",
+ connector->base.id, connector->name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_dp_mst_connector_atomic_check);
+
/**
* drm_atomic_get_mst_topology_state: get MST topology state
*
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 7f78d26a0766..8e33c2c85d1e 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -625,6 +625,9 @@ void drm_dp_mst_topology_mgr_suspend(struct drm_dp_mst_topology_mgr *mgr);
int drm_dp_mst_topology_mgr_resume(struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
+int drm_dp_mst_connector_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *connector_state,
+ struct drm_dp_mst_topology_mgr *mgr);
int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port, int pbn);
--
2.17.1
On Thu, 20 Sep 2018, Evan Green wrote:
> On Thu, Aug 30, 2018 at 7:29 AM Thomas Gleixner <tglx(a)linutronix.de> wrote:
> >
> > On Thu, 30 Aug 2018, John Crispin wrote:
> >
> > > > Sry, that disturbing you all, but what are the conclusion here for 4.14.y?
> > > > - take Thomas's patch https://lore.kernel.org/patchwork/patch/969521/#1162900
> > > > - revert commit 2d898915ccf4838c04531c51a598469e921a5eb5
> > >
> > > Hi Frederic,
> > >
> > > I reported this very issue to tglx last night and he asked me to verify his
> > > proposed patch which i just did. I can confirm the the patch fixes the issue
> > > on 4.14.67 and Greg should add it to the stable queue please.
> > >
> > > Tested-by: John Crispin <john(a)phrozen.org>
> >
> > Let me whip up a proper patch with changelog.
> >
> Hi Thomas,
> Did this patch ever go anywhere? I believe it fixes the prints I'm
> seeing in our kernel, and I wondered if the official patch was
> somewhere.
It's out there:
https://lore.kernel.org/patchwork/patch/979451/
I assume that it has fallen through the stable cracks.
Thanks,
tglx
Hi Doug and Jason,
Mike and Ira have identified some fixes that they would like to see land in the
RC, these are serious problems and are marked as stable.
---
Ira Weiny (1):
IB/hfi1: Fix SL array bounds check
Michael J. Ruhl (3):
IB/hfi1: Invalid user input can result in crash
IB/hfi1: Fix context recovery when PBC has an UnsupportedVL
IB/hfi1: Fix destroy_qp hang after a link down
drivers/infiniband/hw/hfi1/chip.c | 6 +++-
drivers/infiniband/hw/hfi1/pio.c | 51 ++++++++++++++++++++++++++------
drivers/infiniband/hw/hfi1/pio.h | 2 +
drivers/infiniband/hw/hfi1/user_sdma.c | 2 +
drivers/infiniband/hw/hfi1/verbs.c | 8 ++++-
5 files changed, 56 insertions(+), 13 deletions(-)
--
-Denny
From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Subject: fork: report pid exhaustion correctly
Make the clone and fork syscalls return EAGAIN when the limit on the
number of pids /proc/sys/kernel/pid_max is exceeded.
Currently, when the pid_max limit is exceeded, the kernel will return
ENOSPC from the fork and clone syscalls. This is contrary to the
documented behaviour, which explicitly calls out the pid_max case as one
where EAGAIN should be returned. It also leads to really confusing error
messages in userspace programs which will complain about a lack of disk
space when they fail to create processes/threads for this reason.
This error is being returned because alloc_pid() uses the idr api to find
a new pid; when there are none available, idr_alloc_cyclic() returns
-ENOSPC, and this is being propagated back to userspace.
This behaviour has been broken before, and was explicitly fixed in
commit 35f71bc0a09a ("fork: report pid reservation failure properly"),
so I think -EAGAIN is definitely the right thing to return in this case.
The current behaviour change dates from commit 95846ecf9dac ("pid:
replace pid bitmap implementation with IDR AIP") and was I believe
unintentional.
This patch has no impact on the case where allocating a pid fails because
the child reaper for the namespace is dead; that case will still return
-ENOMEM.
Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP")
Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Gargi Sharma <gs051095(a)gmail.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c
--- a/kernel/pid.c~fork-report-pid-exhaustion-correctly
+++ a/kernel/pid.c
@@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa
idr_preload_end();
if (nr < 0) {
- retval = nr;
+ retval = (nr == -ENOSPC) ? -EAGAIN : nr;
goto out_free;
}
_
From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Subject: fork: report pid exhaustion correctly
Make the clone and fork syscalls return EAGAIN when the limit on the
number of pids /proc/sys/kernel/pid_max is exceeded.
Currently, when the pid_max limit is exceeded, the kernel will return
ENOSPC from the fork and clone syscalls. This is contrary to the
documented behaviour, which explicitly calls out the pid_max case as one
where EAGAIN should be returned. It also leads to really confusing error
messages in userspace programs which will complain about a lack of disk
space when they fail to create processes/threads for this reason.
This error is being returned because alloc_pid() uses the idr api to find
a new pid; when there are none available, idr_alloc_cyclic() returns
-ENOSPC, and this is being propagated back to userspace.
This behaviour has been broken before, and was explicitly fixed in
commit 35f71bc0a09a ("fork: report pid reservation failure properly"),
so I think -EAGAIN is definitely the right thing to return in this case.
The current behaviour change dates from commit 95846ecf9dac ("pid:
replace pid bitmap implementation with IDR AIP") and was I believe
unintentional.
This patch has no impact on the case where allocating a pid fails because
the child reaper for the namespace is dead; that case will still return
-ENOMEM.
Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP")
Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Gargi Sharma <gs051095(a)gmail.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c
--- a/kernel/pid.c~fork-report-pid-exhaustion-correctly
+++ a/kernel/pid.c
@@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa
idr_preload_end();
if (nr < 0) {
- retval = nr;
+ retval = (nr == -ENOSPC) ? -EAGAIN : nr;
goto out_free;
}
_
From: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Subject: fork: report pid exhaustion correctly
Make the clone and fork syscalls return EAGAIN when the limit on the
number of pids /proc/sys/kernel/pid_max is exceeded.
Currently, when the pid_max limit is exceeded, the kernel will return
ENOSPC from the fork and clone syscalls. This is contrary to the
documented behaviour, which explicitly calls out the pid_max case as one
where EAGAIN should be returned. It also leads to really confusing error
messages in userspace programs which will complain about a lack of disk
space when they fail to create processes/threads for this reason.
This error is being returned because alloc_pid() uses the idr api to find
a new pid; when there are none available, idr_alloc_cyclic() returns
-ENOSPC, and this is being propagated back to userspace.
This behaviour has been broken before, and was explicitly fixed in
commit 35f71bc0a09a ("fork: report pid reservation failure properly"),
so I think -EAGAIN is definitely the right thing to return in this case.
The current behaviour change dates from commit 95846ecf9dac ("pid:
replace pid bitmap implementation with IDR AIP") and was I believe
unintentional.
This patch has no impact on the case where allocating a pid fails because
the child reaper for the namespace is dead; that case will still return
-ENOMEM.
Link: http://lkml.kernel.org/r/20180903111016.46461-1-ktsanaktsidis@zendesk.com
Fixes: 95846ecf9dac ("pid: replace pid bitmap implementation with IDR AIP")
Signed-off-by: KJ Tsanaktsidis <ktsanaktsidis(a)zendesk.com>
Reviewed-by: Andrew Morton <akpm(a)linux-foundation.org>
Acked-by: Michal Hocko <mhocko(a)suse.com>
Cc: Gargi Sharma <gs051095(a)gmail.com>
Cc: Rik van Riel <riel(a)redhat.com>
Cc: Oleg Nesterov <oleg(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
diff -puN kernel/pid.c~fork-report-pid-exhaustion-correctly kernel/pid.c
--- a/kernel/pid.c~fork-report-pid-exhaustion-correctly
+++ a/kernel/pid.c
@@ -195,7 +195,7 @@ struct pid *alloc_pid(struct pid_namespa
idr_preload_end();
if (nr < 0) {
- retval = nr;
+ retval = (nr == -ENOSPC) ? -EAGAIN : nr;
goto out_free;
}
_
The patch
regulator: fix crash caused by null driver data
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From fb6de923ca3358a91525552b4907d4cb38730bdd Mon Sep 17 00:00:00 2001
From: Yu Zhao <yuzhao(a)google.com>
Date: Wed, 19 Sep 2018 15:30:51 -0600
Subject: [PATCH] regulator: fix crash caused by null driver data
dev_set_drvdata() needs to be called before device_register()
exposes device to userspace. Otherwise kernel crashes after it
gets null pointer from dev_get_drvdata() when userspace tries
to access sysfs entries.
[Removed backtrace for length -- broonie]
Signed-off-by: Yu Zhao <yuzhao(a)google.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
drivers/regulator/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 90215f57270f..9577d8941846 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -4395,13 +4395,13 @@ regulator_register(const struct regulator_desc *regulator_desc,
!rdev->desc->fixed_uV)
rdev->is_switch = true;
+ dev_set_drvdata(&rdev->dev, rdev);
ret = device_register(&rdev->dev);
if (ret != 0) {
put_device(&rdev->dev);
goto unset_supplies;
}
- dev_set_drvdata(&rdev->dev, rdev);
rdev_init_debugfs(rdev);
/* try to resolve regulators supply since a new one was registered */
--
2.19.0
Tree/Branch: v4.4.157
Git describe: v4.4.157
Commit: d956091968 Linux 4.4.157
Build Time: 68 min 54 sec
Passed: 10 / 10 (100.00 %)
Failed: 0 / 10 ( 0.00 %)
Errors: 0
Warnings: 31
Section Mismatches: 0
-------------------------------------------------------------------------------
defconfigs with issues (other than build errors):
19 warnings 0 mismatches : arm64-allmodconfig
17 warnings 0 mismatches : x86_64-allmodconfig
-------------------------------------------------------------------------------
Warnings Summary: 31
3 warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI)
2 ../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 ../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
2 ../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2752 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:4759:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 6784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2304 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2552 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3248 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 2992 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5296 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv0367.c:3147:1: warning: the frame size of 4144 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/stv0367.c:2490:1: warning: the frame size of 3424 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2984 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2976 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4336 bytes is larger than 2048 bytes [-Wframe-larger-than=]
1 ../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4328 bytes is larger than 2048 bytes [-Wframe-larger-than=]
===============================================================================
Detailed per-defconfig build reports below:
-------------------------------------------------------------------------------
arm64-allmodconfig : PASS, 0 errors, 19 warnings, 0 section mismatches
Warnings:
warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI)
warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI)
warning: (IMA) selects TCG_CRB which has unmet direct dependencies (TCG_TPM && X86 && ACPI)
../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 2992 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2288 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3248 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5840 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 6784 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv0367.c:2490:1: warning: the frame size of 3424 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2976 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4336 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2720 bytes is larger than 2048 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
x86_64-allmodconfig : PASS, 0 errors, 17 warnings, 0 section mismatches
Warnings:
../drivers/media/dvb-frontends/stv090x.c:1858:1: warning: the frame size of 3008 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:2141:1: warning: the frame size of 2104 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:2513:1: warning: the frame size of 2304 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:4565:1: warning: the frame size of 2096 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1956:1: warning: the frame size of 3264 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1599:1: warning: the frame size of 5296 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1211:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:4250:1: warning: the frame size of 4832 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:4759:1: warning: the frame size of 2056 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:1168:1: warning: the frame size of 2080 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:2073:1: warning: the frame size of 2552 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:3095:1: warning: the frame size of 5864 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv090x.c:3436:1: warning: the frame size of 5280 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/stv0367.c:3147:1: warning: the frame size of 4144 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/cxd2841er.c:2401:1: warning: the frame size of 2984 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/media/dvb-frontends/cxd2841er.c:2282:1: warning: the frame size of 4328 bytes is larger than 2048 bytes [-Wframe-larger-than=]
../drivers/net/ethernet/rocker/rocker.c:2172:1: warning: the frame size of 2752 bytes is larger than 2048 bytes [-Wframe-larger-than=]
-------------------------------------------------------------------------------
Passed with no errors, warnings or mismatches:
arm64-allnoconfig
arm-multi_v5_defconfig
arm-multi_v7_defconfig
x86_64-defconfig
arm-allmodconfig
arm-allnoconfig
x86_64-allnoconfig
arm64-defconfig
This is a note to let you know that I've just added the patch titled
serial: imx: restore handshaking irq for imx1
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7e620984b62532783912312e334f3c48cdacbd5d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig(a)pengutronix.de>
Date: Thu, 20 Sep 2018 14:11:17 +0200
Subject: serial: imx: restore handshaking irq for imx1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Back in 2015 when irda was dropped from the driver imx1 was broken. This
change reintroduces the support for the third interrupt of the UART.
Fixes: afe9cbb1a6ad ("serial: imx: drop support for IRDA")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de>
Reviewed-by: Leonard Crestez <leonard.crestez(a)nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/imx.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 239c0fa2e981..0f67197a3783 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -2351,6 +2351,14 @@ static int imx_uart_probe(struct platform_device *pdev)
ret);
return ret;
}
+
+ ret = devm_request_irq(&pdev->dev, rtsirq, imx_uart_rtsint, 0,
+ dev_name(&pdev->dev), sport);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to request rts irq: %d\n",
+ ret);
+ return ret;
+ }
} else {
ret = devm_request_irq(&pdev->dev, rxirq, imx_uart_int, 0,
dev_name(&pdev->dev), sport);
--
2.19.0
In commit 66cffd6daab7 ("b43: fix transmit failure when VT is switched"),
a condition is noted where the network controller needs to be reset. Note
that this situation happens when running the open-source firmware
(http://netweb.ing.unibs.it/~openfwwf/), plus a number of other special
conditions.
for a different card model, it is reported that this change breaks
operation running the proprietary firmware
(https://marc.info/?l=linux-wireless&m=153504546924558&w=2). Rather
than reverting the previous patch, the code is tweaked to avoid the
reset unless the open-source firmware is being used.
Fixes: 66cffd6daab7 ("b43: fix transmit failure when VT is switched")
Cc: Stable <stable(a)vger.kernel.org> # 4.18+
Cc: Taketo Kabe <kabe(a)sra-tohoku.co.jp>
Reported-and-tested-by: D. Prabhu <d.praabhu(a)gmail.com>
Signed-off-by: Larry Finger <Larry.Finger(a)lwfinger.net>
---
drivers/net/wireless/broadcom/b43/dma.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/dma.c b/drivers/net/wireless/broadcom/b43/dma.c
index 6b0e1ec346cb..d46d57b989ae 100644
--- a/drivers/net/wireless/broadcom/b43/dma.c
+++ b/drivers/net/wireless/broadcom/b43/dma.c
@@ -1518,13 +1518,15 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev,
}
} else {
/* More than a single header/data pair were missed.
- * Report this error, and reset the controller to
+ * Report this error. If running with open-source
+ * firmware, then reset the controller to
* revive operation.
*/
b43dbg(dev->wl,
"Out of order TX status report on DMA ring %d. Expected %d, but got %d\n",
ring->index, firstused, slot);
- b43_controller_restart(dev, "Out of order TX");
+ if (dev->fw.opensource)
+ b43_controller_restart(dev, "Out of order TX");
return;
}
}
--
2.18.0
This is a note to let you know that I've just added the patch titled
usb: core: safely deal with the dynamic quirk lists
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 16c4cb19fa85c648a803752eb63cac0ef69231c2 Mon Sep 17 00:00:00 2001
From: Harry Pan <harry.pan(a)intel.com>
Date: Fri, 14 Sep 2018 16:58:16 +0800
Subject: usb: core: safely deal with the dynamic quirk lists
Applying dynamic usbcore quirks in early booting when the slab is
not yet ready would cause kernel panic of null pointer dereference
because the quirk_count has been counted as 1 while the quirk_list
was failed to allocate.
i.e.,
[ 1.044970] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 1.044995] IP: [<ffffffffb0953ec7>] usb_detect_quirks+0x88/0xd1
[ 1.045016] PGD 0
[ 1.045026] Oops: 0000 [#1] PREEMPT SMP
[ 1.046986] gsmi: Log Shutdown Reason 0x03
[ 1.046995] Modules linked in:
[ 1.047008] CPU: 0 PID: 81 Comm: kworker/0:3 Not tainted 4.4.154 #28
[ 1.047016] Hardware name: Google Coral/Coral, BIOS Google_Coral.10068.27.0 12/04/2017
[ 1.047028] Workqueue: usb_hub_wq hub_event
[ 1.047037] task: ffff88017a321c80 task.stack: ffff88017a384000
[ 1.047044] RIP: 0010:[<ffffffffb0953ec7>] [<ffffffffb0953ec7>] usb_detect_quirks+0x88/0xd1
To tackle this odd, let's balance the quirk_count to 0 when the kcalloc
call fails, and defer the quirk setting into a lower level callback
which ensures that the kernel memory management has been initialized.
Fixes: 027bd6cafd9a ("usb: core: Add "quirks" parameter for usbcore")
Signed-off-by: Harry Pan <harry.pan(a)intel.com>
Acked-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index e77dfe5ed5ec..178d6c6063c0 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -58,6 +58,7 @@ static int quirks_param_set(const char *val, const struct kernel_param *kp)
quirk_list = kcalloc(quirk_count, sizeof(struct quirk_entry),
GFP_KERNEL);
if (!quirk_list) {
+ quirk_count = 0;
mutex_unlock(&quirk_mutex);
return -ENOMEM;
}
@@ -154,7 +155,7 @@ static struct kparam_string quirks_param_string = {
.string = quirks_param,
};
-module_param_cb(quirks, &quirks_param_ops, &quirks_param_string, 0644);
+device_param_cb(quirks, &quirks_param_ops, &quirks_param_string, 0644);
MODULE_PARM_DESC(quirks, "Add/modify USB quirks by specifying quirks=vendorID:productID:quirks");
/* Lists of quirky USB devices, split in device quirks and interface quirks.
--
2.19.0
This is a note to let you know that I've just added the patch titled
usb: roles: Take care of driver module reference counting
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 5c54fcac9a9de559b444ac63ec3cd82f1d157a0b Mon Sep 17 00:00:00 2001
From: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Date: Wed, 19 Sep 2018 10:58:05 +0300
Subject: usb: roles: Take care of driver module reference counting
This fixes potential "BUG: unable to handle kernel paging
request at ..." from happening.
Fixes: fde0aa6c175a ("usb: common: Small class for USB role switches")
Cc: <stable(a)vger.kernel.org>
Acked-by: Hans de Goede <hdegoede(a)redhat.com>
Tested-by: Hans de Goede <hdegoede(a)redhat.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/common/roles.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
index 15cc76e22123..99116af07f1d 100644
--- a/drivers/usb/common/roles.c
+++ b/drivers/usb/common/roles.c
@@ -109,8 +109,15 @@ static void *usb_role_switch_match(struct device_connection *con, int ep,
*/
struct usb_role_switch *usb_role_switch_get(struct device *dev)
{
- return device_connection_find_match(dev, "usb-role-switch", NULL,
- usb_role_switch_match);
+ struct usb_role_switch *sw;
+
+ sw = device_connection_find_match(dev, "usb-role-switch", NULL,
+ usb_role_switch_match);
+
+ if (!IS_ERR_OR_NULL(sw))
+ WARN_ON(!try_module_get(sw->dev.parent->driver->owner));
+
+ return sw;
}
EXPORT_SYMBOL_GPL(usb_role_switch_get);
@@ -122,8 +129,10 @@ EXPORT_SYMBOL_GPL(usb_role_switch_get);
*/
void usb_role_switch_put(struct usb_role_switch *sw)
{
- if (!IS_ERR_OR_NULL(sw))
+ if (!IS_ERR_OR_NULL(sw)) {
put_device(&sw->dev);
+ module_put(sw->dev.parent->driver->owner);
+ }
}
EXPORT_SYMBOL_GPL(usb_role_switch_put);
--
2.19.0
This is a note to let you know that I've just added the patch titled
USB: handle NULL config in usb_find_alt_setting()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From c9a4cb204e9eb7fa7dfbe3f7d3a674fa530aa193 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Mon, 10 Sep 2018 14:00:53 -0400
Subject: USB: handle NULL config in usb_find_alt_setting()
usb_find_alt_setting() takes a pointer to a struct usb_host_config as
an argument; it searches for an interface with specified interface and
alternate setting numbers in that config. However, it crashes if the
usb_host_config pointer argument is NULL.
Since this is a general-purpose routine, available for use in many
places, we want to to be more robust. This patch makes it return NULL
whenever the config argument is NULL.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: syzbot+19c3aaef85a89d451eac(a)syzkaller.appspotmail.com
CC: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/usb.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index 623be3174fb3..79d8bd7a612e 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -228,6 +228,8 @@ struct usb_host_interface *usb_find_alt_setting(
struct usb_interface_cache *intf_cache = NULL;
int i;
+ if (!config)
+ return NULL;
for (i = 0; i < config->desc.bNumInterfaces; i++) {
if (config->intf_cache[i]->altsetting[0].desc.bInterfaceNumber
== iface_num) {
--
2.19.0
This is a note to let you know that I've just added the patch titled
USB: fix error handling in usb_driver_claim_interface()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From bd729f9d67aa9a303d8925bb8c4f06af25f407d1 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Mon, 10 Sep 2018 13:59:59 -0400
Subject: USB: fix error handling in usb_driver_claim_interface()
The syzbot fuzzing project found a use-after-free bug in the USB
core. The bug was caused by usbfs not unbinding from an interface
when the USB device file was closed, which led another process to
attempt the unbind later on, after the private data structure had been
deallocated.
The reason usbfs did not unbind the interface at the appropriate time
was because it thought the interface had never been claimed in the
first place. This was caused by the fact that
usb_driver_claim_interface() does not clean up properly when
device_bind_driver() returns an error. Although the error code gets
passed back to the caller, the iface->dev.driver pointer remains set
and iface->condition remains equal to USB_INTERFACE_BOUND.
This patch adds proper error handling to usb_driver_claim_interface().
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Reported-by: syzbot+f84aa7209ccec829536f(a)syzkaller.appspotmail.com
CC: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/driver.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index 7652dcb57998..a1f225f077cd 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -550,6 +550,21 @@ int usb_driver_claim_interface(struct usb_driver *driver,
if (device_is_registered(dev))
retval = device_bind_driver(dev);
+ if (retval) {
+ dev->driver = NULL;
+ usb_set_intfdata(iface, NULL);
+ iface->needs_remote_wakeup = 0;
+ iface->condition = USB_INTERFACE_UNBOUND;
+
+ /*
+ * Unbound interfaces are always runtime-PM-disabled
+ * and runtime-PM-suspended
+ */
+ if (driver->supports_autosuspend)
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ }
+
return retval;
}
EXPORT_SYMBOL_GPL(usb_driver_claim_interface);
--
2.19.0
This is a note to let you know that I've just added the patch titled
USB: remove LPM management from usb_driver_claim_interface()
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From c183813fcee44a249339b7c46e1ad271ca1870aa Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Mon, 10 Sep 2018 13:58:51 -0400
Subject: USB: remove LPM management from usb_driver_claim_interface()
usb_driver_claim_interface() disables and re-enables Link Power
Management, but it shouldn't do either one, for the reasons listed
below. This patch removes the two LPM-related function calls from the
routine.
The reason for disabling LPM in the analogous function
usb_probe_interface() is so that drivers won't have to deal with
unwanted LPM transitions in their probe routine. But
usb_driver_claim_interface() doesn't call the driver's probe routine
(or any other callbacks), so that reason doesn't apply here.
Furthermore, no driver other than usbfs will ever call
usb_driver_claim_interface() unless it is already bound to another
interface in the same device, which means disabling LPM here would be
redundant. usbfs doesn't interact with LPM at all.
Lastly, the error return from usb_unlocked_disable_lpm() isn't handled
properly; the code doesn't clean up its earlier actions before
returning.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
Fixes: 8306095fd2c1 ("USB: Disable USB 3.0 LPM in critical sections.")
CC: <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/driver.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c
index e76e95f62f76..7652dcb57998 100644
--- a/drivers/usb/core/driver.c
+++ b/drivers/usb/core/driver.c
@@ -512,7 +512,6 @@ int usb_driver_claim_interface(struct usb_driver *driver,
struct device *dev;
struct usb_device *udev;
int retval = 0;
- int lpm_disable_error = -ENODEV;
if (!iface)
return -ENODEV;
@@ -533,16 +532,6 @@ int usb_driver_claim_interface(struct usb_driver *driver,
iface->condition = USB_INTERFACE_BOUND;
- /* See the comment about disabling LPM in usb_probe_interface(). */
- if (driver->disable_hub_initiated_lpm) {
- lpm_disable_error = usb_unlocked_disable_lpm(udev);
- if (lpm_disable_error) {
- dev_err(&iface->dev, "%s Failed to disable LPM for driver %s\n",
- __func__, driver->name);
- return -ENOMEM;
- }
- }
-
/* Claimed interfaces are initially inactive (suspended) and
* runtime-PM-enabled, but only if the driver has autosuspend
* support. Otherwise they are marked active, to prevent the
@@ -561,10 +550,6 @@ int usb_driver_claim_interface(struct usb_driver *driver,
if (device_is_registered(dev))
retval = device_bind_driver(dev);
- /* Attempt to re-enable USB3 LPM, if the disable was successful. */
- if (!lpm_disable_error)
- usb_unlocked_enable_lpm(udev);
-
return retval;
}
EXPORT_SYMBOL_GPL(usb_driver_claim_interface);
--
2.19.0
This is a note to let you know that I've just added the patch titled
USB: usbdevfs: sanitize flags more
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 7a68d9fb851012829c29e770621905529bd9490b Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Wed, 5 Sep 2018 12:07:02 +0200
Subject: USB: usbdevfs: sanitize flags more
Requesting a ZERO_PACKET or not is sensible only for output.
In the input direction the device decides.
Likewise accepting short packets makes sense only for input.
This allows operation with panic_on_warn without opening up
a local DOS.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Reported-by: syzbot+843efa30c8821bd69f53(a)syzkaller.appspotmail.com
Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/devio.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 6ce77b33da61..263dd2f309fb 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1434,10 +1434,13 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
struct async *as = NULL;
struct usb_ctrlrequest *dr = NULL;
unsigned int u, totlen, isofrmlen;
- int i, ret, is_in, num_sgs = 0, ifnum = -1;
+ int i, ret, num_sgs = 0, ifnum = -1;
int number_of_packets = 0;
unsigned int stream_id = 0;
void *buf;
+ bool is_in;
+ bool allow_short = false;
+ bool allow_zero = false;
unsigned long mask = USBDEVFS_URB_SHORT_NOT_OK |
USBDEVFS_URB_BULK_CONTINUATION |
USBDEVFS_URB_NO_FSBR |
@@ -1471,6 +1474,8 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
u = 0;
switch (uurb->type) {
case USBDEVFS_URB_TYPE_CONTROL:
+ if (is_in)
+ allow_short = true;
if (!usb_endpoint_xfer_control(&ep->desc))
return -EINVAL;
/* min 8 byte setup packet */
@@ -1511,6 +1516,10 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
break;
case USBDEVFS_URB_TYPE_BULK:
+ if (!is_in)
+ allow_zero = true;
+ else
+ allow_short = true;
switch (usb_endpoint_type(&ep->desc)) {
case USB_ENDPOINT_XFER_CONTROL:
case USB_ENDPOINT_XFER_ISOC:
@@ -1531,6 +1540,10 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
if (!usb_endpoint_xfer_int(&ep->desc))
return -EINVAL;
interrupt_urb:
+ if (!is_in)
+ allow_zero = true;
+ else
+ allow_short = true;
break;
case USBDEVFS_URB_TYPE_ISO:
@@ -1676,9 +1689,9 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
u = (is_in ? URB_DIR_IN : URB_DIR_OUT);
if (uurb->flags & USBDEVFS_URB_ISO_ASAP)
u |= URB_ISO_ASAP;
- if (uurb->flags & USBDEVFS_URB_SHORT_NOT_OK && is_in)
+ if (allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
u |= URB_SHORT_NOT_OK;
- if (uurb->flags & USBDEVFS_URB_ZERO_PACKET)
+ if (allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
u |= URB_ZERO_PACKET;
if (uurb->flags & USBDEVFS_URB_NO_INTERRUPT)
u |= URB_NO_INTERRUPT;
--
2.19.0
This is a note to let you know that I've just added the patch titled
USB: usbdevfs: restore warning for nonsensical flags
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 81e0403b26d94360abd1f6a57311337973bc82cd Mon Sep 17 00:00:00 2001
From: Oliver Neukum <oneukum(a)suse.com>
Date: Wed, 5 Sep 2018 12:07:03 +0200
Subject: USB: usbdevfs: restore warning for nonsensical flags
If we filter flags before they reach the core we need to generate our
own warnings.
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Fixes: 0cb54a3e47cb ("USB: debugging code shouldn't alter control flow")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/devio.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
index 263dd2f309fb..244417d0dfd1 100644
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1697,6 +1697,11 @@ static int proc_do_submiturb(struct usb_dev_state *ps, struct usbdevfs_urb *uurb
u |= URB_NO_INTERRUPT;
as->urb->transfer_flags = u;
+ if (!allow_short && uurb->flags & USBDEVFS_URB_SHORT_NOT_OK)
+ dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_SHORT_NOT_OK.\n");
+ if (!allow_zero && uurb->flags & USBDEVFS_URB_ZERO_PACKET)
+ dev_warn(&ps->dev->dev, "Requested nonsensical USBDEVFS_URB_ZERO_PACKET.\n");
+
as->urb->transfer_buffer_length = uurb->buffer_length;
as->urb->setup_packet = (unsigned char *)dr;
dr = NULL;
--
2.19.0
This is a note to let you know that I've just added the patch titled
Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e871db8d78df1c411032cbb3acfdf8930509360e Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Date: Tue, 11 Sep 2018 10:00:44 +0200
Subject: Revert "usb: cdc-wdm: Fix a sleep-in-atomic-context bug in
service_outstanding_interrupt()"
This reverts commit 6e22e3af7bb3a7b9dc53cb4687659f6e63fca427.
The bug the patch describes to, has been already fixed in commit
2df6948428542 ("USB: cdc-wdm: don't enable interrupts in USB-giveback")
so need to this, revert it.
Fixes: 6e22e3af7bb3 ("usb: cdc-wdm: Fix a sleep-in-atomic-context bug in service_outstanding_interrupt()")
Cc: stable <stable(a)vger.kernel.org>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy(a)linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/class/cdc-wdm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
index 656d247819c9..bec581fb7c63 100644
--- a/drivers/usb/class/cdc-wdm.c
+++ b/drivers/usb/class/cdc-wdm.c
@@ -460,7 +460,7 @@ static int service_outstanding_interrupt(struct wdm_device *desc)
set_bit(WDM_RESPONDING, &desc->flags);
spin_unlock_irq(&desc->iuspin);
- rv = usb_submit_urb(desc->response, GFP_ATOMIC);
+ rv = usb_submit_urb(desc->response, GFP_KERNEL);
spin_lock_irq(&desc->iuspin);
if (rv) {
dev_err(&desc->intf->dev,
--
2.19.0
Hello Greg,
Can you please consider including the following patch in the stable
linux-4.14.y branch?
This is to fix a defect in the Hyper-V network driver (hv_netsvc) that
triggers kernel null pointer dereference bug, while loading the driver.
b19b46346f48("hv/netvsc: Fix NULL dereference at single queue mode fallback")
Thanks
Alakesh Haloi
From: Anson Huang <Anson.Huang(a)nxp.com>
[ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ]
When thermal zone is in passive mode, disabling its mode from
sysfs is NOT taking effect at all, it is still polling the
temperature of the disabled thermal zone and handling all thermal
trips, it makes user confused. The disabling operation should
disable the thermal zone behavior completely, for both active and
passive mode, this patch clears the passive_delay when thermal
zone is disabled and restores it when it is enabled.
Signed-off-by: Anson Huang <Anson.Huang(a)nxp.com>
Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/thermal/of-thermal.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index 62143ba31001..3aeb476c2894 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -209,10 +209,13 @@ static int of_thermal_set_mode(struct thermal_zone_device *tz,
mutex_lock(&tz->lock);
- if (mode == THERMAL_DEVICE_ENABLED)
+ if (mode == THERMAL_DEVICE_ENABLED) {
tz->polling_delay = data->polling_delay;
- else
+ tz->passive_delay = data->passive_delay;
+ } else {
tz->polling_delay = 0;
+ tz->passive_delay = 0;
+ }
mutex_unlock(&tz->lock);
--
2.17.1
From: Anson Huang <Anson.Huang(a)nxp.com>
[ Upstream commit 152395fd03d4ce1e535a75cdbf58105e50587611 ]
When thermal zone is in passive mode, disabling its mode from
sysfs is NOT taking effect at all, it is still polling the
temperature of the disabled thermal zone and handling all thermal
trips, it makes user confused. The disabling operation should
disable the thermal zone behavior completely, for both active and
passive mode, this patch clears the passive_delay when thermal
zone is disabled and restores it when it is enabled.
Signed-off-by: Anson Huang <Anson.Huang(a)nxp.com>
Signed-off-by: Eduardo Valentin <edubezval(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/thermal/of-thermal.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
index be4eedcb839a..236c4eb5cf78 100644
--- a/drivers/thermal/of-thermal.c
+++ b/drivers/thermal/of-thermal.c
@@ -284,10 +284,13 @@ static int of_thermal_set_mode(struct thermal_zone_device *tz,
mutex_lock(&tz->lock);
- if (mode == THERMAL_DEVICE_ENABLED)
+ if (mode == THERMAL_DEVICE_ENABLED) {
tz->polling_delay = data->polling_delay;
- else
+ tz->passive_delay = data->passive_delay;
+ } else {
tz->polling_delay = 0;
+ tz->passive_delay = 0;
+ }
mutex_unlock(&tz->lock);
--
2.17.1
From: Tomer Tayar <Tomer.Tayar(a)cavium.com>
[ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ]
The MFW might be reset and re-update its shared memory.
Upon the detection of such a reset the driver rereads this memory, but it
has to wait till the data is valid.
This patch adds the missing wait for a data ready indication.
Signed-off-by: Tomer Tayar <Tomer.Tayar(a)cavium.com>
Signed-off-by: Ariel Elior <Ariel.Elior(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 50 +++++++++++++++++++----
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index eaa242df4131..a89385ba6b63 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -97,18 +97,57 @@ int qed_mcp_free(struct qed_hwfn *p_hwfn)
return 0;
}
+/* Maximum of 1 sec to wait for the SHMEM ready indication */
+#define QED_MCP_SHMEM_RDY_MAX_RETRIES 20
+#define QED_MCP_SHMEM_RDY_ITER_MS 50
+
static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
{
struct qed_mcp_info *p_info = p_hwfn->mcp_info;
+ u8 cnt = QED_MCP_SHMEM_RDY_MAX_RETRIES;
+ u8 msec = QED_MCP_SHMEM_RDY_ITER_MS;
u32 drv_mb_offsize, mfw_mb_offsize;
u32 mcp_pf_id = MCP_PF_ID(p_hwfn);
p_info->public_base = qed_rd(p_hwfn, p_ptt, MISC_REG_SHARED_MEM_ADDR);
- if (!p_info->public_base)
- return 0;
+ if (!p_info->public_base) {
+ DP_NOTICE(p_hwfn,
+ "The address of the MCP scratch-pad is not configured\n");
+ return -EINVAL;
+ }
p_info->public_base |= GRCBASE_MCP;
+ /* Get the MFW MB address and number of supported messages */
+ mfw_mb_offsize = qed_rd(p_hwfn, p_ptt,
+ SECTION_OFFSIZE_ADDR(p_info->public_base,
+ PUBLIC_MFW_MB));
+ p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id);
+ p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt,
+ p_info->mfw_mb_addr +
+ offsetof(struct public_mfw_mb,
+ sup_msgs));
+
+ /* The driver can notify that there was an MCP reset, and might read the
+ * SHMEM values before the MFW has completed initializing them.
+ * To avoid this, the "sup_msgs" field in the MFW mailbox is used as a
+ * data ready indication.
+ */
+ while (!p_info->mfw_mb_length && --cnt) {
+ msleep(msec);
+ p_info->mfw_mb_length =
+ (u16)qed_rd(p_hwfn, p_ptt,
+ p_info->mfw_mb_addr +
+ offsetof(struct public_mfw_mb, sup_msgs));
+ }
+
+ if (!cnt) {
+ DP_NOTICE(p_hwfn,
+ "Failed to get the SHMEM ready notification after %d msec\n",
+ QED_MCP_SHMEM_RDY_MAX_RETRIES * msec);
+ return -EBUSY;
+ }
+
/* Calculate the driver and MFW mailbox address */
drv_mb_offsize = qed_rd(p_hwfn, p_ptt,
SECTION_OFFSIZE_ADDR(p_info->public_base,
@@ -118,13 +157,6 @@ static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
"drv_mb_offsiz = 0x%x, drv_mb_addr = 0x%x mcp_pf_id = 0x%x\n",
drv_mb_offsize, p_info->drv_mb_addr, mcp_pf_id);
- /* Set the MFW MB address */
- mfw_mb_offsize = qed_rd(p_hwfn, p_ptt,
- SECTION_OFFSIZE_ADDR(p_info->public_base,
- PUBLIC_MFW_MB));
- p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id);
- p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt, p_info->mfw_mb_addr);
-
/* Get the current driver mailbox sequence before sending
* the first command
*/
--
2.17.1
From: Tomer Tayar <Tomer.Tayar(a)cavium.com>
[ Upstream commit f00d25f3154b676fcea4502a25b94bd7f142ca74 ]
The MFW might be reset and re-update its shared memory.
Upon the detection of such a reset the driver rereads this memory, but it
has to wait till the data is valid.
This patch adds the missing wait for a data ready indication.
Signed-off-by: Tomer Tayar <Tomer.Tayar(a)cavium.com>
Signed-off-by: Ariel Elior <Ariel.Elior(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/net/ethernet/qlogic/qed/qed_mcp.c | 50 +++++++++++++++++++----
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.c b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
index 3c469355f5a4..9348d367cfdf 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_mcp.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.c
@@ -182,18 +182,57 @@ int qed_mcp_free(struct qed_hwfn *p_hwfn)
return 0;
}
+/* Maximum of 1 sec to wait for the SHMEM ready indication */
+#define QED_MCP_SHMEM_RDY_MAX_RETRIES 20
+#define QED_MCP_SHMEM_RDY_ITER_MS 50
+
static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
{
struct qed_mcp_info *p_info = p_hwfn->mcp_info;
+ u8 cnt = QED_MCP_SHMEM_RDY_MAX_RETRIES;
+ u8 msec = QED_MCP_SHMEM_RDY_ITER_MS;
u32 drv_mb_offsize, mfw_mb_offsize;
u32 mcp_pf_id = MCP_PF_ID(p_hwfn);
p_info->public_base = qed_rd(p_hwfn, p_ptt, MISC_REG_SHARED_MEM_ADDR);
- if (!p_info->public_base)
- return 0;
+ if (!p_info->public_base) {
+ DP_NOTICE(p_hwfn,
+ "The address of the MCP scratch-pad is not configured\n");
+ return -EINVAL;
+ }
p_info->public_base |= GRCBASE_MCP;
+ /* Get the MFW MB address and number of supported messages */
+ mfw_mb_offsize = qed_rd(p_hwfn, p_ptt,
+ SECTION_OFFSIZE_ADDR(p_info->public_base,
+ PUBLIC_MFW_MB));
+ p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id);
+ p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt,
+ p_info->mfw_mb_addr +
+ offsetof(struct public_mfw_mb,
+ sup_msgs));
+
+ /* The driver can notify that there was an MCP reset, and might read the
+ * SHMEM values before the MFW has completed initializing them.
+ * To avoid this, the "sup_msgs" field in the MFW mailbox is used as a
+ * data ready indication.
+ */
+ while (!p_info->mfw_mb_length && --cnt) {
+ msleep(msec);
+ p_info->mfw_mb_length =
+ (u16)qed_rd(p_hwfn, p_ptt,
+ p_info->mfw_mb_addr +
+ offsetof(struct public_mfw_mb, sup_msgs));
+ }
+
+ if (!cnt) {
+ DP_NOTICE(p_hwfn,
+ "Failed to get the SHMEM ready notification after %d msec\n",
+ QED_MCP_SHMEM_RDY_MAX_RETRIES * msec);
+ return -EBUSY;
+ }
+
/* Calculate the driver and MFW mailbox address */
drv_mb_offsize = qed_rd(p_hwfn, p_ptt,
SECTION_OFFSIZE_ADDR(p_info->public_base,
@@ -203,13 +242,6 @@ static int qed_load_mcp_offsets(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt)
"drv_mb_offsiz = 0x%x, drv_mb_addr = 0x%x mcp_pf_id = 0x%x\n",
drv_mb_offsize, p_info->drv_mb_addr, mcp_pf_id);
- /* Set the MFW MB address */
- mfw_mb_offsize = qed_rd(p_hwfn, p_ptt,
- SECTION_OFFSIZE_ADDR(p_info->public_base,
- PUBLIC_MFW_MB));
- p_info->mfw_mb_addr = SECTION_ADDR(mfw_mb_offsize, mcp_pf_id);
- p_info->mfw_mb_length = (u16)qed_rd(p_hwfn, p_ptt, p_info->mfw_mb_addr);
-
/* Get the current driver mailbox sequence before sending
* the first command
*/
--
2.17.1
From: "Maciej W. Rozycki" <macro(a)mips.com>
[ Upstream commit 2f819db565e82e5f73cd42b39925098986693378 ]
The regset API documented in <linux/regset.h> defines -ENODEV as the
result of the `->active' handler to be used where the feature requested
is not available on the hardware found. However code handling core file
note generation in `fill_thread_core_info' interpretes any non-zero
result from the `->active' handler as the regset requested being active.
Consequently processing continues (and hopefully gracefully fails later
on) rather than being abandoned right away for the regset requested.
Fix the problem then by making the code proceed only if a positive
result is returned from the `->active' handler.
Signed-off-by: Maciej W. Rozycki <macro(a)mips.com>
Signed-off-by: Paul Burton <paul.burton(a)mips.com>
Fixes: 4206d3aa1978 ("elf core dump: notes user_regset")
Patchwork: https://patchwork.linux-mips.org/patch/19332/
Cc: Alexander Viro <viro(a)zeniv.linux.org.uk>
Cc: James Hogan <jhogan(a)kernel.org>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: linux-fsdevel(a)vger.kernel.org
Cc: linux-mips(a)linux-mips.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
fs/binfmt_elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 816cc921cf36..efae2fb0930a 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1751,7 +1751,7 @@ static int fill_thread_core_info(struct elf_thread_core_info *t,
const struct user_regset *regset = &view->regsets[i];
do_thread_regset_writeback(t->task, regset);
if (regset->core_note_type && regset->get &&
- (!regset->active || regset->active(t->task, regset))) {
+ (!regset->active || regset->active(t->task, regset) > 0)) {
int ret;
size_t size = regset_size(t->task, regset);
void *data = kmalloc(size, GFP_KERNEL);
--
2.17.1
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-longer-present MSTB ports by
changing the DPMS state to off and this still requires that we retrieve
an encoder.
So, fix this by always returning a valid encoder regardless of the state
of the MST port. Additionally, make intel_dp_mst_atomic_check() simply
rely on drm_dp_mst_connector_atomic_check() to prevent new modesets on
no-longer-present MSTB ports.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index a366f32b048a..2b798d4592f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -106,14 +106,21 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
}
static int intel_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+ struct drm_connector_state *new_conn_state)
{
struct drm_atomic_state *state = new_conn_state->state;
struct drm_connector_state *old_conn_state;
struct drm_crtc *old_crtc;
struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr =
+ &to_intel_connector(connector)->mst_port->mst_mgr;
int slots, ret = 0;
+ ret = drm_dp_mst_connector_atomic_check(connector, new_conn_state,
+ mgr);
+ if (ret)
+ return ret;
+
old_conn_state = drm_atomic_get_old_connector_state(state, connector);
old_crtc = old_conn_state->crtc;
if (!old_crtc)
@@ -122,12 +129,6 @@ static int intel_dp_mst_atomic_check(struct drm_connector *connector,
crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
- struct drm_dp_mst_topology_mgr *mgr;
- struct drm_encoder *old_encoder;
-
- old_encoder = old_conn_state->best_encoder;
- mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr;
-
ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
if (ret)
DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", slots, ret);
@@ -407,8 +408,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (intel_connector->mst_port_gone)
- return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
--
2.17.1
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to do in intel_dp_mst_compute_config() will fail with -EINVAL.
Since the only commits we want to allow on no-longer-present MST ports
are ones that shut off display hardware, we already know that no VCPI
allocations are needed. So, hardcode the VCPI slot count to 0 when
intel_dp_mst_compute_config() is called on an MST port that's gone.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index fcb9b87b9339..a366f32b048a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
- int lane_count, slots;
+ int lane_count, slots = 0;
const struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
@@ -76,11 +76,16 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
- slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
- connector->port, mst_pbn);
- if (slots < 0) {
- DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
- return false;
+ if (!connector->mst_port_gone) {
+ slots = drm_dp_atomic_find_vcpi_slots(state,
+ &intel_dp->mst_mgr,
+ connector->port,
+ mst_pbn);
+ if (slots < 0) {
+ DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+ return false;
+ }
}
intel_link_compute_m_n(bpp, lane_count,
--
2.17.1
Hello,
Niklas Cassle recently reported some regressions with his Qcom cpufreq
driver where he was getting some errors while creating the OPPs tables.
After looking into it I realized that the OPP core incorrectly creates
multiple OPP tables for the devices even if they are sharing the OPP
table in DT. This happens when the request comes using different CPU
devices. For example, dev_pm_opp_set_supported_hw() getting called using
CPU0 and dev_pm_opp_of_add_table() getting called using CPU1.
This series redesigns the internals of the OPP core to fix that. The
redesign has simplified the core itself though.
The first three patches are fixes really for the current code and the rest
of them are making necessary changes to fix the issue defined in
$subject here.
Nikklas already tested this series and his Tested-by is already applied
to series here. I would like to get this merged during the 4.20 merge
window and will push the series to linux-next soon to get more test
coverage. Please provide comments as soon as possible, else will send it
as part of the pull request to Rafael for 4.20.
--
viresh
V1->V2:
- Nikklas reported another regressions which is fixed by the 2nd commit
in this series.
Viresh Kumar (12):
OPP: Free OPP table properly on performance state irregularities
OPP: Don't try to remove all OPP tables on failure
OPP: Protect dev_list with opp_table lock
OPP: Pass index to _of_init_opp_table()
OPP: Parse OPP table's DT properties from _of_init_opp_table()
OPP: Don't take OPP table's kref for static OPPs
OPP: Create separate kref for static OPPs list
cpufreq: mvebu: Remove OPPs using dev_pm_opp_remove()
OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()
OPP: Use a single mechanism to free the OPP table
OPP: Prevent creating multiple OPP tables for devices sharing OPP
nodes
OPP: Pass OPP table to _of_add_opp_table_v{1|2}()
drivers/cpufreq/mvebu-cpufreq.c | 9 +-
drivers/opp/core.c | 147 ++++++++++++++++++++-----------
drivers/opp/cpu.c | 15 ++--
drivers/opp/of.c | 188 +++++++++++++++++++++-------------------
drivers/opp/opp.h | 19 ++--
include/linux/pm_opp.h | 6 ++
6 files changed, 226 insertions(+), 158 deletions(-)
--
2.14.1
Hello,
I don't think you can update the loop index variable in
list_for_each_entry, because the mcro uses th index variable to get to the
next element. Perhaps list_for_each_entry_safe would be more suitable?
julia
---------- Forwarded message ----------
Date: Thu, 20 Sep 2018 04:30:13 +0800
From: kbuild test robot <lkp(a)intel.com>
To: kbuild(a)01.org
Cc: Julia Lawall <julia.lawall(a)lip6.fr>
Subject: Re: [PATCH 1/6] drm/dp_mst: Introduce
drm_dp_mst_connector_atomic_check()
CC: kbuild-all(a)01.org
In-Reply-To: <20180918230637.20700-2-lyude(a)redhat.com>
References: <20180918230637.20700-2-lyude(a)redhat.com>
TO: Lyude Paul <lyude(a)redhat.com>
CC: dri-devel(a)lists.freedesktop.org, nouveau(a)lists.freedesktop.org, intel-gfx(a)lists.freedesktop.org, amd-gfx(a)lists.freedesktop.org
CC: David Airlie <airlied(a)linux.ie>, linux-kernel(a)vger.kernel.org, stable(a)vger.kernel.org, Sean Paul <sean(a)poorly.run>
Hi Lyude,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.19-rc4 next-20180919]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Lyude-Paul/Fix-legacy-DPMS-changes…
base: git://anongit.freedesktop.org/drm-intel for-linux-next
:::::: branch date: 8 hours ago
:::::: commit date: 8 hours ago
>> drivers/gpu/drm/drm_dp_mst_topology.c:3144:1-20: iterator with update on line 3145
# https://github.com/0day-ci/linux/commit/f8df31d5221b9a6da6698d4a37e622253bb…
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f8df31d5221b9a6da6698d4a37e622253bb17cdc
vim +3144 drivers/gpu/drm/drm_dp_mst_topology.c
3f3353b7 Pandiyan, Dhinakaran 2017-04-20 3131
f8df31d5 Lyude Paul 2018-09-18 3132 static bool
f8df31d5 Lyude Paul 2018-09-18 3133 drm_dp_mst_connector_still_exists(struct drm_connector *connector,
f8df31d5 Lyude Paul 2018-09-18 3134 struct drm_dp_mst_topology_mgr *mgr,
f8df31d5 Lyude Paul 2018-09-18 3135 struct drm_dp_mst_branch *mstb)
f8df31d5 Lyude Paul 2018-09-18 3136 {
f8df31d5 Lyude Paul 2018-09-18 3137 struct drm_dp_mst_port *port;
f8df31d5 Lyude Paul 2018-09-18 3138 bool exists = false;
f8df31d5 Lyude Paul 2018-09-18 3139
f8df31d5 Lyude Paul 2018-09-18 3140 mstb = drm_dp_get_validated_mstb_ref(mgr, mstb);
f8df31d5 Lyude Paul 2018-09-18 3141 if (!mstb)
f8df31d5 Lyude Paul 2018-09-18 3142 return false;
f8df31d5 Lyude Paul 2018-09-18 3143
f8df31d5 Lyude Paul 2018-09-18 @3144 list_for_each_entry(port, &mstb->ports, next) {
f8df31d5 Lyude Paul 2018-09-18 @3145 port = drm_dp_get_validated_port_ref(mgr, port);
f8df31d5 Lyude Paul 2018-09-18 3146 if (!port)
f8df31d5 Lyude Paul 2018-09-18 3147 continue;
f8df31d5 Lyude Paul 2018-09-18 3148
f8df31d5 Lyude Paul 2018-09-18 3149 exists = (port->connector == connector ||
f8df31d5 Lyude Paul 2018-09-18 3150 (port->mstb &&
f8df31d5 Lyude Paul 2018-09-18 3151 drm_dp_mst_connector_still_exists(connector, mgr,
f8df31d5 Lyude Paul 2018-09-18 3152 port->mstb)));
f8df31d5 Lyude Paul 2018-09-18 3153
f8df31d5 Lyude Paul 2018-09-18 3154 drm_dp_put_port(port);
f8df31d5 Lyude Paul 2018-09-18 3155 if (exists)
f8df31d5 Lyude Paul 2018-09-18 3156 break;
f8df31d5 Lyude Paul 2018-09-18 3157 }
f8df31d5 Lyude Paul 2018-09-18 3158
f8df31d5 Lyude Paul 2018-09-18 3159 drm_dp_put_mst_branch_device(mstb);
f8df31d5 Lyude Paul 2018-09-18 3160 return exists;
f8df31d5 Lyude Paul 2018-09-18 3161 }
f8df31d5 Lyude Paul 2018-09-18 3162
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hello,
Niklas Cassle recently reported some regressions with his Qcom cpufreq
driver where he was getting some errors while creating the OPPs tables.
After looking into it I realized that the OPP core incorrectly creates
multiple OPP tables for the devices even if they are sharing the OPP
table in DT. This happens when the request comes using different CPU
devices. For example, dev_pm_opp_set_supported_hw() getting called using
CPU0 and dev_pm_opp_of_add_table() getting called using CPU1.
This series redesigns the internals of the OPP core to fix that. The
redesign has simplified the core itself though.
@Niklas: Can you please confirm that this series fixes the issues you
have reported ? I have already tested it on Hikey960.
--
viresh
Viresh Kumar (11):
OPP: Free OPP table properly on performance state irregularities
OPP: Protect dev_list with opp_table lock
OPP: Pass index to _of_init_opp_table()
OPP: Parse OPP table's DT properties from _of_init_opp_table()
OPP: Don't take OPP table's kref for static OPPs
OPP: Create separate kref for static OPPs list
cpufreq: mvebu: Remove OPPs using dev_pm_opp_remove()
OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()
OPP: Use a single mechanism to free the OPP table
OPP: Prevent creating multiple OPP tables for devices sharing OPP
nodes
OPP: Pass OPP table to _of_add_opp_table_v{1|2}()
drivers/cpufreq/mvebu-cpufreq.c | 9 +-
drivers/opp/core.c | 147 ++++++++++++++++---------
drivers/opp/cpu.c | 11 +-
drivers/opp/of.c | 186 +++++++++++++++++---------------
drivers/opp/opp.h | 19 ++--
include/linux/pm_opp.h | 6 ++
6 files changed, 221 insertions(+), 157 deletions(-)
--
2.18.0.rc1.242.g61856ae69a2c
[ Upstream commit 0f02cfbc3d9e413d450d8d0fd660077c23f67eff ]
When a system suffers from dcache aliasing a user program may observe
stale VDSO data from an aliased cache line. Notably this can break the
expectation that clock_gettime(CLOCK_MONOTONIC, ...) is, as its name
suggests, monotonic.
In order to ensure that users observe updates to the VDSO data page as
intended, align the user mappings of the VDSO data page such that their
cache colouring matches that of the virtual address range which the
kernel will use to update the data page - typically its unmapped address
within kseg0.
This ensures that we don't introduce aliasing cache lines for the VDSO
data page, and therefore that userland will observe updates without
requiring cache invalidation.
Signed-off-by: Paul Burton <paul.burton(a)mips.com>
Reported-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Reported-by: Rene Nielsen <rene.nielsen(a)microsemi.com>
Reported-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Patchwork: https://patchwork.linux-mips.org/patch/20344/
Tested-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Tested-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Cc: James Hogan <jhogan(a)kernel.org>
Cc: linux-mips(a)linux-mips.org
Cc: stable(a)vger.kernel.org # v4.4+
---
arch/mips/kernel/vdso.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index f9dbfb14af33..e88344e3d508 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -14,12 +14,14 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/irqchip/mips-gic.h>
+#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/timekeeper_internal.h>
#include <asm/abi.h>
+#include <asm/page.h>
#include <asm/vdso.h>
/* Kernel-provided data used by the VDSO. */
@@ -129,12 +131,30 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
vvar_size = gic_size + PAGE_SIZE;
size = vvar_size + image->size;
+ /*
+ * Find a region that's large enough for us to perform the
+ * colour-matching alignment below.
+ */
+ if (cpu_has_dc_aliases)
+ size += shm_align_mask + 1;
+
base = get_unmapped_area(NULL, 0, size, 0, 0);
if (IS_ERR_VALUE(base)) {
ret = base;
goto out;
}
+ /*
+ * If we suffer from dcache aliasing, ensure that the VDSO data page
+ * mapping is coloured the same as the kernel's mapping of that memory.
+ * This ensures that when the kernel updates the VDSO data userland
+ * will observe it without requiring cache invalidations.
+ */
+ if (cpu_has_dc_aliases) {
+ base = __ALIGN_MASK(base, shm_align_mask);
+ base += ((unsigned long)&vdso_data - gic_size) & shm_align_mask;
+ }
+
data_addr = base + gic_size;
vdso_addr = data_addr + PAGE_SIZE;
--
2.18.0
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From b40b3e9358fbafff6a4ba0f4b9658f6617146f9c Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 11 Jul 2018 15:29:31 +0300
Subject: [PATCH] mei: bus: type promotion bug in mei_nfc_if_version()
We accidentally removed the check for negative returns
without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv()
returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.
Cc: <stable(a)vger.kernel.org>
Fixes: 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index e45fe826d87d..65e28be3c8cc 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -341,7 +341,7 @@ static int mei_nfc_if_version(struct mei_cl *cl,
ret = 0;
bytes_recv = __mei_cl_recv(cl, (u8 *)reply, if_version_length, 0, 0);
- if (bytes_recv < if_version_length) {
+ if (bytes_recv < 0 || bytes_recv < if_version_length) {
dev_err(bus->dev, "Could not read IF version\n");
ret = -EIO;
goto err;
Hi,
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v4.18.8, v4.14.70, v4.9.127, v4.4.156, v3.18.122,
v4.18.8: Build OK!
v4.14.70: Build OK!
v4.9.127: Build OK!
v4.4.156: Build OK!
v3.18.122: Build failed! Errors:
Please let us know how to resolve this.
--
Thanks,
Sasha
Linus (aka Greg),
Vaibhav Nagarnaik found that modifying the ring buffer size could cause
a huge latency in the system because it does a while loop to free pages
without releasing the CPU (on non preempt kernels). In a case where there
are hundreds of thousands of pages to free it could actually cause a system
stall. A properly place cond_resched() solves this issue.
Please pull the latest trace-v4.19-rc4 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v4.19-rc4
Tag SHA1: 977e4fb3741e24151a255ee13bd4a1224545ae4e
Head SHA1: 83f365554e47997ec68dc4eca3f5dce525cd15c3
Vaibhav Nagarnaik (1):
ring-buffer: Allow for rescheduling when removing pages
----
kernel/trace/ring_buffer.c | 2 ++
1 file changed, 2 insertions(+)
---------------------------
commit 83f365554e47997ec68dc4eca3f5dce525cd15c3
Author: Vaibhav Nagarnaik <vnagarnaik(a)google.com>
Date: Fri Sep 7 15:31:29 2018 -0700
ring-buffer: Allow for rescheduling when removing pages
When reducing ring buffer size, pages are removed by scheduling a work
item on each CPU for the corresponding CPU ring buffer. After the pages
are removed from ring buffer linked list, the pages are free()d in a
tight loop. The loop does not give up CPU until all pages are removed.
In a worst case behavior, when lot of pages are to be freed, it can
cause system stall.
After the pages are removed from the list, the free() can happen while
the work is rescheduled. Call cond_resched() in the loop to prevent the
system hangup.
Link: http://lkml.kernel.org/r/20180907223129.71994-1-vnagarnaik@google.com
Cc: stable(a)vger.kernel.org
Fixes: 83f40318dab00 ("ring-buffer: Make removal of ring buffer pages atomic")
Reported-by: Jason Behmer <jbehmer(a)google.com>
Signed-off-by: Vaibhav Nagarnaik <vnagarnaik(a)google.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 1d92d4a982fd..65bd4616220d 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -1546,6 +1546,8 @@ rb_remove_pages(struct ring_buffer_per_cpu *cpu_buffer, unsigned long nr_pages)
tmp_iter_page = first_page;
do {
+ cond_resched();
+
to_remove_page = tmp_iter_page;
rb_inc_page(cpu_buffer, &tmp_iter_page);
Hi There,
Im reaching out to you because Im interested in purchasing a backlink from your site.
The link will go to a high quality drug and alcohol rehabilitation information page.
Ive made a short video explaining exactly what Im looking for: http://mtrack.me/tracking/raWzMz50paMkCGD1BQRlZGV5AwLzMKWjqzA2pzSaqaR9AGV4A…
Ideally, the link will be placed in a relevant, existing post/page on your website.
Please let me know your rates as soon as possible.
Thank you for your time and consideration,
Andy Macia
(949) 467-1404
[Unsubscribe ] <http://mtrack.me/unsub/eng/raWzMz50paMkCGD1BQRlZGV5AwLzMKWjqzA2pzSaqaR9AGV4…>
From: Boris Brezillon <boris.brezillon(a)free-electrons.com>
In the current driver, OOB bytes are accessed in raw mode, and when a
page access is done with NDCR_SPARE_EN set and NDCR_ECC_EN cleared, the
driver must read the whole spare area (64 bytes in case of a 2k page,
16 bytes for a 512 page). The driver was only reading the free OOB
bytes, which was leaving some unread data in the FIFO and was somehow
leading to a timeout.
We could patch the driver to read ->spare_size + ->ecc_size instead of
just ->spare_size when READOOB is requested, but we'd better make
in-band and OOB accesses consistent.
Since the driver is always accessing in-band data in non-raw mode (with
the ECC engine enabled), we should also access OOB data in this mode.
That's particularly useful when using the BCH engine because in this
mode the free OOB bytes are also ECC protected.
Fixes: 43bcfd2bb24a ("mtd: nand: pxa3xx: Add driver-specific ECC BCH support")
Cc: stable(a)vger.kernel.org
Reported-by: Sean Nyekjær <sean.nyekjaer(a)prevas.dk>
Tested-by: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com>
Acked-by: Ezequiel Garcia <ezequiel(a)vanguardiasur.com.ar>
Tested-by: Sean Nyekjaer <sean.nyekjaer(a)prevas.dk>
Acked-by: Robert Jarzmik <robert.jarzmik(a)free.fr>
Signed-off-by: Richard Weinberger <richard(a)nod.at>
Signed-off-by: Ofer Heifetz <oferh(a)marvell.com>
Reviewed-by: Igal Liberman <igall(a)marvell.com>
Cc: Stefan Roese <sr(a)denx.de>
Cc: Simon Glass <sjg(a)chromium.org>
---
drivers/mtd/nand/pxa3xx_nand.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index b64dd0d..c1f7d61 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
@@ -750,6 +750,7 @@ static void prepare_start_command(struct pxa3xx_nand_info *info, int command)
switch (command) {
case NAND_CMD_READ0:
+ case NAND_CMD_READOOB:
case NAND_CMD_PAGEPROG:
info->use_ecc = 1;
break;
--
2.7.4
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on no-longer-present MSTB ports by
changing the DPMS state to off and this still requires that we retrieve
an encoder.
So, fix this by always returning a valid encoder regardless of the state
of the MST port. Additionally, make intel_dp_mst_atomic_check() simply
rely on drm_dp_mst_connector_atomic_check() to prevent new modesets on
no-longer-present MSTB ports.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 ++++++++---------
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index a366f32b048a..2b798d4592f0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -106,14 +106,21 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
}
static int intel_dp_mst_atomic_check(struct drm_connector *connector,
- struct drm_connector_state *new_conn_state)
+ struct drm_connector_state *new_conn_state)
{
struct drm_atomic_state *state = new_conn_state->state;
struct drm_connector_state *old_conn_state;
struct drm_crtc *old_crtc;
struct drm_crtc_state *crtc_state;
+ struct drm_dp_mst_topology_mgr *mgr =
+ &to_intel_connector(connector)->mst_port->mst_mgr;
int slots, ret = 0;
+ ret = drm_dp_mst_connector_atomic_check(connector, new_conn_state,
+ mgr);
+ if (ret)
+ return ret;
+
old_conn_state = drm_atomic_get_old_connector_state(state, connector);
old_crtc = old_conn_state->crtc;
if (!old_crtc)
@@ -122,12 +129,6 @@ static int intel_dp_mst_atomic_check(struct drm_connector *connector,
crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
- struct drm_dp_mst_topology_mgr *mgr;
- struct drm_encoder *old_encoder;
-
- old_encoder = old_conn_state->best_encoder;
- mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr;
-
ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
if (ret)
DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", slots, ret);
@@ -407,8 +408,6 @@ static struct drm_encoder *intel_mst_atomic_best_encoder(struct drm_connector *c
struct intel_dp *intel_dp = intel_connector->mst_port;
struct intel_crtc *crtc = to_intel_crtc(state->crtc);
- if (intel_connector->mst_port_gone)
- return NULL;
return &intel_dp->mst_encoders[crtc->pipe]->base.base;
}
--
2.17.1
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try to do in intel_dp_mst_compute_config() will fail with -EINVAL.
Since the only commits we want to allow on no-longer-present MST ports
are ones that shut off display hardware, we already know that no VCPI
allocations are needed. So, hardcode the VCPI slot count to 0 when
intel_dp_mst_compute_config() is called on an MST port that's gone.
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp_mst.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c
index fcb9b87b9339..a366f32b048a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,7 +42,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
to_intel_connector(conn_state->connector);
struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
- int lane_count, slots;
+ int lane_count, slots = 0;
const struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
int mst_pbn;
bool reduce_m_n = drm_dp_has_quirk(&intel_dp->desc,
@@ -76,11 +76,16 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder,
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
- slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
- connector->port, mst_pbn);
- if (slots < 0) {
- DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
- return false;
+ if (!connector->mst_port_gone) {
+ slots = drm_dp_atomic_find_vcpi_slots(state,
+ &intel_dp->mst_mgr,
+ connector->port,
+ mst_pbn);
+ if (slots < 0) {
+ DRM_DEBUG_KMS("failed finding vcpi slots:%d\n",
+ slots);
+ return false;
+ }
}
intel_link_compute_m_n(bpp, lane_count,
--
2.17.1
Changes since v4 [1]:
* Rebase on v4.19-rc3
* Update changelogs and cover letter
[1]: https://lkml.org/lkml/2018/7/11/14
---
Hi Andrew,
Back from vacation and this series is still top of mind.
devm_memremap_pages() is a facility that can create struct page entries
for any arbitrary range and give drivers the ability to subvert core
aspects of page management. It, and anything derived from it (e.g. hmm,
pcip2p, etc...), is an EXPORT_SYMBOL_GPL() interface.
I see that commit 31c5bda3a656 "mm: fix exports that inadvertently make
put_page() EXPORT_SYMBOL_GPL" was merged ahead of this series to relieve
some of the pressure from innocent consumers of put_page(), but now we
need this series to address *producers* of device pages.
More details and justification in the changelogs. The 0day
infrastructure has reported success across 182 configs and this survives
the libnvdimm unit test suite. Aside from the controversial bits the
diffstat is compelling at:
7 files changed, 138 insertions(+), 328 deletions(-).
Note that the series has some minor collisions with Alex's recent series
to improve devm_memremap_pages() scalability [2]. So, whichever you take
first the other will need a minor rebase.
[2]: https://www.lkml.org/lkml/2018/9/11/10
---
Dan Williams (7):
mm, devm_memremap_pages: Mark devm_memremap_pages() EXPORT_SYMBOL_GPL
mm, devm_memremap_pages: Kill mapping "System RAM" support
mm, devm_memremap_pages: Fix shutdown handling
mm, devm_memremap_pages: Add MEMORY_DEVICE_PRIVATE support
mm, hmm: Use devm semantics for hmm_devmem_{add,remove}
mm, hmm: Replace hmm_devmem_pages_create() with devm_memremap_pages()
mm, hmm: Mark hmm_devmem_{add,add_resource} EXPORT_SYMBOL_GPL
drivers/dax/pmem.c | 15 --
drivers/nvdimm/pmem.c | 18 +-
include/linux/hmm.h | 4
include/linux/memremap.h | 7 +
kernel/memremap.c | 98 ++++++++----
mm/hmm.c | 303 +++++--------------------------------
tools/testing/nvdimm/test/iomap.c | 21 ++-
7 files changed, 138 insertions(+), 328 deletions(-)
From: "Dr. Greg Wettstein" <greg(a)wind.enjellic.com>
Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in commit ccc9d90a9a8b
("xenbus_client: Extend interface to support multi-page ring").
In this commit pointer to location of where the shared page address
is stored was being passed to the xenbus_grant_ring() function rather
then the address of the shared page itself. This resulted in a situation
where the driver would attach to the vtpm-stubdom but any attempt
to send a command to the stub domain would timeout.
A diagnostic finding for this regression is the following error
message being generated when the xen-tpmfront driver probes for a
device:
<3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62
<3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine
the timeouts
This fix is relevant to all kernels from 4.1 forward which is the
release in which multi-page xenbus support was introduced.
Daniel De Graaf formulated the fix by code inspection after the
regression point was located.
Fixes: ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page ring")
Signed-off-by: Dr. Greg Wettstein <greg(a)enjellic.com>
[boris: Updated commit message, added Fixes tag]
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: stable(a)vger.kernel.org # v4.1+
---
drivers/char/tpm/xen-tpmfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 911475d36800..b150f87f38f5 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -264,7 +264,7 @@ static int setup_ring(struct xenbus_device *dev, struct tpm_private *priv)
return -ENOMEM;
}
- rv = xenbus_grant_ring(dev, &priv->shr, 1, &gref);
+ rv = xenbus_grant_ring(dev, priv->shr, 1, &gref);
if (rv < 0)
return rv;
--
2.17.1
This is a note to let you know that I've just added the patch titled
serial: 8250: Fix clearing FIFOs in RS485 mode again
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From f6aa5beb45be27968a4df90176ca36dfc4363d37 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex(a)denx.de>
Date: Mon, 3 Sep 2018 02:44:52 +0200
Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
The 8250 FIFOs indeed need to be cleared after stopping transmission in
RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two
problems with the approach taken by the previous patch from Fixes tag.
First, serial8250_clear_fifos() should clear fifos, but what it really
does is it enables the FIFOs unconditionally if present, clears them
and then sets the FCR register to zero, which effectively disables the
FIFOs. In case the FIFO is disabled, enabling it and clearing it makes
no sense and in fact can trigger misbehavior of the 8250 core. Moreover,
the FCR register may contain other FIFO configuration bits which may not
be writable unconditionally and writing them incorrectly can trigger
misbehavior of the 8250 core too. (ie. AM335x UART swallows the first
byte and retransmits the last byte twice because of this FCR write).
Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR,
but what really has to happen at the end of the RS485 transmission is
clearing of the FIFOs and nothing else.
This patch repairs serial8250_clear_fifos() so that it really only
clears the FIFOs by operating on FCR[2:1] bits and leaves all the
other bits alone. It also undoes serial8250_clear_and_reinit_fifos()
from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient.
Signed-off-by: Marek Vasut <marex(a)denx.de>
Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
Cc: Daniel Jedrychowski <avistel(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: stable <stable(a)vger.kernel.org> # let it bake a bit before merging
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 3f779d25ec0c..f776b3eafb96 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -552,11 +552,30 @@ static unsigned int serial_icr_read(struct uart_8250_port *up, int offset)
*/
static void serial8250_clear_fifos(struct uart_8250_port *p)
{
+ unsigned char fcr;
+ unsigned char clr_mask = UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT;
+
if (p->capabilities & UART_CAP_FIFO) {
- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
- UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
- serial_out(p, UART_FCR, 0);
+ /*
+ * Make sure to avoid changing FCR[7:3] and ENABLE_FIFO bits.
+ * In case ENABLE_FIFO is not set, there is nothing to flush
+ * so just return. Furthermore, on certain implementations of
+ * the 8250 core, the FCR[7:3] bits may only be changed under
+ * specific conditions and changing them if those conditions
+ * are not met can have nasty side effects. One such core is
+ * the 8250-omap present in TI AM335x.
+ */
+ fcr = serial_in(p, UART_FCR);
+
+ /* FIFO is not enabled, there's nothing to clear. */
+ if (!(fcr & UART_FCR_ENABLE_FIFO))
+ return;
+
+ fcr |= clr_mask;
+ serial_out(p, UART_FCR, fcr);
+
+ fcr &= ~clr_mask;
+ serial_out(p, UART_FCR, fcr);
}
}
@@ -1448,7 +1467,7 @@ static void __do_stop_tx_rs485(struct uart_8250_port *p)
* Enable previously disabled RX interrupts.
*/
if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
- serial8250_clear_and_reinit_fifos(p);
+ serial8250_clear_fifos(p);
p->ier |= UART_IER_RLSI | UART_IER_RDI;
serial_port_out(&p->port, UART_IER, p->ier);
--
2.19.0
This is a note to let you know that I've just added the patch titled
serial: cpm_uart: return immediately from console poll
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From be28c1e3ca29887e207f0cbcd294cefe5074bab6 Mon Sep 17 00:00:00 2001
From: Christophe Leroy <christophe.leroy(a)c-s.fr>
Date: Fri, 14 Sep 2018 10:32:50 +0000
Subject: serial: cpm_uart: return immediately from console poll
kgdb expects poll function to return immediately and
returning NO_POLL_CHAR when no character is available.
Fixes: f5316b4aea024 ("kgdb,8250,pl011: Return immediately from console poll")
Cc: Jason Wessel <jason.wessel(a)windriver.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index 24a5f05e769b..e5389591bb4f 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1054,8 +1054,8 @@ static int poll_wait_key(char *obuf, struct uart_cpm_port *pinfo)
/* Get the address of the host memory buffer.
*/
bdp = pinfo->rx_cur;
- while (bdp->cbd_sc & BD_SC_EMPTY)
- ;
+ if (bdp->cbd_sc & BD_SC_EMPTY)
+ return NO_POLL_CHAR;
/* If the buffer address is in the CPM DPRAM, don't
* convert it.
@@ -1090,7 +1090,11 @@ static int cpm_get_poll_char(struct uart_port *port)
poll_chars = 0;
}
if (poll_chars <= 0) {
- poll_chars = poll_wait_key(poll_buf, pinfo);
+ int ret = poll_wait_key(poll_buf, pinfo);
+
+ if (ret == NO_POLL_CHAR)
+ return ret;
+ poll_chars = ret;
pollp = poll_buf;
}
poll_chars--;
--
2.19.0
This is a note to let you know that I've just added the patch titled
serial: mvebu-uart: Fix reporting of effective CSIZE to userspace
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From e0bf2d4982fe7d9ddaf550dd023803ea286f47fc Mon Sep 17 00:00:00 2001
From: Jan Kiszka <jan.kiszka(a)siemens.com>
Date: Sun, 26 Aug 2018 19:49:32 +0200
Subject: serial: mvebu-uart: Fix reporting of effective CSIZE to userspace
Apparently, this driver (or the hardware) does not support character
length settings. It's apparently running in 8-bit mode, but it makes
userspace believe it's in 5-bit mode. That makes tcsetattr with CS8
incorrectly fail, breaking e.g. getty from busybox, thus the login shell
on ttyMVx.
Fix by hard-wiring CS8 into c_cflag.
Signed-off-by: Jan Kiszka <jan.kiszka(a)siemens.com>
Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port")
Cc: stable <stable(a)vger.kernel.org> # 4.6+
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/mvebu-uart.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index d04b5eeea3c6..170e446a2f62 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -511,6 +511,7 @@ static void mvebu_uart_set_termios(struct uart_port *port,
termios->c_iflag |= old->c_iflag & ~(INPCK | IGNPAR);
termios->c_cflag &= CREAD | CBAUD;
termios->c_cflag |= old->c_cflag & ~(CREAD | CBAUD);
+ termios->c_cflag |= CS8;
}
spin_unlock_irqrestore(&port->lock, flags);
--
2.19.0
This is a note to let you know that I've just added the patch titled
serial: 8250: Fix clearing FIFOs in RS485 mode again
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-testing branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will be merged to the tty-next branch sometime soon,
after it passes testing, and the merge window is open.
If you have any questions about this process, please let me know.
>From b268203fc327a8f480ef70b70acace7f4a80f525 Mon Sep 17 00:00:00 2001
From: Marek Vasut <marex(a)denx.de>
Date: Mon, 3 Sep 2018 02:44:52 +0200
Subject: serial: 8250: Fix clearing FIFOs in RS485 mode again
The 8250 FIFOs indeed need to be cleared after stopping transmission in
RS485 mode without SER_RS485_RX_DURING_TX flag set. But there are two
problems with the approach taken by the previous patch from Fixes tag.
First, serial8250_clear_fifos() should clear fifos, but what it really
does is it enables the FIFOs unconditionally if present, clears them
and then sets the FCR register to zero, which effectively disables the
FIFOs. In case the FIFO is disabled, enabling it and clearing it makes
no sense and in fact can trigger misbehavior of the 8250 core. Moreover,
the FCR register may contain other FIFO configuration bits which may not
be writable unconditionally and writing them incorrectly can trigger
misbehavior of the 8250 core too. (ie. AM335x UART swallows the first
byte and retransmits the last byte twice because of this FCR write).
Second, serial8250_clear_and_reinit_fifos() completely reloads the FCR,
but what really has to happen at the end of the RS485 transmission is
clearing of the FIFOs and nothing else.
This patch repairs serial8250_clear_fifos() so that it really only
clears the FIFOs by operating on FCR[2:1] bits and leaves all the
other bits alone. It also undoes serial8250_clear_and_reinit_fifos()
from __do_stop_tx_rs485() as serial8250_clear_fifos() is sufficient.
Signed-off-by: Marek Vasut <marex(a)denx.de>
Fixes: 2bed8a8e7072 ("Clearing FIFOs in RS485 emulation mode causes subsequent transmits to break")
Cc: Daniel Jedrychowski <avistel(a)gmail.com>
Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Cc: stable <stable(a)vger.kernel.org> # let it bake a bit before merging
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/tty/serial/8250/8250_port.c | 29 ++++++++++++++++++++++++-----
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
index 3f779d25ec0c..f776b3eafb96 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -552,11 +552,30 @@ static unsigned int serial_icr_read(struct uart_8250_port *up, int offset)
*/
static void serial8250_clear_fifos(struct uart_8250_port *p)
{
+ unsigned char fcr;
+ unsigned char clr_mask = UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT;
+
if (p->capabilities & UART_CAP_FIFO) {
- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO);
- serial_out(p, UART_FCR, UART_FCR_ENABLE_FIFO |
- UART_FCR_CLEAR_RCVR | UART_FCR_CLEAR_XMIT);
- serial_out(p, UART_FCR, 0);
+ /*
+ * Make sure to avoid changing FCR[7:3] and ENABLE_FIFO bits.
+ * In case ENABLE_FIFO is not set, there is nothing to flush
+ * so just return. Furthermore, on certain implementations of
+ * the 8250 core, the FCR[7:3] bits may only be changed under
+ * specific conditions and changing them if those conditions
+ * are not met can have nasty side effects. One such core is
+ * the 8250-omap present in TI AM335x.
+ */
+ fcr = serial_in(p, UART_FCR);
+
+ /* FIFO is not enabled, there's nothing to clear. */
+ if (!(fcr & UART_FCR_ENABLE_FIFO))
+ return;
+
+ fcr |= clr_mask;
+ serial_out(p, UART_FCR, fcr);
+
+ fcr &= ~clr_mask;
+ serial_out(p, UART_FCR, fcr);
}
}
@@ -1448,7 +1467,7 @@ static void __do_stop_tx_rs485(struct uart_8250_port *p)
* Enable previously disabled RX interrupts.
*/
if (!(p->port.rs485.flags & SER_RS485_RX_DURING_TX)) {
- serial8250_clear_and_reinit_fifos(p);
+ serial8250_clear_fifos(p);
p->ier |= UART_IER_RLSI | UART_IER_RDI;
serial_port_out(&p->port, UART_IER, p->ier);
--
2.19.0
The core of the driver expects the resource array from the glue layer
to be indexed by even numbers, as is the case for 64-bit PCI resources.
This doesn't hold true for others, ACPI in this instance, which leads
to an out-of-bounds access and an ioremap() on whatever address that
access fetches.
This patch fixes the problem by reading resource array differently based
on whether the 64-bit flag is set, which would indicate PCI glue layer.
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Fixes: ebc57e399b8e ("intel_th: Add ACPI glue layer")
CC: stable(a)vger.kernel.org # v4.17+
---
drivers/hwtracing/intel_th/core.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c
index 4e70ecee2103..fc6b7f8b62fb 100644
--- a/drivers/hwtracing/intel_th/core.c
+++ b/drivers/hwtracing/intel_th/core.c
@@ -488,7 +488,7 @@ static const struct intel_th_subdevice {
.flags = IORESOURCE_MEM,
},
{
- .start = TH_MMIO_SW,
+ .start = 1, /* use resource[1] */
.end = 0,
.flags = IORESOURCE_MEM,
},
@@ -581,6 +581,7 @@ intel_th_subdevice_alloc(struct intel_th *th,
struct intel_th_device *thdev;
struct resource res[3];
unsigned int req = 0;
+ bool is64bit = false;
int r, err;
thdev = intel_th_device_alloc(th, subdev->type, subdev->name,
@@ -590,12 +591,18 @@ intel_th_subdevice_alloc(struct intel_th *th,
thdev->drvdata = th->drvdata;
+ for (r = 0; r < th->num_resources; r++)
+ if (th->resource[r].flags & IORESOURCE_MEM_64) {
+ is64bit = true;
+ break;
+ }
+
memcpy(res, subdev->res,
sizeof(struct resource) * subdev->nres);
for (r = 0; r < subdev->nres; r++) {
struct resource *devres = th->resource;
- int bar = TH_MMIO_CONFIG;
+ int bar = 0; /* cut subdevices' MMIO from resource[0] */
/*
* Take .end == 0 to mean 'take the whole bar',
@@ -604,6 +611,8 @@ intel_th_subdevice_alloc(struct intel_th *th,
*/
if (!res[r].end && res[r].flags == IORESOURCE_MEM) {
bar = res[r].start;
+ if (is64bit)
+ bar *= 2;
res[r].start = 0;
res[r].end = resource_size(&devres[bar]) - 1;
}
--
2.18.0
Commit a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices")
brings in new subdevice addition/removal logic that's broken for "host
mode": the SWITCH device has no children to begin with, which is not
handled in the code. This results in a null dereference bug later down
the path.
This patch fixes the subdevice removal code to handle host mode correctly.
Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
Fixes: a753bfcfdb1f ("intel_th: Make the switch allocate its subdevices")
CC: stable(a)vger.kernel.org # v4.14+
---
drivers/hwtracing/intel_th/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwtracing/intel_th/core.c b/drivers/hwtracing/intel_th/core.c
index da962aa2cef5..4e70ecee2103 100644
--- a/drivers/hwtracing/intel_th/core.c
+++ b/drivers/hwtracing/intel_th/core.c
@@ -139,7 +139,8 @@ static int intel_th_remove(struct device *dev)
th->thdev[i] = NULL;
}
- th->num_thdevs = lowest;
+ if (lowest >= 0)
+ th->num_thdevs = lowest;
}
if (thdrv->attr_group)
--
2.18.0
As documented in spi-mem.h, spi_mem_op->data.buf.{in,out} must be
DMA-able, and commit 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx()
API") failed to follow this rule as buffers passed to
->{read,write}_reg() are usually placed on the stack.
Fix that by allocating a scratch buffer and copying the data around.
Fixes: 4120f8d158ef ("mtd: spi-nor: Use the spi_mem_xx() API")
Reported-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
---
Note that the ->{read,write}() path is still buggy since nothing
guarantees that buffers passed by the MTD layer to the SPI NOR layer
are DMA-able, but this is a long-standing issue which we'll have to
address at the spi-nor level (this layer can choose the bounce buffer
size based on nor->page_size).
Changes in v2:
- Copy the data from scratchbuf in the ->read_reg() path
---
drivers/mtd/devices/m25p80.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index cbfafc453274..270d3c9580c5 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -39,13 +39,23 @@ static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8 *val, int len)
struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(code, 1),
SPI_MEM_OP_NO_ADDR,
SPI_MEM_OP_NO_DUMMY,
- SPI_MEM_OP_DATA_IN(len, val, 1));
+ SPI_MEM_OP_DATA_IN(len, NULL, 1));
+ void *scratchbuf;
int ret;
+ scratchbuf = kmalloc(len, GFP_KERNEL);
+ if (!scratchbuf)
+ return -ENOMEM;
+
+ op.data.buf.in = scratchbuf;
ret = spi_mem_exec_op(flash->spimem, &op);
if (ret < 0)
dev_err(&flash->spimem->spi->dev, "error %d reading %x\n", ret,
code);
+ else
+ memcpy(val, scratchbuf, len);
+
+ kfree(scratchbuf);
return ret;
}
@@ -56,9 +66,19 @@ static int m25p80_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
struct spi_mem_op op = SPI_MEM_OP(SPI_MEM_OP_CMD(opcode, 1),
SPI_MEM_OP_NO_ADDR,
SPI_MEM_OP_NO_DUMMY,
- SPI_MEM_OP_DATA_OUT(len, buf, 1));
+ SPI_MEM_OP_DATA_OUT(len, NULL, 1));
+ void *scratchbuf;
+ int ret;
- return spi_mem_exec_op(flash->spimem, &op);
+ scratchbuf = kmemdup(buf, len, GFP_KERNEL);
+ if (!scratchbuf)
+ return -ENOMEM;
+
+ op.data.buf.out = scratchbuf;
+ ret = spi_mem_exec_op(flash->spimem, &op);
+ kfree(scratchbuf);
+
+ return ret;
}
static ssize_t m25p80_write(struct spi_nor *nor, loff_t to, size_t len,
--
2.14.1
From: "Dr. Greg Wettstein" <greg(a)wind.enjellic.com>
Functionality of the xen-tpmfront driver was lost secondary to
the introduction of xenbus multi-page support in commit ccc9d90a9a8b
("xenbus_client: Extend interface to support multi-page ring").
In this commit a pointer to the shared page address was being
passed to the xenbus_grant_ring() function rather then the
address of the shared page itself. This resulted in a situation
where the driver would attach to the vtpm-stubdom but any attempt
to send a command to the stub domain would timeout.
A diagnostic finding for this regression is the following error
message being generated when the xen-tpmfront driver probes for a
device:
<3>vtpm vtpm-0: tpm_transmit: tpm_send: error -62
<3>vtpm vtpm-0: A TPM error (-62) occurred attempting to determine
the timeouts
This fix is relevant to all kernels from 4.1 forward which is the
release in which multi-page xenbus support was introduced.
Daniel De Graaf formulated the fix by code inspection after the
regression point was located.
Fixes: ccc9d90a9a8b ("xenbus_client: Extend interface to support multi-page ring")
Signed-off-by: Dr. Greg Wettstein <greg(a)enjellic.com>
[boris: fixed commit message formatting, added Fixes tag]
Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
Cc: stable(a)vger.kernel.org # v4.1+
---
drivers/char/tpm/xen-tpmfront.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/tpm/xen-tpmfront.c b/drivers/char/tpm/xen-tpmfront.c
index 911475d36800..b150f87f38f5 100644
--- a/drivers/char/tpm/xen-tpmfront.c
+++ b/drivers/char/tpm/xen-tpmfront.c
@@ -264,7 +264,7 @@ static int setup_ring(struct xenbus_device *dev, struct tpm_private *priv)
return -ENOMEM;
}
- rv = xenbus_grant_ring(dev, &priv->shr, 1, &gref);
+ rv = xenbus_grant_ring(dev, priv->shr, 1, &gref);
if (rv < 0)
return rv;
--
2.17.1
As pointed out by Daniel Vetter, we should be usinng
drm_drv_uses_atomic_modeset() for determining whether or not we want to
make the debugfs nodes for atomic instead of checking DRIVER_ATOMIC, as
the former isn't an accurate representation of whether or not the driver
is actually using atomic modesetting internally (even though it might
not be exposing atomic capabilities).
Signed-off-by: Lyude Paul <lyude(a)redhat.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/drm_atomic.c | 2 +-
drivers/gpu/drm/drm_debugfs.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3eb061e11e2e..018fcdb353d2 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2067,7 +2067,7 @@ static void __drm_state_dump(struct drm_device *dev, struct drm_printer *p,
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
- if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
+ if (!drm_drv_uses_atomic_modeset(dev))
return;
list_for_each_entry(plane, &config->plane_list, head) {
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 6f28fe58f169..373bd4c2b698 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -151,7 +151,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
return ret;
}
- if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
+ if (drm_drv_uses_atomic_modeset(dev)) {
ret = drm_atomic_debugfs_init(minor);
if (ret) {
DRM_ERROR("Failed to create atomic debugfs files\n");
--
2.17.1
commit 40413955ee26 ("Cipso: cipso_v4_optptr enter infinite loop") fixed
a possible infinite loop in the IP option parsing of CIPSO. The fix
assumes that ip_options_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP exist.
While this assumption currently holds true, add explicit checks for zero
length and invalid length options to be safe for the future. Even though
ip_options_compile should have validated the options, the introduction of
new one-byte options can still confuse this code without the additional
checks.
Signed-off-by: Stefan Nuernberger <snu(a)amazon.com>
Reviewed-by: David Woodhouse <dwmw(a)amazon.co.uk>
Reviewed-by: Simon Veith <sveith(a)amazon.de>
Cc: stable(a)vger.kernel.org
---
net/ipv4/cipso_ipv4.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index 82178cc69c96..f291b57b8474 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1512,7 +1512,7 @@ static int cipso_v4_parsetag_loc(const struct cipso_v4_doi *doi_def,
*
* Description:
* Parse the packet's IP header looking for a CIPSO option. Returns a pointer
- * to the start of the CIPSO option on success, NULL if one if not found.
+ * to the start of the CIPSO option on success, NULL if one is not found.
*
*/
unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
@@ -1522,9 +1522,11 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
int optlen;
int taglen;
- for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
+ for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 1; ) {
switch (optptr[0]) {
case IPOPT_CIPSO:
+ if (!optptr[1] || optptr[1] > optlen)
+ return NULL;
return optptr;
case IPOPT_END:
return NULL;
@@ -1534,6 +1536,10 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
default:
taglen = optptr[1];
}
+
+ if (!taglen || taglen > optlen)
+ break;
+
optlen -= taglen;
optptr += taglen;
}
--
2.19.0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Greg,
Pleae pull commits for Linux 3.18 .
I've sent a review request for all commits over a week ago and all
comments were addressed.
Thanks,
Sasha
=====
The following changes since commit a5f9be3576c3f9dd871f68eaf482278c0b3a6df2:
Linux 3.18.120 (2018-08-28 07:21:37 +0200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-17092018
for you to fetch changes up to 7058136ea11e4f5b2d0d65f6f6dbb714d2beec42:
platform/x86: toshiba_acpi: Fix defined but not used build warnings (2018-09-04 13:44:36 -0400)
- ----------------------------------------------------------------
for-greg-3.18-17092018
- ----------------------------------------------------------------
Andreas Gruenbacher (1):
gfs2: Special-case rindex for gfs2_grow
Anton Vasilyev (1):
video: goldfishfb: fix memory leak on driver remove
Bob Peterson (1):
gfs2: Don't reject a supposedly full bitmap if we have blocks reserved
Dan Carpenter (1):
fbdev: omapfb: off by one in omapfb_register_client()
Felix Fietkau (1):
MIPS: ath79: fix system restart
Fredrik Noring (1):
fbdev: Distinguish between interlaced and progressive modes
Julian Wiedmann (2):
s390/qeth: fix race in used-buffer accounting
s390/qeth: reset layer2 attribute on layer switch
Lars-Peter Clausen (1):
iio: ad9523: Fix displayed phase
Manikanta Pubbisetty (1):
mac80211: restrict delayed tailroom needed decrement
Nicholas Piggin (1):
powerpc/powernv: opal_put_chars partial write fix
Randy Dunlap (3):
mtd/maps: fix solutionengine.c printk format warnings
fbdev/via: fix defined but not used warning
platform/x86: toshiba_acpi: Fix defined but not used build warnings
Sandipan Das (2):
perf powerpc: Fix callchain ip filtering when return address is in a register
perf powerpc: Fix callchain ip filtering
Takashi Iwai (2):
ALSA: msnd: Fix the default sample sizes
ALSA: usb-audio: Fix multiple definitions in AU0828_DEVICE() macro
YueHaibing (1):
xfrm: fix 'passing zero to ERR_PTR()' warning
arch/mips/ath79/setup.c | 1 +
arch/mips/include/asm/mach-ath79/ath79.h | 1 +
arch/powerpc/platforms/powernv/opal.c | 2 +-
drivers/iio/frequency/ad9523.c | 2 +-
drivers/mtd/maps/solutionengine.c | 6 ++--
drivers/platform/x86/toshiba_acpi.c | 3 +-
drivers/s390/net/qeth_core_main.c | 3 +-
drivers/s390/net/qeth_core_sys.c | 1 +
drivers/video/fbdev/core/modedb.c | 41 +++++++++++++++++------
drivers/video/fbdev/goldfishfb.c | 1 +
drivers/video/fbdev/omap/omapfb_main.c | 2 +-
drivers/video/fbdev/via/viafbdev.c | 3 +-
fs/gfs2/bmap.c | 2 +-
fs/gfs2/rgrp.c | 3 +-
net/mac80211/cfg.c | 2 +-
net/mac80211/key.c | 24 ++++++++-----
net/xfrm/xfrm_policy.c | 5 ++-
sound/isa/msnd/msnd_pinnacle.c | 4 +--
sound/usb/quirks-table.h | 3 +-
tools/perf/arch/powerpc/util/skip-callchain-idx.c | 10 ++++--
20 files changed, 80 insertions(+), 39 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAlugPO8ACgkQ3qZv95d3
LNygexAAvz2wzEaH/mDTnQ0085ODaIA6wmr/U7dlzXjoE1vPko4EOg0y8GJPmRD0
DsFkX7fqCLoLT/LQcCMK+KKq5IsPNPDs35tOvCc1T0WofnIE1KVifz4zalmW3upc
gT1HjZaza+agnw5QDs9RI0Y/y5vfR9Pwpmfi1e9V8vsNX8iR7i3YMI3HwS8g2Ggq
gjVOlH2UyiyJpqruV1B6tRwZA+KE3RNmj7xIXwvRVd29MLI0CMs/mSOo57TvGvxp
Wcn0IA0TK6T0LvNqgXNv+vjJhohfIN1TzhGiH0oEMiZVkRoHs1wqmkVQdkRPBApV
GXMGvb1suh1NE8IRl4OP/z27zZoUBr+ksoLgFD+o6tzgiBp0zR+gPV87PVzPLN32
PKyru9V0LOrF3nnCS9k6iMboFUS/vWrctrxRIdd2oUPkljPwkzxx8jz6HUNJ606B
6vPeNMBdxH1Vqiptt29Qn6c9Lg35OkOi+6JMS0WWkTPCArvHBPKOodf/4DIslm4O
2ewBiq8ewmhfUTAxxQfk+xR0+YR6d4g82Q3PvZ4jyDsSosQWnThAwLjketoTRBmc
BRcZKrqFvIMpVky0I2sl9U3ZFzlWWr2Z4PEKxu98o0AhUDCctzBHvXwL45c+7K0k
CQEs5a76ecC99mAf5AjtrbAcnTjKx9R6Y1RJ8XS9gCjT5/CMA7M=
=gANE
-----END PGP SIGNATURE-----
The patch titled
Subject: mm, thp: fix mlocking THP page with migration enabled
has been added to the -mm tree. Its filename is
mm-thp-fix-mlocking-thp-page-with-migration-enabled.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-fix-mlocking-thp-page-with-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-fix-mlocking-thp-page-with-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm, thp: fix mlocking THP page with migration enabled
A transparent huge page is represented by a single entry on an LRU list.
Therefore, we can only make unevictable an entire compound page, not
individual subpages.
If a user tries to mlock() part of a huge page, we want the rest of the
page to be reclaimable.
We handle this by keeping PTE-mapped huge pages on normal LRU lists: the
PMD on border of VM_LOCKED VMA will be split into PTE table.
Introduction of THP migration breaks[1] the rules around mlocking THP
pages. If we had a single PMD mapping of the page in mlocked VMA, the
page will get mlocked, regardless of PTE mappings of the page.
For tmpfs/shmem it's easy to fix by checking PageDoubleMap() in
remove_migration_pmd().
Anon THP pages can only be shared between processes via fork(). Mlocked
page can only be shared if parent mlocked it before forking, otherwise CoW
will be triggered on mlock().
For Anon-THP, we can fix the issue by munlocking the page on removing PTE
migration entry for the page. PTEs for the page will always come after
mlocked PMD: rmap walks VMAs from oldest to newest.
Test-case:
#include <unistd.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <linux/mempolicy.h>
#include <numaif.h>
int main(void)
{
unsigned long nodemask = 4;
void *addr;
addr = mmap((void *)0x20000000UL, 2UL << 20, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, -1, 0);
if (fork()) {
wait(NULL);
return 0;
}
mlock(addr, 4UL << 10);
mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES,
&nodemask, 4, MPOL_MF_MOVE);
return 0;
}
[1] https://lkml.kernel.org/r/CAOMGZ=G52R-30rZvhGxEbkTw7rLLwBGadVYeo--iizcD3upL…
Link: http://lkml.kernel.org/r/20180917133816.43995-1-kirill.shutemov@linux.intel…
Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reported-by: Vegard Nossum <vegard.nossum(a)oracle.com>
Reviewed-by: Zi Yan <zi.yan(a)cs.rutgers.edu>
Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/huge_memory.c | 2 +-
mm/migrate.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
--- a/mm/huge_memory.c~mm-thp-fix-mlocking-thp-page-with-migration-enabled
+++ a/mm/huge_memory.c
@@ -2931,7 +2931,7 @@ void remove_migration_pmd(struct page_vm
else
page_add_file_rmap(new, true);
set_pmd_at(mm, mmun_start, pvmw->pmd, pmde);
- if (vma->vm_flags & VM_LOCKED)
+ if ((vma->vm_flags & VM_LOCKED) && !PageDoubleMap(new))
mlock_vma_page(new);
update_mmu_cache_pmd(vma, address, pvmw->pmd);
}
--- a/mm/migrate.c~mm-thp-fix-mlocking-thp-page-with-migration-enabled
+++ a/mm/migrate.c
@@ -275,6 +275,9 @@ static bool remove_migration_pte(struct
if (vma->vm_flags & VM_LOCKED && !PageTransCompound(new))
mlock_vma_page(new);
+ if (PageTransHuge(page) && PageMlocked(page))
+ clear_page_mlock(page);
+
/* No need to invalidate - it was non-present before */
update_mmu_cache(vma, pvmw.address, pvmw.pte);
}
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
mm-thp-fix-mlocking-thp-page-with-migration-enabled.patch
The patch titled
Subject: mm, thp: fix mlocking THP page with migration enabled
has been added to the -mm tree. Its filename is
mm-thp-fix-mlocking-thp-page-with-migration-enabled.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-thp-fix-mlocking-thp-page-with-…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-thp-fix-mlocking-thp-page-with-…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com>
Subject: mm, thp: fix mlocking THP page with migration enabled
A transparent huge page is represented by a single entry on an LRU list.
Therefore, we can only make unevictable an entire compound page, not
individual subpages.
If a user tries to mlock() part of a huge page, we want the rest of the
page to be reclaimable.
We handle this by keeping PTE-mapped huge pages on normal LRU lists: the
PMD on border of VM_LOCKED VMA will be split into PTE table.
Introduction of THP migration breaks[1] the rules around mlocking THP
pages. If we had a single PMD mapping of the page in mlocked VMA, the
page will get mlocked, regardless of PTE mappings of the page.
For tmpfs/shmem it's easy to fix by checking PageDoubleMap() in
remove_migration_pmd().
Anon THP pages can only be shared between processes via fork(). Mlocked
page can only be shared if parent mlocked it before forking, otherwise CoW
will be triggered on mlock().
For Anon-THP, we can fix the issue by munlocking the page on removing PTE
migration entry for the page. PTEs for the page will always come after
mlocked PMD: rmap walks VMAs from oldest to newest.
Test-case:
#include <unistd.h>
#include <sys/mman.h>
#include <sys/wait.h>
#include <linux/mempolicy.h>
#include <numaif.h>
int main(void)
{
unsigned long nodemask = 4;
void *addr;
addr = mmap((void *)0x20000000UL, 2UL << 20, PROT_READ | PROT_WRITE,
MAP_PRIVATE | MAP_ANONYMOUS | MAP_LOCKED, -1, 0);
if (fork()) {
wait(NULL);
return 0;
}
mlock(addr, 4UL << 10);
mbind(addr, 2UL << 20, MPOL_PREFERRED | MPOL_F_RELATIVE_NODES,
&nodemask, 4, MPOL_MF_MOVE);
return 0;
}
[1] https://lkml.kernel.org/r/CAOMGZ=G52R-30rZvhGxEbkTw7rLLwBGadVYeo--iizcD3upL…
Link: http://lkml.kernel.org/r/20180917133816.43995-1-kirill.shutemov@linux.intel…
Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com>
Reported-by: Vegard Nossum <vegard.nossum(a)oracle.com>
Reviewed-by: Zi Yan <zi.yan(a)cs.rutgers.edu>
Cc: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: Andrea Arcangeli <aarcange(a)redhat.com>
Cc: <stable(a)vger.kernel.org> [4.14+]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
mm/huge_memory.c | 2 +-
mm/migrate.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
--- a/mm/huge_memory.c~mm-thp-fix-mlocking-thp-page-with-migration-enabled
+++ a/mm/huge_memory.c
@@ -2931,7 +2931,7 @@ void remove_migration_pmd(struct page_vm
else
page_add_file_rmap(new, true);
set_pmd_at(mm, mmun_start, pvmw->pmd, pmde);
- if (vma->vm_flags & VM_LOCKED)
+ if ((vma->vm_flags & VM_LOCKED) && !PageDoubleMap(new))
mlock_vma_page(new);
update_mmu_cache_pmd(vma, address, pvmw->pmd);
}
--- a/mm/migrate.c~mm-thp-fix-mlocking-thp-page-with-migration-enabled
+++ a/mm/migrate.c
@@ -275,6 +275,9 @@ static bool remove_migration_pte(struct
if (vma->vm_flags & VM_LOCKED && !PageTransCompound(new))
mlock_vma_page(new);
+ if (PageTransHuge(page) && PageMlocked(page))
+ clear_page_mlock(page);
+
/* No need to invalidate - it was non-present before */
update_mmu_cache(vma, pvmw.address, pvmw.pte);
}
_
Patches currently in -mm which might be from kirill.shutemov(a)linux.intel.com are
mm-thp-fix-mlocking-thp-page-with-migration-enabled.patch
If on an initiator system a LUN reset is issued while I/O is in
progress with queue depth > 1, avoid that data corruption occurs
as follows:
- The initiator submits a READ (a).
- The initiator submits a LUN reset before READ (a) completes.
- The target responds that the LUN reset succeeded after READ (a)
has been marked as CMD_T_COMPLETE and before .queue_status() has
been called.
- The initiator receives the LUN reset response and frees the
tag used by READ (a).
- The initiator submits READ (b) and reuses the tag of READ (a).
- The initiator receives the response for READ (a) and interprets
this as a completion for READ (b).
- The initiator receives the completion for READ (b) and discards
it.
With the SRP initiator and target drivers and when running fio
concurrently with sg_reset -d it only takes a few minutes to
reproduce this.
Signed-off-by: Bart Van Assche <bvanassche(a)acm.org>
Fixes: commit febe562c20df ("target: Fix LUN_RESET active I/O handling for ACK_KREF")
Cc: Nicholas Bellinger <nab(a)linux-iscsi.org>
Cc: Mike Christie <mchristi(a)redhat.com>
Cc: Christoph Hellwig <hch(a)lst.de>
Cc: Hannes Reinecke <hare(a)suse.de>
Cc: <stable(a)vger.kernel.org>
---
drivers/target/target_core_tmr.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/target/target_core_tmr.c b/drivers/target/target_core_tmr.c
index 2750a2c7b563..6e419396c1e4 100644
--- a/drivers/target/target_core_tmr.c
+++ b/drivers/target/target_core_tmr.c
@@ -90,7 +90,7 @@ static int target_check_cdb_and_preempt(struct list_head *list,
return 1;
}
-static bool __target_check_io_state(struct se_cmd *se_cmd,
+static bool __target_check_io_state(struct se_cmd *se_cmd, u32 skip_flags,
struct se_session *tmr_sess, int tas)
{
struct se_session *sess = se_cmd->se_sess;
@@ -108,7 +108,7 @@ static bool __target_check_io_state(struct se_cmd *se_cmd,
* long as se_cmd->cmd_kref is still active unless zero.
*/
spin_lock(&se_cmd->t_state_lock);
- if (se_cmd->transport_state & (CMD_T_COMPLETE | CMD_T_FABRIC_STOP)) {
+ if (se_cmd->transport_state & (skip_flags | CMD_T_FABRIC_STOP)) {
pr_debug("Attempted to abort io tag: %llu already complete or"
" fabric stop, skipping\n", se_cmd->tag);
spin_unlock(&se_cmd->t_state_lock);
@@ -165,7 +165,8 @@ void core_tmr_abort_task(
printk("ABORT_TASK: Found referenced %s task_tag: %llu\n",
se_cmd->se_tfo->get_fabric_name(), ref_tag);
- if (!__target_check_io_state(se_cmd, se_sess, 0))
+ if (!__target_check_io_state(se_cmd, CMD_T_COMPLETE, se_sess,
+ 0))
continue;
spin_unlock_irqrestore(&se_sess->sess_cmd_lock, flags);
@@ -349,7 +350,7 @@ static void core_tmr_drain_state_list(
continue;
spin_lock(&sess->sess_cmd_lock);
- rc = __target_check_io_state(cmd, tmr_sess, tas);
+ rc = __target_check_io_state(cmd, 0, tmr_sess, tas);
spin_unlock(&sess->sess_cmd_lock);
if (!rc)
continue;
--
2.18.0
On Mon, 17 Sep 2018, gregkh(a)linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> x86/kexec: Allocate 8k PGDs for PTI
>
> to the 3.18-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:
> x86-kexec-allocate-8k-pgds-for-pti.patch
> and it can be found in the queue-3.18 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.
I believe this commit is an example of the auto-selector being too
eager, and this should not be in *any* of the stable trees. As the
commit message indicates, it's a fix by Joerg for his PTI-x86-32
implementation - which has not been backported to any of the stable
trees (yet), has it?
In several of the recent stable trees, I think this will not do any
actual harm; but it looks as if it will prevent relevant x86-32 configs
from building on 3.18 (I see no definition of PGD_ALLOCATION_ORDER in
linux-3.18.y - you preferred not to have any PTI in that tree), and I
haven't checked whether its definition in older backports will build
correctly here or not.
Hugh
>
>
> From foo@baz Mon Sep 17 11:45:57 CEST 2018
> From: Joerg Roedel <jroedel(a)suse.de>
> Date: Wed, 25 Jul 2018 17:48:03 +0200
> Subject: x86/kexec: Allocate 8k PGDs for PTI
>
> From: Joerg Roedel <jroedel(a)suse.de>
>
> [ Upstream commit ca38dc8f2724d101038b1205122c93a1c7f38f11 ]
>
> Fuzzing the PTI-x86-32 code with trinity showed unhandled
> kernel paging request oops-messages that looked a lot like
> silent data corruption.
>
> Lot's of debugging and testing lead to the kexec-32bit code,
> which is still allocating 4k PGDs when PTI is enabled. But
> since it uses native_set_pud() to build the page-table, it
> will unevitably call into __pti_set_user_pgtbl(), which
> writes beyond the allocated 4k page.
>
> Use PGD_ALLOCATION_ORDER to allocate PGDs in the kexec code
> to fix the issue.
>
> Signed-off-by: Joerg Roedel <jroedel(a)suse.de>
> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
> Tested-by: David H. Gutteridge <dhgutteridge(a)sympatico.ca>
> Cc: "H . Peter Anvin" <hpa(a)zytor.com>
> Cc: linux-mm(a)kvack.org
> Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
> Cc: Andy Lutomirski <luto(a)kernel.org>
> Cc: Dave Hansen <dave.hansen(a)intel.com>
> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
> Cc: Juergen Gross <jgross(a)suse.com>
> Cc: Peter Zijlstra <peterz(a)infradead.org>
> Cc: Borislav Petkov <bp(a)alien8.de>
> Cc: Jiri Kosina <jkosina(a)suse.cz>
> Cc: Boris Ostrovsky <boris.ostrovsky(a)oracle.com>
> Cc: Brian Gerst <brgerst(a)gmail.com>
> Cc: David Laight <David.Laight(a)aculab.com>
> Cc: Denys Vlasenko <dvlasenk(a)redhat.com>
> Cc: Eduardo Valentin <eduval(a)amazon.com>
> Cc: Greg KH <gregkh(a)linuxfoundation.org>
> Cc: Will Deacon <will.deacon(a)arm.com>
> Cc: aliguori(a)amazon.com
> Cc: daniel.gruss(a)iaik.tugraz.at
> Cc: hughd(a)google.com
> Cc: keescook(a)google.com
> Cc: Andrea Arcangeli <aarcange(a)redhat.com>
> Cc: Waiman Long <llong(a)redhat.com>
> Cc: Pavel Machek <pavel(a)ucw.cz>
> Cc: Arnaldo Carvalho de Melo <acme(a)kernel.org>
> Cc: Alexander Shishkin <alexander.shishkin(a)linux.intel.com>
> Cc: Jiri Olsa <jolsa(a)redhat.com>
> Cc: Namhyung Kim <namhyung(a)kernel.org>
> Cc: joro(a)8bytes.org
> Link: https://lkml.kernel.org/r/1532533683-5988-4-git-send-email-joro@8bytes.org
> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
> ---
> arch/x86/kernel/machine_kexec_32.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> --- a/arch/x86/kernel/machine_kexec_32.c
> +++ b/arch/x86/kernel/machine_kexec_32.c
> @@ -69,7 +69,7 @@ static void load_segments(void)
>
> static void machine_kexec_free_page_tables(struct kimage *image)
> {
> - free_page((unsigned long)image->arch.pgd);
> + free_pages((unsigned long)image->arch.pgd, PGD_ALLOCATION_ORDER);
> image->arch.pgd = NULL;
> #ifdef CONFIG_X86_PAE
> free_page((unsigned long)image->arch.pmd0);
> @@ -85,7 +85,8 @@ static void machine_kexec_free_page_tabl
>
> static int machine_kexec_alloc_page_tables(struct kimage *image)
> {
> - image->arch.pgd = (pgd_t *)get_zeroed_page(GFP_KERNEL);
> + image->arch.pgd = (pgd_t *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
> + PGD_ALLOCATION_ORDER);
> #ifdef CONFIG_X86_PAE
> image->arch.pmd0 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
> image->arch.pmd1 = (pmd_t *)get_zeroed_page(GFP_KERNEL);
>
>
> Patches currently in stable-queue which might be from jroedel(a)suse.de are
>
> queue-3.18/x86-kexec-allocate-8k-pgds-for-pti.patch
> queue-3.18/x86-mm-remove-in_nmi-warning-from-vmalloc_fault.patch
>