* [PATCH 4.12 01/84] staging: android: uapi: drop definitions of removed ION_IOC_{FREE,SHARE} ioctls
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 02/84] net/mlx5: Fix driver load error flow when firmware is stuck Greg Kroah-Hartman
` (75 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Gleb Fotengauer-Malinovskiy,
Laura Abbott, Dmitry V. Levin
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
commit f7a320ffebe2bdce3a189ecb531a401c653f754f upstream.
This problem was found by strace ioctl list generator.
Fixes: 15c6098cfec5 ("staging: android: ion: Remove ion_handle and ion_client")
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: "Dmitry V. Levin" <ldv@altlinux.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/staging/android/uapi/ion.h | 18 ------------------
1 file changed, 18 deletions(-)
--- a/drivers/staging/android/uapi/ion.h
+++ b/drivers/staging/android/uapi/ion.h
@@ -131,24 +131,6 @@ struct ion_heap_query {
struct ion_allocation_data)
/**
- * DOC: ION_IOC_FREE - free memory
- *
- * Takes an ion_handle_data struct and frees the handle.
- */
-#define ION_IOC_FREE _IOWR(ION_IOC_MAGIC, 1, struct ion_handle_data)
-
-/**
- * DOC: ION_IOC_SHARE - creates a file descriptor to use to share an allocation
- *
- * Takes an ion_fd_data struct with the handle field populated with a valid
- * opaque handle. Returns the struct with the fd field set to a file
- * descriptor open in the current address space. This file descriptor
- * can then be passed to another process. The corresponding opaque handle can
- * be retrieved via ION_IOC_IMPORT.
- */
-#define ION_IOC_SHARE _IOWR(ION_IOC_MAGIC, 4, struct ion_fd_data)
-
-/**
* DOC: ION_IOC_HEAP_QUERY - information about available heaps
*
* Takes an ion_heap_query structure and populates information about
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 02/84] net/mlx5: Fix driver load error flow when firmware is stuck
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 01/84] staging: android: uapi: drop definitions of removed ION_IOC_{FREE,SHARE} ioctls Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 03/84] net/mlx5: Cancel delayed recovery work when unloading the driver Greg Kroah-Hartman
` (74 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gal Pressman, Saeed Mahameed
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <galp@mellanox.com>
[ Upstream commit 8ce59b16b4b6eacedaec1f7b652b4781cdbfe15f ]
When wait for firmware init fails, previous code would mistakenly
return success and cause inconsistency in the driver state.
Fixes: 6c780a0267b8 ("net/mlx5: Wait for FW readiness before initializing command interface")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1020,7 +1020,7 @@ static int mlx5_load_one(struct mlx5_cor
if (err) {
dev_err(&dev->pdev->dev, "Firmware over %d MS in pre-initializing state, aborting\n",
FW_PRE_INIT_TIMEOUT_MILI);
- goto out;
+ goto out_err;
}
err = mlx5_cmd_init(dev);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 03/84] net/mlx5: Cancel delayed recovery work when unloading the driver
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 01/84] staging: android: uapi: drop definitions of removed ION_IOC_{FREE,SHARE} ioctls Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 02/84] net/mlx5: Fix driver load error flow when firmware is stuck Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 04/84] net/mlx5e: Fix TX carrier errors report in get stats ndo Greg Kroah-Hartman
` (73 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Mohamad Haj Yahia, Moshe Shemesh,
Saeed Mahameed
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohamad Haj Yahia <mohamad@mellanox.com>
[ Upstream commit 2a0165a034ac024b60cca49c61e46f4afa2e4d98 ]
Draining the health workqueue will ignore future health works including
the one that report hardware failure and thus we can't enter error state
Instead cancel the recovery flow and make sure only recovery flow won't
be scheduled.
Fixes: 5e44fca50470 ('net/mlx5: Only cancel recovery work when cleaning up device')
Signed-off-by: Mohamad Haj Yahia <mohamad@mellanox.com>
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/health.c | 15 ++++++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +-
include/linux/mlx5/driver.h | 1 +
3 files changed, 16 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -67,6 +67,7 @@ enum {
enum {
MLX5_DROP_NEW_HEALTH_WORK,
+ MLX5_DROP_NEW_RECOVERY_WORK,
};
static u8 get_nic_state(struct mlx5_core_dev *dev)
@@ -193,7 +194,7 @@ static void health_care(struct work_stru
mlx5_handle_bad_state(dev);
spin_lock(&health->wq_lock);
- if (!test_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags))
+ if (!test_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags))
schedule_delayed_work(&health->recover_work, recover_delay);
else
dev_err(&dev->pdev->dev,
@@ -313,6 +314,7 @@ void mlx5_start_health_poll(struct mlx5_
init_timer(&health->timer);
health->sick = 0;
clear_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags);
+ clear_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
health->health = &dev->iseg->health;
health->health_counter = &dev->iseg->health_counter;
@@ -335,11 +337,22 @@ void mlx5_drain_health_wq(struct mlx5_co
spin_lock(&health->wq_lock);
set_bit(MLX5_DROP_NEW_HEALTH_WORK, &health->flags);
+ set_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
spin_unlock(&health->wq_lock);
cancel_delayed_work_sync(&health->recover_work);
cancel_work_sync(&health->work);
}
+void mlx5_drain_health_recovery(struct mlx5_core_dev *dev)
+{
+ struct mlx5_core_health *health = &dev->priv.health;
+
+ spin_lock(&health->wq_lock);
+ set_bit(MLX5_DROP_NEW_RECOVERY_WORK, &health->flags);
+ spin_unlock(&health->wq_lock);
+ cancel_delayed_work_sync(&dev->priv.health.recover_work);
+}
+
void mlx5_health_cleanup(struct mlx5_core_dev *dev)
{
struct mlx5_core_health *health = &dev->priv.health;
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -1228,7 +1228,7 @@ static int mlx5_unload_one(struct mlx5_c
int err = 0;
if (cleanup)
- mlx5_drain_health_wq(dev);
+ mlx5_drain_health_recovery(dev);
mutex_lock(&dev->intf_state_mutex);
if (test_bit(MLX5_INTERFACE_STATE_DOWN, &dev->intf_state)) {
--- a/include/linux/mlx5/driver.h
+++ b/include/linux/mlx5/driver.h
@@ -925,6 +925,7 @@ int mlx5_health_init(struct mlx5_core_de
void mlx5_start_health_poll(struct mlx5_core_dev *dev);
void mlx5_stop_health_poll(struct mlx5_core_dev *dev);
void mlx5_drain_health_wq(struct mlx5_core_dev *dev);
+void mlx5_drain_health_recovery(struct mlx5_core_dev *dev);
int mlx5_buf_alloc_node(struct mlx5_core_dev *dev, int size,
struct mlx5_buf *buf, int node);
int mlx5_buf_alloc(struct mlx5_core_dev *dev, int size, struct mlx5_buf *buf);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 04/84] net/mlx5e: Fix TX carrier errors report in get stats ndo
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 03/84] net/mlx5: Cancel delayed recovery work when unloading the driver Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 05/84] ipv6: dad: dont remove dynamic addresses if link is down Greg Kroah-Hartman
` (72 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gal Pressman, Saeed Mahameed
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <galp@mellanox.com>
[ Upstream commit 8ff93de7668bd81bc8efa819d1184ebd48fae72d ]
Symbol error during carrier counter from PPCNT was mistakenly reported as
TX carrier errors in get_stats ndo, although it's an RX counter.
Fixes: 269e6b3af3bf ("net/mlx5e: Report additional error statistics in get stats ndo")
Signed-off-by: Gal Pressman <galp@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3053,8 +3053,6 @@ mlx5e_get_stats(struct net_device *dev,
PPORT_802_3_GET(pstats, a_frame_check_sequence_errors);
stats->rx_frame_errors = PPORT_802_3_GET(pstats, a_alignment_errors);
stats->tx_aborted_errors = PPORT_2863_GET(pstats, if_out_discards);
- stats->tx_carrier_errors =
- PPORT_802_3_GET(pstats, a_symbol_error_during_carrier);
stats->rx_errors = stats->rx_length_errors + stats->rx_crc_errors +
stats->rx_frame_errors;
stats->tx_errors = stats->tx_aborted_errors + stats->tx_carrier_errors;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 05/84] ipv6: dad: dont remove dynamic addresses if link is down
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 04/84] net/mlx5e: Fix TX carrier errors report in get stats ndo Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 06/84] vxlan: fix hlist corruption Greg Kroah-Hartman
` (71 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Sabrina Dubroca, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sabrina Dubroca <sd@queasysnail.net>
[ Upstream commit ec8add2a4c9df723c94a863b8fcd6d93c472deed ]
Currently, when the link for $DEV is down, this command succeeds but the
address is removed immediately by DAD (1):
ip addr add 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800
In the same situation, this will succeed and not remove the address (2):
ip addr add 1111::12/64 dev $DEV
ip addr change 1111::12/64 dev $DEV valid_lft 3600 preferred_lft 1800
The comment in addrconf_dad_begin() when !IF_READY makes it look like
this is the intended behavior, but doesn't explain why:
* If the device is not ready:
* - keep it tentative if it is a permanent address.
* - otherwise, kill it.
We clearly cannot prevent userspace from doing (2), but we can make (1)
work consistently with (2).
addrconf_dad_stop() is only called in two cases: if DAD failed, or to
skip DAD when the link is down. In that second case, the fix is to avoid
deleting the address, like we already do for permanent addresses.
Fixes: 3c21edbd1137 ("[IPV6]: Defer IPv6 device initialization until the link becomes ready.")
Signed-off-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/ipv6/addrconf.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1912,15 +1912,7 @@ static void addrconf_dad_stop(struct ine
if (dad_failed)
ifp->flags |= IFA_F_DADFAILED;
- if (ifp->flags&IFA_F_PERMANENT) {
- spin_lock_bh(&ifp->lock);
- addrconf_del_dad_work(ifp);
- ifp->flags |= IFA_F_TENTATIVE;
- spin_unlock_bh(&ifp->lock);
- if (dad_failed)
- ipv6_ifa_notify(0, ifp);
- in6_ifa_put(ifp);
- } else if (ifp->flags&IFA_F_TEMPORARY) {
+ if (ifp->flags&IFA_F_TEMPORARY) {
struct inet6_ifaddr *ifpub;
spin_lock_bh(&ifp->lock);
ifpub = ifp->ifpub;
@@ -1933,6 +1925,14 @@ static void addrconf_dad_stop(struct ine
spin_unlock_bh(&ifp->lock);
}
ipv6_del_addr(ifp);
+ } else if (ifp->flags&IFA_F_PERMANENT || !dad_failed) {
+ spin_lock_bh(&ifp->lock);
+ addrconf_del_dad_work(ifp);
+ ifp->flags |= IFA_F_TENTATIVE;
+ spin_unlock_bh(&ifp->lock);
+ if (dad_failed)
+ ipv6_ifa_notify(0, ifp);
+ in6_ifa_put(ifp);
} else {
ipv6_del_addr(ifp);
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 06/84] vxlan: fix hlist corruption
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 05/84] ipv6: dad: dont remove dynamic addresses if link is down Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 08/84] net: core: Fix slab-out-of-bounds in netdev_stats_to_stats64 Greg Kroah-Hartman
` (70 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jiri Benc, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Benc <jbenc@redhat.com>
[ Upstream commit 69e766612c4bcb79e19cebed9eed61d4222c1d47 ]
It's not a good idea to add the same hlist_node to two different hash lists.
This leads to various hard to debug memory corruptions.
Fixes: b1be00a6c39f ("vxlan: support both IPv4 and IPv6 sockets in a single vxlan device")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/vxlan.c | 30 ++++++++++++++++++++----------
include/net/vxlan.h | 10 +++++++++-
2 files changed, 29 insertions(+), 11 deletions(-)
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -228,15 +228,15 @@ static struct vxlan_sock *vxlan_find_soc
static struct vxlan_dev *vxlan_vs_find_vni(struct vxlan_sock *vs, __be32 vni)
{
- struct vxlan_dev *vxlan;
+ struct vxlan_dev_node *node;
/* For flow based devices, map all packets to VNI 0 */
if (vs->flags & VXLAN_F_COLLECT_METADATA)
vni = 0;
- hlist_for_each_entry_rcu(vxlan, vni_head(vs, vni), hlist) {
- if (vxlan->default_dst.remote_vni == vni)
- return vxlan;
+ hlist_for_each_entry_rcu(node, vni_head(vs, vni), hlist) {
+ if (node->vxlan->default_dst.remote_vni == vni)
+ return node->vxlan;
}
return NULL;
@@ -2365,17 +2365,22 @@ static void vxlan_vs_del_dev(struct vxla
struct vxlan_net *vn = net_generic(vxlan->net, vxlan_net_id);
spin_lock(&vn->sock_lock);
- hlist_del_init_rcu(&vxlan->hlist);
+ hlist_del_init_rcu(&vxlan->hlist4.hlist);
+#if IS_ENABLED(CONFIG_IPV6)
+ hlist_del_init_rcu(&vxlan->hlist6.hlist);
+#endif
spin_unlock(&vn->sock_lock);
}
-static void vxlan_vs_add_dev(struct vxlan_sock *vs, struct vxlan_dev *vxlan)
+static void vxlan_vs_add_dev(struct vxlan_sock *vs, struct vxlan_dev *vxlan,
+ struct vxlan_dev_node *node)
{
struct vxlan_net *vn = net_generic(vxlan->net, vxlan_net_id);
__be32 vni = vxlan->default_dst.remote_vni;
+ node->vxlan = vxlan;
spin_lock(&vn->sock_lock);
- hlist_add_head_rcu(&vxlan->hlist, vni_head(vs, vni));
+ hlist_add_head_rcu(&node->hlist, vni_head(vs, vni));
spin_unlock(&vn->sock_lock);
}
@@ -2819,6 +2824,7 @@ static int __vxlan_sock_add(struct vxlan
{
struct vxlan_net *vn = net_generic(vxlan->net, vxlan_net_id);
struct vxlan_sock *vs = NULL;
+ struct vxlan_dev_node *node;
if (!vxlan->cfg.no_share) {
spin_lock(&vn->sock_lock);
@@ -2836,12 +2842,16 @@ static int __vxlan_sock_add(struct vxlan
if (IS_ERR(vs))
return PTR_ERR(vs);
#if IS_ENABLED(CONFIG_IPV6)
- if (ipv6)
+ if (ipv6) {
rcu_assign_pointer(vxlan->vn6_sock, vs);
- else
+ node = &vxlan->hlist6;
+ } else
#endif
+ {
rcu_assign_pointer(vxlan->vn4_sock, vs);
- vxlan_vs_add_dev(vs, vxlan);
+ node = &vxlan->hlist4;
+ }
+ vxlan_vs_add_dev(vs, vxlan, node);
return 0;
}
--- a/include/net/vxlan.h
+++ b/include/net/vxlan.h
@@ -221,9 +221,17 @@ struct vxlan_config {
bool no_share;
};
+struct vxlan_dev_node {
+ struct hlist_node hlist;
+ struct vxlan_dev *vxlan;
+};
+
/* Pseudo network device */
struct vxlan_dev {
- struct hlist_node hlist; /* vni hash table */
+ struct vxlan_dev_node hlist4; /* vni hash table for IPv4 socket */
+#if IS_ENABLED(CONFIG_IPV6)
+ struct vxlan_dev_node hlist6; /* vni hash table for IPv6 socket */
+#endif
struct list_head next; /* vxlan's per namespace list */
struct vxlan_sock __rcu *vn4_sock; /* listening socket for IPv4 */
#if IS_ENABLED(CONFIG_IPV6)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 08/84] net: core: Fix slab-out-of-bounds in netdev_stats_to_stats64
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 06/84] vxlan: fix hlist corruption Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 09/84] liquidio: fix bug in soft reset failure detection Greg Kroah-Hartman
` (69 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Alban Browaeys, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alban Browaeys <alban.browaeys@gmail.com>
[ Upstream commit 9af9959e142c274f4a30fefb71d97d2b028b337f ]
commit 9256645af098 ("net/core: relax BUILD_BUG_ON in
netdev_stats_to_stats64") made an attempt to read beyond
the size of the source a possibility.
Fix to only copy src size to dest. As dest might be bigger than src.
==================================================================
BUG: KASAN: slab-out-of-bounds in netdev_stats_to_stats64+0xe/0x30 at addr ffff8801be248b20
Read of size 192 by task VBoxNetAdpCtl/6734
CPU: 1 PID: 6734 Comm: VBoxNetAdpCtl Tainted: G O 4.11.4prahal+intel+ #118
Hardware name: LENOVO 20CDCTO1WW/20CDCTO1WW, BIOS GQET52WW (1.32 ) 05/04/2017
Call Trace:
dump_stack+0x63/0x86
kasan_object_err+0x1c/0x70
kasan_report+0x270/0x520
? netdev_stats_to_stats64+0xe/0x30
? sched_clock_cpu+0x1b/0x190
? __module_address+0x3e/0x3b0
? unwind_next_frame+0x1ea/0xb00
check_memory_region+0x13c/0x1a0
memcpy+0x23/0x50
netdev_stats_to_stats64+0xe/0x30
dev_get_stats+0x1b9/0x230
rtnl_fill_stats+0x44/0xc00
? nla_put+0xc6/0x130
rtnl_fill_ifinfo+0xe9e/0x3700
? rtnl_fill_vfinfo+0xde0/0xde0
? sched_clock+0x9/0x10
? sched_clock+0x9/0x10
? sched_clock_local+0x120/0x130
? __module_address+0x3e/0x3b0
? unwind_next_frame+0x1ea/0xb00
? sched_clock+0x9/0x10
? sched_clock+0x9/0x10
? sched_clock_cpu+0x1b/0x190
? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp]
? depot_save_stack+0x1d8/0x4a0
? depot_save_stack+0x34f/0x4a0
? depot_save_stack+0x34f/0x4a0
? save_stack+0xb1/0xd0
? save_stack_trace+0x16/0x20
? save_stack+0x46/0xd0
? kasan_slab_alloc+0x12/0x20
? __kmalloc_node_track_caller+0x10d/0x350
? __kmalloc_reserve.isra.36+0x2c/0xc0
? __alloc_skb+0xd0/0x560
? rtmsg_ifinfo_build_skb+0x61/0x120
? rtmsg_ifinfo.part.25+0x16/0xb0
? rtmsg_ifinfo+0x47/0x70
? register_netdev+0x15/0x30
? vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp]
? vboxNetAdpCreate+0x210/0x400 [vboxnetadp]
? VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp]
? do_vfs_ioctl+0x17f/0xff0
? SyS_ioctl+0x74/0x80
? do_syscall_64+0x182/0x390
? __alloc_skb+0xd0/0x560
? __alloc_skb+0xd0/0x560
? save_stack_trace+0x16/0x20
? init_object+0x64/0xa0
? ___slab_alloc+0x1ae/0x5c0
? ___slab_alloc+0x1ae/0x5c0
? __alloc_skb+0xd0/0x560
? sched_clock+0x9/0x10
? kasan_unpoison_shadow+0x35/0x50
? kasan_kmalloc+0xad/0xe0
? __kmalloc_node_track_caller+0x246/0x350
? __alloc_skb+0xd0/0x560
? kasan_unpoison_shadow+0x35/0x50
? memset+0x31/0x40
? __alloc_skb+0x31f/0x560
? napi_consume_skb+0x320/0x320
? br_get_link_af_size_filtered+0xb7/0x120 [bridge]
? if_nlmsg_size+0x440/0x630
rtmsg_ifinfo_build_skb+0x83/0x120
rtmsg_ifinfo.part.25+0x16/0xb0
rtmsg_ifinfo+0x47/0x70
register_netdevice+0xa2b/0xe50
? __kmalloc+0x171/0x2d0
? netdev_change_features+0x80/0x80
register_netdev+0x15/0x30
vboxNetAdpOsCreate+0xc0/0x1c0 [vboxnetadp]
vboxNetAdpCreate+0x210/0x400 [vboxnetadp]
? vboxNetAdpComposeMACAddress+0x1d0/0x1d0 [vboxnetadp]
? kasan_check_write+0x14/0x20
VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp]
? VBoxNetAdpLinuxOpen+0x20/0x20 [vboxnetadp]
? lock_acquire+0x11c/0x270
? __audit_syscall_entry+0x2fb/0x660
do_vfs_ioctl+0x17f/0xff0
? __audit_syscall_entry+0x2fb/0x660
? ioctl_preallocate+0x1d0/0x1d0
? __audit_syscall_entry+0x2fb/0x660
? kmem_cache_free+0xb2/0x250
? syscall_trace_enter+0x537/0xd00
? exit_to_usermode_loop+0x100/0x100
SyS_ioctl+0x74/0x80
? do_sys_open+0x350/0x350
? do_vfs_ioctl+0xff0/0xff0
do_syscall_64+0x182/0x390
entry_SYSCALL64_slow_path+0x25/0x25
RIP: 0033:0x7f7e39a1ae07
RSP: 002b:00007ffc6f04c6d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007ffc6f04c730 RCX: 00007f7e39a1ae07
RDX: 00007ffc6f04c730 RSI: 00000000c0207601 RDI: 0000000000000007
RBP: 00007ffc6f04c700 R08: 00007ffc6f04c780 R09: 0000000000000008
R10: 0000000000000541 R11: 0000000000000206 R12: 0000000000000007
R13: 00000000c0207601 R14: 00007ffc6f04c730 R15: 0000000000000012
Object at ffff8801be248008, in cache kmalloc-4096 size: 4096
Allocated:
PID = 6734
save_stack_trace+0x16/0x20
save_stack+0x46/0xd0
kasan_kmalloc+0xad/0xe0
__kmalloc+0x171/0x2d0
alloc_netdev_mqs+0x8a7/0xbe0
vboxNetAdpOsCreate+0x65/0x1c0 [vboxnetadp]
vboxNetAdpCreate+0x210/0x400 [vboxnetadp]
VBoxNetAdpLinuxIOCtlUnlocked+0x14b/0x280 [vboxnetadp]
do_vfs_ioctl+0x17f/0xff0
SyS_ioctl+0x74/0x80
do_syscall_64+0x182/0x390
return_from_SYSCALL_64+0x0/0x6a
Freed:
PID = 5600
save_stack_trace+0x16/0x20
save_stack+0x46/0xd0
kasan_slab_free+0x73/0xc0
kfree+0xe4/0x220
kvfree+0x25/0x30
single_release+0x74/0xb0
__fput+0x265/0x6b0
____fput+0x9/0x10
task_work_run+0xd5/0x150
exit_to_usermode_loop+0xe2/0x100
do_syscall_64+0x26c/0x390
return_from_SYSCALL_64+0x0/0x6a
Memory state around the buggy address:
ffff8801be248a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8801be248b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff8801be248b80: 00 00 00 00 00 00 00 00 00 00 00 07 fc fc fc fc
^
ffff8801be248c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801be248c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
Signed-off-by: Alban Browaeys <alban.browaeys@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -7751,7 +7751,7 @@ void netdev_stats_to_stats64(struct rtnl
{
#if BITS_PER_LONG == 64
BUILD_BUG_ON(sizeof(*stats64) < sizeof(*netdev_stats));
- memcpy(stats64, netdev_stats, sizeof(*stats64));
+ memcpy(stats64, netdev_stats, sizeof(*netdev_stats));
/* zero out counters that only exist in rtnl_link_stats64 */
memset((char *)stats64 + sizeof(*netdev_stats), 0,
sizeof(*stats64) - sizeof(*netdev_stats));
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 09/84] liquidio: fix bug in soft reset failure detection
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 08/84] net: core: Fix slab-out-of-bounds in netdev_stats_to_stats64 Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 11/84] vrf: fix bug_on triggered by rx when destroying a vrf Greg Kroah-Hartman
` (68 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Derek Chickles, Satanand Burla,
Raghu Vatsavayi, Felix Manlunas, Leon Romanovsky,
David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Derek Chickles <derek.chickles@cavium.com>
[ Upstream commit 05a6b4cae8c0cc1680c9dd33a97a49a13c0f01bc ]
The code that detects a failed soft reset of Octeon is comparing the wrong
value against the reset value of the Octeon SLI_SCRATCH_1 register,
resulting in an inability to detect a soft reset failure. Fix it by using
the correct value in the comparison, which is any non-zero value.
Fixes: f21fb3ed364b ("Add support of Cavium Liquidio ethernet adapters")
Fixes: c0eab5b3580a ("liquidio: CN23XX firmware download")
Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
Signed-off-by: Satanand Burla <satananda.burla@cavium.com>
Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c | 2 +-
drivers/net/ethernet/cavium/liquidio/cn66xx_device.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c
@@ -221,7 +221,7 @@ static int cn23xx_pf_soft_reset(struct o
/* Wait for 100ms as Octeon resets. */
mdelay(100);
- if (octeon_read_csr64(oct, CN23XX_SLI_SCRATCH1) == 0x1234ULL) {
+ if (octeon_read_csr64(oct, CN23XX_SLI_SCRATCH1)) {
dev_err(&oct->pci_dev->dev, "OCTEON[%d]: Soft reset failed\n",
oct->octeon_id);
return 1;
--- a/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/cn66xx_device.c
@@ -44,7 +44,7 @@ int lio_cn6xxx_soft_reset(struct octeon_
/* Wait for 10ms as Octeon resets. */
mdelay(100);
- if (octeon_read_csr64(oct, CN6XXX_SLI_SCRATCH1) == 0x1234ULL) {
+ if (octeon_read_csr64(oct, CN6XXX_SLI_SCRATCH1)) {
dev_err(&oct->pci_dev->dev, "Soft reset failed\n");
return 1;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 11/84] vrf: fix bug_on triggered by rx when destroying a vrf
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 09/84] liquidio: fix bug in soft reset failure detection Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 12/84] virtio-net: fix leaking of ctx array Greg Kroah-Hartman
` (67 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Chris Cormier, Nikolay Aleksandrov,
David Ahern, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
[ Upstream commit f630c38ef0d785101363a8992bbd4f302180f86f ]
When destroying a VRF device we cleanup the slaves in its ndo_uninit()
function, but that causes packets to be switched (skb->dev == vrf being
destroyed) even though we're pass the point where the VRF should be
receiving any packets while it is being dismantled. This causes a BUG_ON
to trigger if we have raw sockets (trace below).
The reason is that the inetdev of the VRF has been destroyed but we're
still sending packets up the stack with it, so let's free the slaves in
the dellink callback as David Ahern suggested.
Note that this fix doesn't prevent packets from going up when the VRF
device is admin down.
[ 35.631371] ------------[ cut here ]------------
[ 35.631603] kernel BUG at net/ipv4/fib_frontend.c:285!
[ 35.631854] invalid opcode: 0000 [#1] SMP
[ 35.631977] Modules linked in:
[ 35.632081] CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 4.12.0-rc7+ #45
[ 35.632247] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 35.632477] task: ffff88005ad68000 task.stack: ffff88005ad64000
[ 35.632632] RIP: 0010:fib_compute_spec_dst+0xfc/0x1ee
[ 35.632769] RSP: 0018:ffff88005ad67978 EFLAGS: 00010202
[ 35.632910] RAX: 0000000000000001 RBX: ffff880059a7f200 RCX: 0000000000000000
[ 35.633084] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff82274af0
[ 35.633256] RBP: ffff88005ad679f8 R08: 000000000001ef70 R09: 0000000000000046
[ 35.633430] R10: ffff88005ad679f8 R11: ffff880037731cb0 R12: 0000000000000001
[ 35.633603] R13: ffff8800599e3000 R14: 0000000000000000 R15: ffff8800599cb852
[ 35.634114] FS: 0000000000000000(0000) GS:ffff88005d900000(0000) knlGS:0000000000000000
[ 35.634306] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.634456] CR2: 00007f3563227095 CR3: 000000000201d000 CR4: 00000000000406e0
[ 35.634632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 35.634865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 35.635055] Call Trace:
[ 35.635271] ? __lock_acquire+0xf0d/0x1117
[ 35.635522] ipv4_pktinfo_prepare+0x82/0x151
[ 35.635831] raw_rcv_skb+0x17/0x3c
[ 35.636062] raw_rcv+0xe5/0xf7
[ 35.636287] raw_local_deliver+0x169/0x1d9
[ 35.636534] ip_local_deliver_finish+0x87/0x1c4
[ 35.636820] ip_local_deliver+0x63/0x7f
[ 35.637058] ip_rcv_finish+0x340/0x3a1
[ 35.637295] ip_rcv+0x314/0x34a
[ 35.637525] __netif_receive_skb_core+0x49f/0x7c5
[ 35.637780] ? lock_acquire+0x13f/0x1d7
[ 35.638018] ? lock_acquire+0x15e/0x1d7
[ 35.638259] __netif_receive_skb+0x1e/0x94
[ 35.638502] ? __netif_receive_skb+0x1e/0x94
[ 35.638748] netif_receive_skb_internal+0x74/0x300
[ 35.639002] ? dev_gro_receive+0x2ed/0x411
[ 35.639246] ? lock_is_held_type+0xc4/0xd2
[ 35.639491] napi_gro_receive+0x105/0x1a0
[ 35.639736] receive_buf+0xc32/0xc74
[ 35.639965] ? detach_buf+0x67/0x153
[ 35.640201] ? virtqueue_get_buf_ctx+0x120/0x176
[ 35.640453] virtnet_poll+0x128/0x1c5
[ 35.640690] net_rx_action+0x103/0x343
[ 35.640932] __do_softirq+0x1c7/0x4b7
[ 35.641171] run_ksoftirqd+0x23/0x5c
[ 35.641403] smpboot_thread_fn+0x24f/0x26d
[ 35.641646] ? sort_range+0x22/0x22
[ 35.641878] kthread+0x129/0x131
[ 35.642104] ? __list_add+0x31/0x31
[ 35.642335] ? __list_add+0x31/0x31
[ 35.642568] ret_from_fork+0x2a/0x40
[ 35.642804] Code: 05 bd 87 a3 00 01 e8 1f ef 98 ff 4d 85 f6 48 c7 c7 f0 4a 27 82 41 0f 94 c4 31 c9 31 d2 41 0f b6 f4 e8 04 71 a1 ff 45 84 e4 74 02 <0f> 0b 0f b7 93 c4 00 00 00 4d 8b a5 80 05 00 00 48 03 93 d0 00
[ 35.644342] RIP: fib_compute_spec_dst+0xfc/0x1ee RSP: ffff88005ad67978
Fixes: 193125dbd8eb ("net: Introduce VRF device driver")
Reported-by: Chris Cormier <chriscormier@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Acked-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/vrf.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -926,15 +926,10 @@ static int vrf_del_slave(struct net_devi
static void vrf_dev_uninit(struct net_device *dev)
{
struct net_vrf *vrf = netdev_priv(dev);
- struct net_device *port_dev;
- struct list_head *iter;
vrf_rtable_release(dev, vrf);
vrf_rt6_release(dev, vrf);
- netdev_for_each_lower_dev(dev, port_dev, iter)
- vrf_del_slave(dev, port_dev);
-
free_percpu(dev->dstats);
dev->dstats = NULL;
}
@@ -1389,6 +1384,12 @@ static int vrf_validate(struct nlattr *t
static void vrf_dellink(struct net_device *dev, struct list_head *head)
{
+ struct net_device *port_dev;
+ struct list_head *iter;
+
+ netdev_for_each_lower_dev(dev, port_dev, iter)
+ vrf_del_slave(dev, port_dev);
+
unregister_netdevice_queue(dev, head);
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 12/84] virtio-net: fix leaking of ctx array
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 11/84] vrf: fix bug_on triggered by rx when destroying a vrf Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 13/84] rds: tcp: use sock_create_lite() to create the accept socket Greg Kroah-Hartman
` (66 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Wang, Michael S. Tsirkin,
David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wang <jasowang@redhat.com>
[ Upstream commit 55281621b6047d2ffb934a0b984ab0cdb1ad1d76 ]
Fixes: commit d45b897b11ea ("virtio_net: allow specifying context for rx")
Signed-off-by: Jason Wang <jasowang@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/virtio_net.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -2221,6 +2221,7 @@ static int virtnet_find_vqs(struct virtn
kfree(names);
kfree(callbacks);
kfree(vqs);
+ kfree(ctx);
return 0;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 13/84] rds: tcp: use sock_create_lite() to create the accept socket
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 12/84] virtio-net: fix leaking of ctx array Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 14/84] net/mlx5e: Initialize CEEs getpermhwaddr address buffer to 0xff Greg Kroah-Hartman
` (65 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sowmini Varadhan, Santosh Shilimkar,
David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
[ Upstream commit 0933a578cd55b02dc80f219dc8f2efb17ec61c9a ]
There are two problems with calling sock_create_kern() from
rds_tcp_accept_one()
1. it sets up a new_sock->sk that is wasteful, because this ->sk
is going to get replaced by inet_accept() in the subsequent ->accept()
2. The new_sock->sk is a leaked reference in sock_graft() which
expects to find a null parent->sk
Avoid these problems by calling sock_create_lite().
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/rds/tcp_listen.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@ -125,7 +125,7 @@ int rds_tcp_accept_one(struct socket *so
if (!sock) /* module unload or netns delete in progress */
return -ENETUNREACH;
- ret = sock_create_kern(sock_net(sock->sk), sock->sk->sk_family,
+ ret = sock_create_lite(sock->sk->sk_family,
sock->sk->sk_type, sock->sk->sk_protocol,
&new_sock);
if (ret)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 14/84] net/mlx5e: Initialize CEEs getpermhwaddr address buffer to 0xff
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 13/84] rds: tcp: use sock_create_lite() to create the accept socket Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 15/84] cxgb4: fix BUG() on interrupt deallocating path of ULD Greg Kroah-Hartman
` (64 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Huy Nguyen, Daniel Jurgens, Saeed Mahameed
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Huy Nguyen <huyn@mellanox.com>
[ Upstream commit d968f0f2e4404152f37ed2384b4a2269dd2dae5a ]
Latest change in open-lldp code uses bytes 6-11 of perm_addr buffer
as the Ethernet source address for the host TLV packet.
Since our driver does not fill these bytes, they stay at zero and
the open-lldp code ends up sending the TLV packet with zero source
address and the switch drops this packet.
The fix is to initialize these bytes to 0xff. The open-lldp code
considers 0xff:ff:ff:ff:ff:ff as the invalid address and falls back to
use the host's mac address as the Ethernet source address.
Fixes: 3a6a931dfb8e ("net/mlx5e: Support DCBX CEE API")
Signed-off-by: Huy Nguyen <huyn@mellanox.com>
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
@@ -464,6 +464,8 @@ static void mlx5e_dcbnl_getpermhwaddr(st
if (!perm_addr)
return;
+ memset(perm_addr, 0xff, MAX_ADDR_LEN);
+
mlx5_query_nic_vport_mac_address(priv->mdev, 0, perm_addr);
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 15/84] cxgb4: fix BUG() on interrupt deallocating path of ULD
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 14/84] net/mlx5e: Initialize CEEs getpermhwaddr address buffer to 0xff Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 16/84] tap: convert a mutex to a spinlock Greg Kroah-Hartman
` (63 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Harsha Thyagaraja,
Guilherme G. Piccoli, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Guilherme G. Piccoli" <gpiccoli@linux.vnet.ibm.com>
[ Upstream commit 6a146f3a5894b751cef16feb3d7903e45e3c445c ]
Since the introduction of ULD (Upper-Layer Drivers), the MSI-X
deallocating path changed in cxgb4: the driver frees the interrupts
of ULD when unregistering it or on shutdown PCI handler.
Problem is that if a MSI-X is not freed before deallocated in the PCI
layer, it will trigger a BUG() due to still "alive" interrupt being
tentatively quiesced.
The below trace was observed when doing a simple unbind of Chelsio's
adapter PCI function, like:
"echo 001e:80:00.4 > /sys/bus/pci/drivers/cxgb4/unbind"
Trace:
kernel BUG at drivers/pci/msi.c:352!
Oops: Exception in kernel mode, sig: 5 [#1]
...
NIP [c0000000005a5e60] free_msi_irqs+0xa0/0x250
LR [c0000000005a5e50] free_msi_irqs+0x90/0x250
Call Trace:
[c0000000005a5e50] free_msi_irqs+0x90/0x250 (unreliable)
[c0000000005a72c4] pci_disable_msix+0x124/0x180
[d000000011e06708] disable_msi+0x88/0xb0 [cxgb4]
[d000000011e06948] free_some_resources+0xa8/0x160 [cxgb4]
[d000000011e06d60] remove_one+0x170/0x3c0 [cxgb4]
[c00000000058a910] pci_device_remove+0x70/0x110
[c00000000064ef04] device_release_driver_internal+0x1f4/0x2c0
...
This patch fixes the issue by refactoring the shutdown path of ULD on
cxgb4 driver, by properly freeing and disabling interrupts on PCI
remove handler too.
Fixes: 0fbc81b3ad51 ("Allocate resources dynamically for all cxgb4 ULD's")
Reported-by: Harsha Thyagaraja <hathyaga@in.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 16 ++++++---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c | 42 ++++++++++++++----------
2 files changed, 36 insertions(+), 22 deletions(-)
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -2055,12 +2055,12 @@ static void detach_ulds(struct adapter *
mutex_lock(&uld_mutex);
list_del(&adap->list_node);
+
for (i = 0; i < CXGB4_ULD_MAX; i++)
- if (adap->uld && adap->uld[i].handle) {
+ if (adap->uld && adap->uld[i].handle)
adap->uld[i].state_change(adap->uld[i].handle,
CXGB4_STATE_DETACH);
- adap->uld[i].handle = NULL;
- }
+
if (netevent_registered && list_empty(&adapter_list)) {
unregister_netevent_notifier(&cxgb4_netevent_nb);
netevent_registered = false;
@@ -5086,8 +5086,10 @@ static void remove_one(struct pci_dev *p
*/
destroy_workqueue(adapter->workq);
- if (is_uld(adapter))
+ if (is_uld(adapter)) {
detach_ulds(adapter);
+ t4_uld_clean_up(adapter);
+ }
disable_interrupts(adapter);
@@ -5164,7 +5166,11 @@ static void shutdown_one(struct pci_dev
if (adapter->port[i]->reg_state == NETREG_REGISTERED)
cxgb_close(adapter->port[i]);
- t4_uld_clean_up(adapter);
+ if (is_uld(adapter)) {
+ detach_ulds(adapter);
+ t4_uld_clean_up(adapter);
+ }
+
disable_interrupts(adapter);
disable_msi(adapter);
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c
@@ -589,22 +589,37 @@ void t4_uld_mem_free(struct adapter *ada
kfree(adap->uld);
}
+/* This function should be called with uld_mutex taken. */
+static void cxgb4_shutdown_uld_adapter(struct adapter *adap, enum cxgb4_uld type)
+{
+ if (adap->uld[type].handle) {
+ adap->uld[type].handle = NULL;
+ adap->uld[type].add = NULL;
+ release_sge_txq_uld(adap, type);
+
+ if (adap->flags & FULL_INIT_DONE)
+ quiesce_rx_uld(adap, type);
+
+ if (adap->flags & USING_MSIX)
+ free_msix_queue_irqs_uld(adap, type);
+
+ free_sge_queues_uld(adap, type);
+ free_queues_uld(adap, type);
+ }
+}
+
void t4_uld_clean_up(struct adapter *adap)
{
unsigned int i;
- if (!adap->uld)
- return;
+ mutex_lock(&uld_mutex);
for (i = 0; i < CXGB4_ULD_MAX; i++) {
if (!adap->uld[i].handle)
continue;
- if (adap->flags & FULL_INIT_DONE)
- quiesce_rx_uld(adap, i);
- if (adap->flags & USING_MSIX)
- free_msix_queue_irqs_uld(adap, i);
- free_sge_queues_uld(adap, i);
- free_queues_uld(adap, i);
+
+ cxgb4_shutdown_uld_adapter(adap, i);
}
+ mutex_unlock(&uld_mutex);
}
static void uld_init(struct adapter *adap, struct cxgb4_lld_info *lld)
@@ -782,15 +797,8 @@ int cxgb4_unregister_uld(enum cxgb4_uld
continue;
if (type == CXGB4_ULD_ISCSIT && is_t4(adap->params.chip))
continue;
- adap->uld[type].handle = NULL;
- adap->uld[type].add = NULL;
- release_sge_txq_uld(adap, type);
- if (adap->flags & FULL_INIT_DONE)
- quiesce_rx_uld(adap, type);
- if (adap->flags & USING_MSIX)
- free_msix_queue_irqs_uld(adap, type);
- free_sge_queues_uld(adap, type);
- free_queues_uld(adap, type);
+
+ cxgb4_shutdown_uld_adapter(adap, type);
}
mutex_unlock(&uld_mutex);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 16/84] tap: convert a mutex to a spinlock
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 15/84] cxgb4: fix BUG() on interrupt deallocating path of ULD Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 17/84] bridge: mdb: fix leak on complete_info ptr on fail path Greg Kroah-Hartman
` (62 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian Borntraeger,
Sainath Grandhi, Cong Wang, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: WANG Cong <xiyou.wangcong@gmail.com>
[ Upstream commit ffa423fb3251f8737303ffc3b0659e86e501808e ]
We are not allowed to block on the RCU reader side, so can't
just hold the mutex as before. As a quick fix, convert it to
a spinlock.
Fixes: d9f1f61c0801 ("tap: Extending tap device create/destroy APIs")
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Sainath Grandhi <sainath.grandhi@intel.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/tap.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
--- a/drivers/net/tap.c
+++ b/drivers/net/tap.c
@@ -106,7 +106,7 @@ struct major_info {
struct rcu_head rcu;
dev_t major;
struct idr minor_idr;
- struct mutex minor_lock;
+ spinlock_t minor_lock;
const char *device_name;
struct list_head next;
};
@@ -416,15 +416,15 @@ int tap_get_minor(dev_t major, struct ta
goto unlock;
}
- mutex_lock(&tap_major->minor_lock);
- retval = idr_alloc(&tap_major->minor_idr, tap, 1, TAP_NUM_DEVS, GFP_KERNEL);
+ spin_lock(&tap_major->minor_lock);
+ retval = idr_alloc(&tap_major->minor_idr, tap, 1, TAP_NUM_DEVS, GFP_ATOMIC);
if (retval >= 0) {
tap->minor = retval;
} else if (retval == -ENOSPC) {
netdev_err(tap->dev, "Too many tap devices\n");
retval = -EINVAL;
}
- mutex_unlock(&tap_major->minor_lock);
+ spin_unlock(&tap_major->minor_lock);
unlock:
rcu_read_unlock();
@@ -442,12 +442,12 @@ void tap_free_minor(dev_t major, struct
goto unlock;
}
- mutex_lock(&tap_major->minor_lock);
+ spin_lock(&tap_major->minor_lock);
if (tap->minor) {
idr_remove(&tap_major->minor_idr, tap->minor);
tap->minor = 0;
}
- mutex_unlock(&tap_major->minor_lock);
+ spin_unlock(&tap_major->minor_lock);
unlock:
rcu_read_unlock();
@@ -467,13 +467,13 @@ static struct tap_dev *dev_get_by_tap_fi
goto unlock;
}
- mutex_lock(&tap_major->minor_lock);
+ spin_lock(&tap_major->minor_lock);
tap = idr_find(&tap_major->minor_idr, minor);
if (tap) {
dev = tap->dev;
dev_hold(dev);
}
- mutex_unlock(&tap_major->minor_lock);
+ spin_unlock(&tap_major->minor_lock);
unlock:
rcu_read_unlock();
@@ -1227,7 +1227,7 @@ static int tap_list_add(dev_t major, con
tap_major->major = MAJOR(major);
idr_init(&tap_major->minor_idr);
- mutex_init(&tap_major->minor_lock);
+ spin_lock_init(&tap_major->minor_lock);
tap_major->device_name = device_name;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 17/84] bridge: mdb: fix leak on complete_info ptr on fail path
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 16/84] tap: convert a mutex to a spinlock Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 19/84] sfc: dont read beyond unicast address list Greg Kroah-Hartman
` (61 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Vallish Vaidyeshwara,
Eduardo Valentin, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eduardo Valentin <eduval@amazon.com>
[ Upstream commit 1bfb159673957644951ab0a8d2aec44b93ddb1ae ]
We currently get the following kmemleak report:
unreferenced object 0xffff8800039d9820 (size 32):
comm "softirq", pid 0, jiffies 4295212383 (age 792.416s)
hex dump (first 32 bytes):
00 0c e0 03 00 88 ff ff ff 02 00 00 00 00 00 00 ................
00 00 00 01 ff 11 00 02 86 dd 00 00 ff ff ff ff ................
backtrace:
[<ffffffff8152b4aa>] kmemleak_alloc+0x4a/0xa0
[<ffffffff811d8ec8>] kmem_cache_alloc_trace+0xb8/0x1c0
[<ffffffffa0389683>] __br_mdb_notify+0x2a3/0x300 [bridge]
[<ffffffffa038a0ce>] br_mdb_notify+0x6e/0x70 [bridge]
[<ffffffffa0386479>] br_multicast_add_group+0x109/0x150 [bridge]
[<ffffffffa0386518>] br_ip6_multicast_add_group+0x58/0x60 [bridge]
[<ffffffffa0387fb5>] br_multicast_rcv+0x1d5/0xdb0 [bridge]
[<ffffffffa037d7cf>] br_handle_frame_finish+0xcf/0x510 [bridge]
[<ffffffffa03a236b>] br_nf_hook_thresh.part.27+0xb/0x10 [br_netfilter]
[<ffffffffa03a3738>] br_nf_hook_thresh+0x48/0xb0 [br_netfilter]
[<ffffffffa03a3fb9>] br_nf_pre_routing_finish_ipv6+0x109/0x1d0 [br_netfilter]
[<ffffffffa03a4400>] br_nf_pre_routing_ipv6+0xd0/0x14c [br_netfilter]
[<ffffffffa03a3c27>] br_nf_pre_routing+0x197/0x3d0 [br_netfilter]
[<ffffffff814a2952>] nf_iterate+0x52/0x60
[<ffffffff814a29bc>] nf_hook_slow+0x5c/0xb0
[<ffffffffa037ddf4>] br_handle_frame+0x1a4/0x2c0 [bridge]
This happens when switchdev_port_obj_add() fails. This patch
frees complete_info object in the fail path.
Reviewed-by: Vallish Vaidyeshwara <vallish@amazon.com>
Signed-off-by: Eduardo Valentin <eduval@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/bridge/br_mdb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -323,7 +323,8 @@ static void __br_mdb_notify(struct net_d
__mdb_entry_to_br_ip(entry, &complete_info->ip);
mdb.obj.complete_priv = complete_info;
mdb.obj.complete = br_mdb_complete;
- switchdev_port_obj_add(port_dev, &mdb.obj);
+ if (switchdev_port_obj_add(port_dev, &mdb.obj))
+ kfree(complete_info);
}
} else if (port_dev && type == RTM_DELMDB) {
switchdev_port_obj_del(port_dev, &mdb.obj);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 19/84] sfc: dont read beyond unicast address list
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (14 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 17/84] bridge: mdb: fix leak on complete_info ptr on fail path Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 20/84] Adding asm-prototypes.h for genksyms to generate crc Greg Kroah-Hartman
` (60 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Bert Kenward, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bert Kenward <bkenward@solarflare.com>
[ Upstream commit c70d68150f71b84cea6997a53493e17bf18a54db ]
If we have more than 32 unicast MAC addresses assigned to an interface
we will read beyond the end of the address table in the driver when
adding filters. The next 256 entries store multicast addresses, so we
will end up attempting to insert duplicate filters, which is mostly
harmless. If we add more than 288 unicast addresses we will then read
past the multicast address table, which is likely to be more exciting.
Fixes: 12fb0da45c9a ("sfc: clean fallbacks between promisc/normal in efx_ef10_filter_sync_rx_mode")
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/sfc/ef10.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -5034,12 +5034,9 @@ static void efx_ef10_filter_uc_addr_list
struct efx_ef10_filter_table *table = efx->filter_state;
struct net_device *net_dev = efx->net_dev;
struct netdev_hw_addr *uc;
- int addr_count;
unsigned int i;
- addr_count = netdev_uc_count(net_dev);
table->uc_promisc = !!(net_dev->flags & IFF_PROMISC);
- table->dev_uc_count = 1 + addr_count;
ether_addr_copy(table->dev_uc_list[0].addr, net_dev->dev_addr);
i = 1;
netdev_for_each_uc_addr(uc, net_dev) {
@@ -5050,6 +5047,8 @@ static void efx_ef10_filter_uc_addr_list
ether_addr_copy(table->dev_uc_list[i].addr, uc->addr);
i++;
}
+
+ table->dev_uc_count = i;
}
static void efx_ef10_filter_mc_addr_list(struct efx_nic *efx)
@@ -5057,12 +5056,11 @@ static void efx_ef10_filter_mc_addr_list
struct efx_ef10_filter_table *table = efx->filter_state;
struct net_device *net_dev = efx->net_dev;
struct netdev_hw_addr *mc;
- unsigned int i, addr_count;
+ unsigned int i;
table->mc_overflow = false;
table->mc_promisc = !!(net_dev->flags & (IFF_PROMISC | IFF_ALLMULTI));
- addr_count = netdev_mc_count(net_dev);
i = 0;
netdev_for_each_mc_addr(mc, net_dev) {
if (i >= EFX_EF10_FILTER_DEV_MC_MAX) {
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 20/84] Adding asm-prototypes.h for genksyms to generate crc
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (15 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 19/84] sfc: dont read beyond unicast address list Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 21/84] sed regex in Makefile.build requires line break between exported symbols Greg Kroah-Hartman
` (59 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nagarathnam Muthusamy, Babu Moger,
David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
[ Upstream commit bdca8cc096203b17ad0ac4e19f50578207e054d2 ]
This patch adds the prototypes of assembly defined functions to asm-prototypes.h.
Some prototypes are directly added as they are not present in any existing header
files.
Signed-off-by: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
Reviewed-by: Babu Moger <babu.moger@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/include/asm/asm-prototypes.h | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 arch/sparc/include/asm/asm-prototypes.h
--- /dev/null
+++ b/arch/sparc/include/asm/asm-prototypes.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2017 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include <asm/xor.h>
+#include <asm/checksum.h>
+#include <asm/trap_block.h>
+#include <asm/uaccess.h>
+#include <asm/atomic.h>
+#include <asm/ftrace.h>
+#include <asm/cacheflush.h>
+#include <asm/oplib.h>
+#include <linux/atomic.h>
+
+void *__memscan_zero(void *, size_t);
+void *__memscan_generic(void *, int, size_t);
+void *__bzero(void *, size_t);
+void VISenter(void); /* Dummy prototype to supress warning */
+#undef memcpy
+#undef memset
+void *memcpy(void *dest, const void *src, size_t n);
+void *memset(void *s, int c, size_t n);
+typedef int TItype __attribute__((mode(TI)));
+TItype __multi3(TItype a, TItype b);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 21/84] sed regex in Makefile.build requires line break between exported symbols
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (16 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 20/84] Adding asm-prototypes.h for genksyms to generate crc Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 22/84] Adding the type of " Greg Kroah-Hartman
` (58 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nagarathnam Muthusamy, Babu Moger,
David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
[ Upstream commit d16c0649feb4fe4e814f44803df5a617769c3233 ]
The following regex in Makefile.build matches only one ___EXPORT_SYMBOL per line.
sed
's/.*___EXPORT_SYMBOL[[:space:]]*\([a-zA-Z0-9_]*\)[[:space:]]*,.*/EXPORT_SYMBOL(\1);/'
ATOMIC_OPS macro in atomic_64.S expands multiple symbols in same line hence
version generation is done only for the last matched symbol. This patch adds
new line between the symbol expansions.
Signed-off-by: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
Reviewed-by: Babu Moger <babu.moger@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/lib/atomic_64.S | 44 ++++++++++++++++++++++++++------------------
1 file changed, 26 insertions(+), 18 deletions(-)
--- a/arch/sparc/lib/atomic_64.S
+++ b/arch/sparc/lib/atomic_64.S
@@ -62,19 +62,23 @@ ENTRY(atomic_fetch_##op) /* %o0 = increm
ENDPROC(atomic_fetch_##op); \
EXPORT_SYMBOL(atomic_fetch_##op);
-#define ATOMIC_OPS(op) ATOMIC_OP(op) ATOMIC_OP_RETURN(op) ATOMIC_FETCH_OP(op)
+ATOMIC_OP(add)
+ATOMIC_OP_RETURN(add)
+ATOMIC_FETCH_OP(add)
+
+ATOMIC_OP(sub)
+ATOMIC_OP_RETURN(sub)
+ATOMIC_FETCH_OP(sub)
-ATOMIC_OPS(add)
-ATOMIC_OPS(sub)
+ATOMIC_OP(and)
+ATOMIC_FETCH_OP(and)
-#undef ATOMIC_OPS
-#define ATOMIC_OPS(op) ATOMIC_OP(op) ATOMIC_FETCH_OP(op)
+ATOMIC_OP(or)
+ATOMIC_FETCH_OP(or)
-ATOMIC_OPS(and)
-ATOMIC_OPS(or)
-ATOMIC_OPS(xor)
+ATOMIC_OP(xor)
+ATOMIC_FETCH_OP(xor)
-#undef ATOMIC_OPS
#undef ATOMIC_FETCH_OP
#undef ATOMIC_OP_RETURN
#undef ATOMIC_OP
@@ -124,19 +128,23 @@ ENTRY(atomic64_fetch_##op) /* %o0 = incr
ENDPROC(atomic64_fetch_##op); \
EXPORT_SYMBOL(atomic64_fetch_##op);
-#define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_OP_RETURN(op) ATOMIC64_FETCH_OP(op)
+ATOMIC64_OP(add)
+ATOMIC64_OP_RETURN(add)
+ATOMIC64_FETCH_OP(add)
+
+ATOMIC64_OP(sub)
+ATOMIC64_OP_RETURN(sub)
+ATOMIC64_FETCH_OP(sub)
-ATOMIC64_OPS(add)
-ATOMIC64_OPS(sub)
+ATOMIC64_OP(and)
+ATOMIC64_FETCH_OP(and)
-#undef ATOMIC64_OPS
-#define ATOMIC64_OPS(op) ATOMIC64_OP(op) ATOMIC64_FETCH_OP(op)
+ATOMIC64_OP(or)
+ATOMIC64_FETCH_OP(or)
-ATOMIC64_OPS(and)
-ATOMIC64_OPS(or)
-ATOMIC64_OPS(xor)
+ATOMIC64_OP(xor)
+ATOMIC64_FETCH_OP(xor)
-#undef ATOMIC64_OPS
#undef ATOMIC64_FETCH_OP
#undef ATOMIC64_OP_RETURN
#undef ATOMIC64_OP
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 22/84] Adding the type of exported symbols
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (17 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 21/84] sed regex in Makefile.build requires line break between exported symbols Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 23/84] sparc64: Fix gup_huge_pmd Greg Kroah-Hartman
` (57 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nagarathnam Muthusamy, Babu Moger,
David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
[ Upstream commit f5a651f1d5e524cab345250a783702fb6a3f14d6 ]
Missing symbol type for few functions prevents genksyms from generating
symbol versions for those functions. This patch fixes them.
Signed-off-by: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
Reviewed-by: Babu Moger <babu.moger@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/lib/checksum_64.S | 1 +
arch/sparc/lib/csum_copy.S | 1 +
arch/sparc/lib/memscan_64.S | 2 ++
arch/sparc/lib/memset.S | 1 +
4 files changed, 5 insertions(+)
--- a/arch/sparc/lib/checksum_64.S
+++ b/arch/sparc/lib/checksum_64.S
@@ -38,6 +38,7 @@ csum_partial_fix_alignment:
.align 32
.globl csum_partial
+ .type csum_partial,#function
EXPORT_SYMBOL(csum_partial)
csum_partial: /* %o0=buff, %o1=len, %o2=sum */
prefetch [%o0 + 0x000], #n_reads
--- a/arch/sparc/lib/csum_copy.S
+++ b/arch/sparc/lib/csum_copy.S
@@ -65,6 +65,7 @@
add %o5, %o4, %o4
.globl FUNC_NAME
+ .type FUNC_NAME,#function
EXPORT_SYMBOL(FUNC_NAME)
FUNC_NAME: /* %o0=src, %o1=dst, %o2=len, %o3=sum */
LOAD(prefetch, %o0 + 0x000, #n_reads)
--- a/arch/sparc/lib/memscan_64.S
+++ b/arch/sparc/lib/memscan_64.S
@@ -14,6 +14,8 @@
.text
.align 32
.globl __memscan_zero, __memscan_generic
+ .type __memscan_zero,#function
+ .type __memscan_generic,#function
.globl memscan
EXPORT_SYMBOL(__memscan_zero)
EXPORT_SYMBOL(__memscan_generic)
--- a/arch/sparc/lib/memset.S
+++ b/arch/sparc/lib/memset.S
@@ -63,6 +63,7 @@
__bzero_begin:
.globl __bzero
+ .type __bzero,#function
.globl memset
EXPORT_SYMBOL(__bzero)
EXPORT_SYMBOL(memset)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 23/84] sparc64: Fix gup_huge_pmd
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (18 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 22/84] Adding the type of " Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 24/84] brcmfmac: Fix a memory leak in error handling path in brcmf_cfg80211_attach Greg Kroah-Hartman
` (56 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Julian Calaby, Nitin Gupta, David S. Miller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nitin Gupta <nitin.m.gupta@oracle.com>
[ Upstream commit dbd2667a4fb9ce4f547982b07cd69dda127c47ea ]
The function assumes that each PMD points to head of a
huge page. This is not correct as a PMD can point to
start of any 8M region with a, say 256M, hugepage. The
fix ensures that it points to the correct head of any PMD
huge page.
Cc: Julian Calaby <julian.calaby@gmail.com>
Signed-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/mm/gup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/sparc/mm/gup.c
+++ b/arch/sparc/mm/gup.c
@@ -78,8 +78,8 @@ static int gup_huge_pmd(pmd_t *pmdp, pmd
return 0;
refs = 0;
- head = pmd_page(pmd);
- page = head + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
+ page = pmd_page(pmd) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
+ head = compound_head(page);
do {
VM_BUG_ON(compound_head(page) != head);
pages[*nr] = page;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 24/84] brcmfmac: Fix a memory leak in error handling path in brcmf_cfg80211_attach
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (19 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 23/84] sparc64: Fix gup_huge_pmd Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 25/84] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain Greg Kroah-Hartman
` (55 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Christophe JAILLET, Kalle Valo
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Jaillet <christophe.jaillet@wanadoo.fr>
commit 57c00f2fac512837f8de73474ec1f54020015bae upstream.
If 'wiphy_new()' fails, we leak 'ops'. Add a new label in the error
handling path to free it in such a case.
Fixes: 5c22fb85102a7 ("brcmfmac: add wowl gtk rekeying offload support")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -6855,7 +6855,7 @@ struct brcmf_cfg80211_info *brcmf_cfg802
wiphy = wiphy_new(ops, sizeof(struct brcmf_cfg80211_info));
if (!wiphy) {
brcmf_err("Could not allocate wiphy device\n");
- return NULL;
+ goto ops_out;
}
memcpy(wiphy->perm_addr, drvr->mac, ETH_ALEN);
set_wiphy_dev(wiphy, busdev);
@@ -6998,6 +6998,7 @@ priv_out:
ifp->vif = NULL;
wiphy_out:
brcmf_free_wiphy(wiphy);
+ops_out:
kfree(ops);
return NULL;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 25/84] brcmfmac: Fix glom_skb leak in brcmf_sdiod_recv_chain
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (20 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 24/84] brcmfmac: Fix a memory leak in error handling path in brcmf_cfg80211_attach Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` Greg Kroah-Hartman
` (54 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter S. Housel, Arend van Spriel,
Kalle Valo
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter S. Housel <housel@acm.org>
commit 5ea59db8a375216e6c915c5586f556766673b5a7 upstream.
An earlier change to this function (3bdae810721b) fixed a leak in the
case of an unsuccessful call to brcmf_sdiod_buffrw(). However, the
glom_skb buffer, used for emulating a scattering read, is never used
or referenced after its contents are copied into the destination
buffers, and therefore always needs to be freed by the end of the
function.
Fixes: 3bdae810721b ("brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain")
Fixes: a413e39a38573 ("brcmfmac: fix brcmf_sdcard_recv_chain() for host without sg support")
Signed-off-by: Peter S. Housel <housel@acm.org>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -706,7 +706,7 @@ done:
int brcmf_sdiod_recv_chain(struct brcmf_sdio_dev *sdiodev,
struct sk_buff_head *pktq, uint totlen)
{
- struct sk_buff *glom_skb;
+ struct sk_buff *glom_skb = NULL;
struct sk_buff *skb;
u32 addr = sdiodev->sbwad;
int err = 0;
@@ -727,10 +727,8 @@ int brcmf_sdiod_recv_chain(struct brcmf_
return -ENOMEM;
err = brcmf_sdiod_buffrw(sdiodev, SDIO_FUNC_2, false, addr,
glom_skb);
- if (err) {
- brcmu_pkt_buf_free_skb(glom_skb);
+ if (err)
goto done;
- }
skb_queue_walk(pktq, skb) {
memcpy(skb->data, glom_skb->data, skb->len);
@@ -741,6 +739,7 @@ int brcmf_sdiod_recv_chain(struct brcmf_
pktq);
done:
+ brcmu_pkt_buf_free_skb(glom_skb);
return err;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 02/84] net/mlx5: Fix driver load error flow when firmware is stuck Greg Kroah-Hartman
` (75 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Kiper, Boris Ostrovsky,
Ard Biesheuvel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3, jgross, linux-efi, matt, xen-devel, Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Kiper <daniel.kiper@oracle.com>
commit 6c64447ec58b0bac612732303f7ab04562124587 upstream.
The current approach, which is the wholesale efi struct initialization from
a 'efi_xen' local template is not robust. Usually if new member is defined
then it is properly initialized in drivers/firmware/efi/efi.c, but not in
arch/x86/xen/efi.c.
The effect is that the Xen initialization clears any fields the generic code
might have set and the Xen code does not know about yet.
I saw this happen a few times, so let's initialize only the EFI struct members
used by Xen and maintain no local duplicate, to avoid such issues in the future.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: jgross@suse.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1498128697-12943-3-git-send-email-daniel.kiper@oracle.com
[ Clarified the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/xen/efi.c | 45 ++++++++++++---------------------------------
1 file changed, 12 insertions(+), 33 deletions(-)
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -54,38 +54,6 @@ static efi_system_table_t efi_systab_xen
.tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
};
-static const struct efi efi_xen __initconst = {
- .systab = NULL, /* Initialized later. */
- .runtime_version = 0, /* Initialized later. */
- .mps = EFI_INVALID_TABLE_ADDR,
- .acpi = EFI_INVALID_TABLE_ADDR,
- .acpi20 = EFI_INVALID_TABLE_ADDR,
- .smbios = EFI_INVALID_TABLE_ADDR,
- .smbios3 = EFI_INVALID_TABLE_ADDR,
- .sal_systab = EFI_INVALID_TABLE_ADDR,
- .boot_info = EFI_INVALID_TABLE_ADDR,
- .hcdp = EFI_INVALID_TABLE_ADDR,
- .uga = EFI_INVALID_TABLE_ADDR,
- .uv_systab = EFI_INVALID_TABLE_ADDR,
- .fw_vendor = EFI_INVALID_TABLE_ADDR,
- .runtime = EFI_INVALID_TABLE_ADDR,
- .config_table = EFI_INVALID_TABLE_ADDR,
- .get_time = xen_efi_get_time,
- .set_time = xen_efi_set_time,
- .get_wakeup_time = xen_efi_get_wakeup_time,
- .set_wakeup_time = xen_efi_set_wakeup_time,
- .get_variable = xen_efi_get_variable,
- .get_next_variable = xen_efi_get_next_variable,
- .set_variable = xen_efi_set_variable,
- .query_variable_info = xen_efi_query_variable_info,
- .update_capsule = xen_efi_update_capsule,
- .query_capsule_caps = xen_efi_query_capsule_caps,
- .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = xen_efi_reset_system,
- .set_virtual_address_map = NULL, /* Not used under Xen. */
- .flags = 0 /* Initialized later. */
-};
-
static efi_system_table_t __init *xen_efi_probe(void)
{
struct xen_platform_op op = {
@@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_ef
/* Here we know that Xen runs on EFI platform. */
- efi = efi_xen;
+ efi.get_time = xen_efi_get_time;
+ efi.set_time = xen_efi_set_time;
+ efi.get_wakeup_time = xen_efi_get_wakeup_time;
+ efi.set_wakeup_time = xen_efi_set_wakeup_time;
+ efi.get_variable = xen_efi_get_variable;
+ efi.get_next_variable = xen_efi_get_next_variable;
+ efi.set_variable = xen_efi_set_variable;
+ efi.query_variable_info = xen_efi_query_variable_info;
+ efi.update_capsule = xen_efi_update_capsule;
+ efi.query_capsule_caps = xen_efi_query_capsule_caps;
+ efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+ efi.reset_system = xen_efi_reset_system;
efi_systab_xen.tables = info->cfg.addr;
efi_systab_xen.nr_tables = info->cfg.nent;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
0 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
Greg Kroah-Hartman, Daniel Kiper, stable, Ingo Molnar, matt,
andrew.cooper3, xen-devel, Boris Ostrovsky, Linus Torvalds,
Thomas Gleixner
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Kiper <daniel.kiper@oracle.com>
commit 6c64447ec58b0bac612732303f7ab04562124587 upstream.
The current approach, which is the wholesale efi struct initialization from
a 'efi_xen' local template is not robust. Usually if new member is defined
then it is properly initialized in drivers/firmware/efi/efi.c, but not in
arch/x86/xen/efi.c.
The effect is that the Xen initialization clears any fields the generic code
might have set and the Xen code does not know about yet.
I saw this happen a few times, so let's initialize only the EFI struct members
used by Xen and maintain no local duplicate, to avoid such issues in the future.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: jgross@suse.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1498128697-12943-3-git-send-email-daniel.kiper@oracle.com
[ Clarified the changelog. ]
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/xen/efi.c | 45 ++++++++++++---------------------------------
1 file changed, 12 insertions(+), 33 deletions(-)
--- a/arch/x86/xen/efi.c
+++ b/arch/x86/xen/efi.c
@@ -54,38 +54,6 @@ static efi_system_table_t efi_systab_xen
.tables = EFI_INVALID_TABLE_ADDR /* Initialized later. */
};
-static const struct efi efi_xen __initconst = {
- .systab = NULL, /* Initialized later. */
- .runtime_version = 0, /* Initialized later. */
- .mps = EFI_INVALID_TABLE_ADDR,
- .acpi = EFI_INVALID_TABLE_ADDR,
- .acpi20 = EFI_INVALID_TABLE_ADDR,
- .smbios = EFI_INVALID_TABLE_ADDR,
- .smbios3 = EFI_INVALID_TABLE_ADDR,
- .sal_systab = EFI_INVALID_TABLE_ADDR,
- .boot_info = EFI_INVALID_TABLE_ADDR,
- .hcdp = EFI_INVALID_TABLE_ADDR,
- .uga = EFI_INVALID_TABLE_ADDR,
- .uv_systab = EFI_INVALID_TABLE_ADDR,
- .fw_vendor = EFI_INVALID_TABLE_ADDR,
- .runtime = EFI_INVALID_TABLE_ADDR,
- .config_table = EFI_INVALID_TABLE_ADDR,
- .get_time = xen_efi_get_time,
- .set_time = xen_efi_set_time,
- .get_wakeup_time = xen_efi_get_wakeup_time,
- .set_wakeup_time = xen_efi_set_wakeup_time,
- .get_variable = xen_efi_get_variable,
- .get_next_variable = xen_efi_get_next_variable,
- .set_variable = xen_efi_set_variable,
- .query_variable_info = xen_efi_query_variable_info,
- .update_capsule = xen_efi_update_capsule,
- .query_capsule_caps = xen_efi_query_capsule_caps,
- .get_next_high_mono_count = xen_efi_get_next_high_mono_count,
- .reset_system = xen_efi_reset_system,
- .set_virtual_address_map = NULL, /* Not used under Xen. */
- .flags = 0 /* Initialized later. */
-};
-
static efi_system_table_t __init *xen_efi_probe(void)
{
struct xen_platform_op op = {
@@ -102,7 +70,18 @@ static efi_system_table_t __init *xen_ef
/* Here we know that Xen runs on EFI platform. */
- efi = efi_xen;
+ efi.get_time = xen_efi_get_time;
+ efi.set_time = xen_efi_set_time;
+ efi.get_wakeup_time = xen_efi_get_wakeup_time;
+ efi.set_wakeup_time = xen_efi_set_wakeup_time;
+ efi.get_variable = xen_efi_get_variable;
+ efi.get_next_variable = xen_efi_get_next_variable;
+ efi.set_variable = xen_efi_set_variable;
+ efi.query_variable_info = xen_efi_query_variable_info;
+ efi.update_capsule = xen_efi_update_capsule;
+ efi.query_capsule_caps = xen_efi_query_capsule_caps;
+ efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+ efi.reset_system = xen_efi_reset_system;
efi_systab_xen.tables = info->cfg.addr;
efi_systab_xen.nr_tables = info->cfg.nent;
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 9:43 ` Greg Kroah-Hartman
(?)
@ 2017-07-19 10:37 ` Daniel Kiper
-1 siblings, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-19 10:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, linux-kernel, stable, Ingo Molnar, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
Hey Greg,
On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> 4.12-stable review patch. If anyone has any objections, please let me know.
Why did you skip this patch for 4.11? IMO it should be applied there too.
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 9:43 ` Greg Kroah-Hartman
(?)
(?)
@ 2017-07-19 10:37 ` Daniel Kiper
2017-07-19 11:12 ` Greg Kroah-Hartman
` (2 more replies)
-1 siblings, 3 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-19 10:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, andrew.cooper3,
jgross, linux-efi, matt, xen-devel, Ingo Molnar
Hey Greg,
On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> 4.12-stable review patch. If anyone has any objections, please let me know.
Why did you skip this patch for 4.11? IMO it should be applied there too.
Daniel
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 10:37 ` Daniel Kiper
@ 2017-07-19 11:12 ` Greg Kroah-Hartman
2017-07-19 11:19 ` Greg Kroah-Hartman
` (3 more replies)
2017-07-19 11:12 ` Greg Kroah-Hartman
2017-07-20 8:39 ` Ingo Molnar
2 siblings, 4 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 11:12 UTC (permalink / raw)
To: Daniel Kiper
Cc: linux-kernel, stable, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, andrew.cooper3,
jgross, linux-efi, matt, xen-devel, Ingo Molnar
On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> Hey Greg,
>
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch. If anyone has any objections, please let me know.
>
> Why did you skip this patch for 4.11? IMO it should be applied there too.
Are you sure it actually applied? (hint, it did not...)
If you want it in 4.11, or older kernels, please provide a working
backport.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 11:12 ` Greg Kroah-Hartman
@ 2017-07-19 11:19 ` Greg Kroah-Hartman
2017-07-19 11:19 ` Greg Kroah-Hartman
` (2 subsequent siblings)
3 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 11:19 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, linux-kernel, stable, Ingo Molnar, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> Are you sure it actually applied? (hint, it did not...)
>
> If you want it in 4.11, or older kernels, please provide a working
> backport.
And, in the future, if you want it to be applied to older kernels, or be
notified if it can not be, please add a kernel version number in the
stable marking:
Cc: stable@vger.kernel.org # 4.0+
or use the Fixes: tag:
Fixes: SHASHAHSA ("short description")
which I pick up on and let you know if the patch does not actually apply
back to the kernel that the fixes: tag was in.
hope this helps,
greg k-h
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 11:12 ` Greg Kroah-Hartman
2017-07-19 11:19 ` Greg Kroah-Hartman
@ 2017-07-19 11:19 ` Greg Kroah-Hartman
2017-07-19 11:57 ` Daniel Kiper
2017-07-19 11:57 ` Daniel Kiper
2017-07-19 11:28 ` Daniel Kiper
2017-07-19 11:28 ` Daniel Kiper
3 siblings, 2 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 11:19 UTC (permalink / raw)
To: Daniel Kiper
Cc: linux-kernel, stable, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, andrew.cooper3,
jgross, linux-efi, matt, xen-devel, Ingo Molnar
On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> Are you sure it actually applied? (hint, it did not...)
>
> If you want it in 4.11, or older kernels, please provide a working
> backport.
And, in the future, if you want it to be applied to older kernels, or be
notified if it can not be, please add a kernel version number in the
stable marking:
Cc: stable@vger.kernel.org # 4.0+
or use the Fixes: tag:
Fixes: SHASHAHSA ("short description")
which I pick up on and let you know if the patch does not actually apply
back to the kernel that the fixes: tag was in.
hope this helps,
greg k-h
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 11:19 ` Greg Kroah-Hartman
@ 2017-07-19 11:57 ` Daniel Kiper
2017-07-19 11:57 ` Daniel Kiper
1 sibling, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-19 11:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, linux-kernel, stable, Ingo Molnar, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
On Wed, Jul 19, 2017 at 01:19:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > Are you sure it actually applied? (hint, it did not...)
> >
> > If you want it in 4.11, or older kernels, please provide a working
> > backport.
>
> And, in the future, if you want it to be applied to older kernels, or be
> notified if it can not be, please add a kernel version number in the
> stable marking:
> Cc: stable@vger.kernel.org # 4.0+
> or use the Fixes: tag:
> Fixes: SHASHAHSA ("short description")
> which I pick up on and let you know if the patch does not actually apply
> back to the kernel that the fixes: tag was in.
>
> hope this helps,
Sure thing! Thanks a lot!
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 11:19 ` Greg Kroah-Hartman
2017-07-19 11:57 ` Daniel Kiper
@ 2017-07-19 11:57 ` Daniel Kiper
1 sibling, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-19 11:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, andrew.cooper3,
jgross, linux-efi, matt, xen-devel, Ingo Molnar
On Wed, Jul 19, 2017 at 01:19:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > Are you sure it actually applied? (hint, it did not...)
> >
> > If you want it in 4.11, or older kernels, please provide a working
> > backport.
>
> And, in the future, if you want it to be applied to older kernels, or be
> notified if it can not be, please add a kernel version number in the
> stable marking:
> Cc: stable@vger.kernel.org # 4.0+
> or use the Fixes: tag:
> Fixes: SHASHAHSA ("short description")
> which I pick up on and let you know if the patch does not actually apply
> back to the kernel that the fixes: tag was in.
>
> hope this helps,
Sure thing! Thanks a lot!
Daniel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 11:12 ` Greg Kroah-Hartman
2017-07-19 11:19 ` Greg Kroah-Hartman
2017-07-19 11:19 ` Greg Kroah-Hartman
@ 2017-07-19 11:28 ` Daniel Kiper
2017-07-19 11:28 ` Daniel Kiper
3 siblings, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-19 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, linux-kernel, stable, Ingo Molnar, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> Are you sure it actually applied? (hint, it did not...)
>
> If you want it in 4.11, or older kernels, please provide a working
> backport.
OK, if it did not apply then probably there were some changes in the code
here and there. Though, IIRC, fix itself is perfectly valid for 4.11.
So, I will post updated patch for it.
Thanks,
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 11:12 ` Greg Kroah-Hartman
` (2 preceding siblings ...)
2017-07-19 11:28 ` Daniel Kiper
@ 2017-07-19 11:28 ` Daniel Kiper
3 siblings, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-19 11:28 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, andrew.cooper3,
jgross, linux-efi, matt, xen-devel, Ingo Molnar
On Wed, Jul 19, 2017 at 01:12:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> Are you sure it actually applied? (hint, it did not...)
>
> If you want it in 4.11, or older kernels, please provide a working
> backport.
OK, if it did not apply then probably there were some changes in the code
here and there. Though, IIRC, fix itself is perfectly valid for 4.11.
So, I will post updated patch for it.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 10:37 ` Daniel Kiper
2017-07-19 11:12 ` Greg Kroah-Hartman
@ 2017-07-19 11:12 ` Greg Kroah-Hartman
2017-07-20 8:39 ` Ingo Molnar
2 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 11:12 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, linux-kernel, stable, Ingo Molnar, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
On Wed, Jul 19, 2017 at 12:37:47PM +0200, Daniel Kiper wrote:
> Hey Greg,
>
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch. If anyone has any objections, please let me know.
>
> Why did you skip this patch for 4.11? IMO it should be applied there too.
Are you sure it actually applied? (hint, it did not...)
If you want it in 4.11, or older kernels, please provide a working
backport.
thanks,
greg k-h
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-19 10:37 ` Daniel Kiper
@ 2017-07-20 8:39 ` Ingo Molnar
2017-07-19 11:12 ` Greg Kroah-Hartman
2017-07-20 8:39 ` Ingo Molnar
2 siblings, 0 replies; 106+ messages in thread
From: Ingo Molnar @ 2017-07-20 8:39 UTC (permalink / raw)
To: Daniel Kiper
Cc: Greg Kroah-Hartman, linux-kernel, stable, Boris Ostrovsky,
Ard Biesheuvel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3, jgross, linux-efi, matt, xen-devel
* Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Hey Greg,
>
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch. If anyone has any objections, please let me know.
>
> Why did you skip this patch for 4.11? IMO it should be applied there too.
The thing is, this patch should probaly not even be in v4.12, as it should only
make any difference if there's a separate _bug_ in the kernel.
This patch makes things more robust going forward, but I question that it needs to
be in -stable.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-20 8:39 ` Ingo Molnar
0 siblings, 0 replies; 106+ messages in thread
From: Ingo Molnar @ 2017-07-20 8:39 UTC (permalink / raw)
To: Daniel Kiper
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
Greg Kroah-Hartman, linux-kernel, stable, matt, andrew.cooper3,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
* Daniel Kiper <daniel.kiper@oracle.com> wrote:
> Hey Greg,
>
> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > 4.12-stable review patch. If anyone has any objections, please let me know.
>
> Why did you skip this patch for 4.11? IMO it should be applied there too.
The thing is, this patch should probaly not even be in v4.12, as it should only
make any difference if there's a separate _bug_ in the kernel.
This patch makes things more robust going forward, but I question that it needs to
be in -stable.
Thanks,
Ingo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-20 8:39 ` Ingo Molnar
(?)
@ 2017-07-20 9:16 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-20 9:16 UTC (permalink / raw)
To: Ingo Molnar
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, Daniel Kiper, linux-kernel, stable, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
>
> * Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> The thing is, this patch should probaly not even be in v4.12, as it should only
> make any difference if there's a separate _bug_ in the kernel.
>
> This patch makes things more robust going forward, but I question that it needs to
> be in -stable.
Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
tree as it obviously isn't stable material, sorry for not catching that
before.
thanks,
greg k-h
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-20 8:39 ` Ingo Molnar
(?)
(?)
@ 2017-07-20 9:16 ` Greg Kroah-Hartman
2017-07-20 9:41 ` Ingo Molnar
` (3 more replies)
-1 siblings, 4 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-20 9:16 UTC (permalink / raw)
To: Ingo Molnar
Cc: Daniel Kiper, linux-kernel, stable, Boris Ostrovsky,
Ard Biesheuvel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3, jgross, linux-efi, matt, xen-devel
On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
>
> * Daniel Kiper <daniel.kiper@oracle.com> wrote:
>
> > Hey Greg,
> >
> > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > 4.12-stable review patch. If anyone has any objections, please let me know.
> >
> > Why did you skip this patch for 4.11? IMO it should be applied there too.
>
> The thing is, this patch should probaly not even be in v4.12, as it should only
> make any difference if there's a separate _bug_ in the kernel.
>
> This patch makes things more robust going forward, but I question that it needs to
> be in -stable.
Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
tree as it obviously isn't stable material, sorry for not catching that
before.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-20 9:41 ` Ingo Molnar
0 siblings, 0 replies; 106+ messages in thread
From: Ingo Molnar @ 2017-07-20 9:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Kiper, linux-kernel, stable, Boris Ostrovsky,
Ard Biesheuvel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3, jgross, linux-efi, matt, xen-devel
* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.
I should have caught the tag as well when applying the upstream patch to begin
with.
Thanks!
Ingo
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-20 9:41 ` Ingo Molnar
0 siblings, 0 replies; 106+ messages in thread
From: Ingo Molnar @ 2017-07-20 9:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Daniel Kiper, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3-Sxgqhf6Nn4DQT0dZR+AlfA, jgross-IBi9RG/b67k,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
matt-mF/unelCI9GS6iBeEJttW/XRex20P6io,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b
* Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.
I should have caught the tag as well when applying the upstream patch to begin
with.
Thanks!
Ingo
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-20 9:16 ` Greg Kroah-Hartman
2017-07-20 9:41 ` Ingo Molnar
@ 2017-07-20 9:41 ` Ingo Molnar
2017-07-20 12:33 ` Daniel Kiper
2017-07-20 12:33 ` Daniel Kiper
3 siblings, 0 replies; 106+ messages in thread
From: Ingo Molnar @ 2017-07-20 9:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
andrew.cooper3, Daniel Kiper, linux-kernel, stable, matt,
xen-devel, Boris Ostrovsky, Linus Torvalds, Thomas Gleixner
* Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.
I should have caught the tag as well when applying the upstream patch to begin
with.
Thanks!
Ingo
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-20 9:16 ` Greg Kroah-Hartman
2017-07-20 9:41 ` Ingo Molnar
2017-07-20 9:41 ` Ingo Molnar
@ 2017-07-20 12:33 ` Daniel Kiper
2017-07-20 12:33 ` Daniel Kiper
3 siblings, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-20 12:33 UTC (permalink / raw)
To: gregkh, jgross
Cc: linux-efi, Ard Biesheuvel, Peter Zijlstra, andrew.cooper3,
linux-kernel, stable, matt, Thomas Gleixner, xen-devel,
Boris Ostrovsky, Linus Torvalds, Ingo Molnar
On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.
Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
found/assigned by/to him. Juergen? If it is true then I would apply it to
stable. If I am wrong you can drop it.
Thanks,
Daniel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-20 12:33 ` Daniel Kiper
0 siblings, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-20 12:33 UTC (permalink / raw)
To: gregkh, jgross
Cc: Ingo Molnar, linux-kernel, stable, Boris Ostrovsky,
Ard Biesheuvel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3, linux-efi, matt, xen-devel
On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper@oracle.com> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.
Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
found/assigned by/to him. Juergen? If it is true then I would apply it to
stable. If I am wrong you can drop it.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-20 12:33 ` Daniel Kiper
0 siblings, 0 replies; 106+ messages in thread
From: Daniel Kiper @ 2017-07-20 12:33 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, jgross-IBi9RG/b67k
Cc: Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3-Sxgqhf6Nn4DQT0dZR+AlfA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
matt-mF/unelCI9GS6iBeEJttW/XRex20P6io,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b
On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
> >
> > * Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
> >
> > > Hey Greg,
> > >
> > > On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
> > > > 4.12-stable review patch. If anyone has any objections, please let me know.
> > >
> > > Why did you skip this patch for 4.11? IMO it should be applied there too.
> >
> > The thing is, this patch should probaly not even be in v4.12, as it should only
> > make any difference if there's a separate _bug_ in the kernel.
> >
> > This patch makes things more robust going forward, but I question that it needs to
> > be in -stable.
>
> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
> tree as it obviously isn't stable material, sorry for not catching that
> before.
Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
found/assigned by/to him. Juergen? If it is true then I would apply it to
stable. If I am wrong you can drop it.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
2017-07-20 12:33 ` Daniel Kiper
(?)
@ 2017-07-21 6:32 ` Juergen Gross
-1 siblings, 0 replies; 106+ messages in thread
From: Juergen Gross @ 2017-07-21 6:32 UTC (permalink / raw)
To: Daniel Kiper, gregkh
Cc: linux-efi, Ard Biesheuvel, Peter Zijlstra, andrew.cooper3,
linux-kernel, stable, matt, Thomas Gleixner, xen-devel,
Boris Ostrovsky, Linus Torvalds, Ingo Molnar
On 20/07/17 14:33, Daniel Kiper wrote:
> On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
>>>
>>> * Daniel Kiper <daniel.kiper@oracle.com> wrote:
>>>
>>>> Hey Greg,
>>>>
>>>> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
>>>>> 4.12-stable review patch. If anyone has any objections, please let me know.
>>>>
>>>> Why did you skip this patch for 4.11? IMO it should be applied there too.
>>>
>>> The thing is, this patch should probaly not even be in v4.12, as it should only
>>> make any difference if there's a separate _bug_ in the kernel.
>>>
>>> This patch makes things more robust going forward, but I question that it needs to
>>> be in -stable.
>>
>> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
>> tree as it obviously isn't stable material, sorry for not catching that
>> before.
>
> Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
> found/assigned by/to him. Juergen? If it is true then I would apply it to
> stable. If I am wrong you can drop it.
I'm not sure both patches (this one and upstream 457ea3f7e97881f) are
needed. I have got a report about a failing boot and with both patches
applied the boot is working. I will ask if 457ea3f7e97881f alone works,
too. If it doesn't I'll request this patch to be added to stable again.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-21 6:32 ` Juergen Gross
0 siblings, 0 replies; 106+ messages in thread
From: Juergen Gross @ 2017-07-21 6:32 UTC (permalink / raw)
To: Daniel Kiper, gregkh
Cc: Ingo Molnar, linux-kernel, stable, Boris Ostrovsky,
Ard Biesheuvel, Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3, linux-efi, matt, xen-devel
On 20/07/17 14:33, Daniel Kiper wrote:
> On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
>>>
>>> * Daniel Kiper <daniel.kiper@oracle.com> wrote:
>>>
>>>> Hey Greg,
>>>>
>>>> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
>>>>> 4.12-stable review patch. If anyone has any objections, please let me know.
>>>>
>>>> Why did you skip this patch for 4.11? IMO it should be applied there too.
>>>
>>> The thing is, this patch should probaly not even be in v4.12, as it should only
>>> make any difference if there's a separate _bug_ in the kernel.
>>>
>>> This patch makes things more robust going forward, but I question that it needs to
>>> be in -stable.
>>
>> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
>> tree as it obviously isn't stable material, sorry for not catching that
>> before.
>
> Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
> found/assigned by/to him. Juergen? If it is true then I would apply it to
> stable. If I am wrong you can drop it.
I'm not sure both patches (this one and upstream 457ea3f7e97881f) are
needed. I have got a report about a failing boot and with both patches
applied the boot is working. I will ask if 457ea3f7e97881f alone works,
too. If it doesn't I'll request this patch to be added to stable again.
Juergen
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 26/84] x86/xen/efi: Initialize only the EFI struct members used by Xen
@ 2017-07-21 6:32 ` Juergen Gross
0 siblings, 0 replies; 106+ messages in thread
From: Juergen Gross @ 2017-07-21 6:32 UTC (permalink / raw)
To: Daniel Kiper, gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r
Cc: Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
stable-u79uwXL29TY76Z2rM5mHXA, Boris Ostrovsky, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner,
andrew.cooper3-Sxgqhf6Nn4DQT0dZR+AlfA,
linux-efi-u79uwXL29TY76Z2rM5mHXA,
matt-mF/unelCI9GS6iBeEJttW/XRex20P6io,
xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b
On 20/07/17 14:33, Daniel Kiper wrote:
> On Thu, Jul 20, 2017 at 11:16:39AM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Jul 20, 2017 at 10:39:10AM +0200, Ingo Molnar wrote:
>>>
>>> * Daniel Kiper <daniel.kiper-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:
>>>
>>>> Hey Greg,
>>>>
>>>> On Wed, Jul 19, 2017 at 11:43:32AM +0200, Greg Kroah-Hartman wrote:
>>>>> 4.12-stable review patch. If anyone has any objections, please let me know.
>>>>
>>>> Why did you skip this patch for 4.11? IMO it should be applied there too.
>>>
>>> The thing is, this patch should probaly not even be in v4.12, as it should only
>>> make any difference if there's a separate _bug_ in the kernel.
>>>
>>> This patch makes things more robust going forward, but I question that it needs to
>>> be in -stable.
>>
>> Yeah, good point, I'm going to go drop it entirely from the 4.12-stable
>> tree as it obviously isn't stable material, sorry for not catching that
>> before.
>
> Wait a minute. IIRC, Juergen told me last week that this patch fixes a bug
> found/assigned by/to him. Juergen? If it is true then I would apply it to
> stable. If I am wrong you can drop it.
I'm not sure both patches (this one and upstream 457ea3f7e97881f) are
needed. I have got a report about a failing boot and with both patches
applied the boot is working. I will ask if 457ea3f7e97881f alone works,
too. If it doesn't I'll request this patch to be added to stable again.
Juergen
^ permalink raw reply [flat|nested] 106+ messages in thread
* [PATCH 4.12 27/84] efi: Process the MEMATTR table only if EFI_MEMMAP is enabled
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (22 preceding siblings ...)
2017-07-19 9:43 ` Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` Greg Kroah-Hartman
` (52 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Daniel Kiper, Ard Biesheuvel,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, andrew.cooper3,
boris.ostrovsky, jgross, linux-efi, matt, xen-devel, Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Kiper <daniel.kiper@oracle.com>
commit 457ea3f7e97881f937136ce0ba1f29f82b9abdb0 upstream.
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more targeted and covers more cases.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: boris.ostrovsky@oracle.com
Cc: jgross@suse.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.kiper@oracle.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/efi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -528,7 +528,8 @@ int __init efi_config_parse_tables(void
}
}
- efi_memattr_init();
+ if (efi_enabled(EFI_MEMMAP))
+ efi_memattr_init();
/* Parse the EFI Properties table if it exists */
if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 27/84] efi: Process the MEMATTR table only if EFI_MEMMAP is enabled
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (23 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 27/84] efi: Process the MEMATTR table only if EFI_MEMMAP is enabled Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 28/84] cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE Greg Kroah-Hartman
` (51 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: jgross, linux-efi, Ard Biesheuvel, Peter Zijlstra,
Greg Kroah-Hartman, Daniel Kiper, stable, Ingo Molnar, matt,
andrew.cooper3, xen-devel, Thomas Gleixner, Linus Torvalds,
boris.ostrovsky
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Kiper <daniel.kiper@oracle.com>
commit 457ea3f7e97881f937136ce0ba1f29f82b9abdb0 upstream.
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes.
In theory we can check EFI_PARAVIRT too, however,
EFI_MEMMAP looks more targeted and covers more cases.
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: andrew.cooper3@citrix.com
Cc: boris.ostrovsky@oracle.com
Cc: jgross@suse.com
Cc: linux-efi@vger.kernel.org
Cc: matt@codeblueprint.co.uk
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.kiper@oracle.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/firmware/efi/efi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -528,7 +528,8 @@ int __init efi_config_parse_tables(void
}
}
- efi_memattr_init();
+ if (efi_enabled(EFI_MEMMAP))
+ efi_memattr_init();
/* Parse the EFI Properties table if it exists */
if (efi.properties_table != EFI_INVALID_TABLE_ADDR) {
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 28/84] cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (24 preceding siblings ...)
2017-07-19 9:43 ` Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 29/84] cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES Greg Kroah-Hartman
` (50 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Srinivas Dasari, Jouni Malinen,
Johannes Berg
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Dasari <dasaris@qti.qualcomm.com>
commit 8feb69c7bd89513be80eb19198d48f154b254021 upstream.
Buffer overread may happen as nl80211_set_station() reads 4 bytes
from the attribute NL80211_ATTR_LOCAL_MESH_POWER_MODE without
validating the size of data received when userspace sends less
than 4 bytes of data with NL80211_ATTR_LOCAL_MESH_POWER_MODE.
Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE to avoid
the buffer overread.
Fixes: 3b1c5a5307f ("{cfg,nl}80211: mesh power mode primitives and userspace access")
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/nl80211.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -348,6 +348,7 @@ static const struct nla_policy nl80211_p
[NL80211_ATTR_SCAN_FLAGS] = { .type = NLA_U32 },
[NL80211_ATTR_P2P_CTWINDOW] = { .type = NLA_U8 },
[NL80211_ATTR_P2P_OPPPS] = { .type = NLA_U8 },
+ [NL80211_ATTR_LOCAL_MESH_POWER_MODE] = {. type = NLA_U32 },
[NL80211_ATTR_ACL_POLICY] = {. type = NLA_U32 },
[NL80211_ATTR_MAC_ADDRS] = { .type = NLA_NESTED },
[NL80211_ATTR_STA_CAPABILITY] = { .type = NLA_U16 },
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 29/84] cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (25 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 28/84] cfg80211: Define nla_policy for NL80211_ATTR_LOCAL_MESH_POWER_MODE Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 30/84] cfg80211: Check if PMKID attribute is of expected size Greg Kroah-Hartman
` (49 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Srinivas Dasari, Jouni Malinen,
Johannes Berg
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Dasari <dasaris@qti.qualcomm.com>
commit d7f13f7450369281a5d0ea463cc69890a15923ae upstream.
validate_scan_freqs() retrieves frequencies from attributes
nested in the attribute NL80211_ATTR_SCAN_FREQUENCIES with
nla_get_u32(), which reads 4 bytes from each attribute
without validating the size of data received. Attributes
nested in NL80211_ATTR_SCAN_FREQUENCIES don't have an nla policy.
Validate size of each attribute before parsing to avoid potential buffer
overread.
Fixes: 2a519311926 ("cfg80211/nl80211: scanning (and mac80211 update to use it)")
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/nl80211.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6470,6 +6470,10 @@ static int validate_scan_freqs(struct nl
struct nlattr *attr1, *attr2;
int n_channels = 0, tmp1, tmp2;
+ nla_for_each_nested(attr1, freqs, tmp1)
+ if (nla_len(attr1) != sizeof(u32))
+ return 0;
+
nla_for_each_nested(attr1, freqs, tmp1) {
n_channels++;
/*
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 30/84] cfg80211: Check if PMKID attribute is of expected size
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (26 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 29/84] cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 31/84] cfg80211: Check if NAN service ID " Greg Kroah-Hartman
` (48 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Srinivas Dasari, Jouni Malinen,
Johannes Berg
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Dasari <dasaris@qti.qualcomm.com>
commit 9361df14d1cbf966409d5d6f48bb334384fbe138 upstream.
nla policy checks for only maximum length of the attribute data
when the attribute type is NLA_BINARY. If userspace sends less
data than specified, the wireless drivers may access illegal
memory. When type is NLA_UNSPEC, nla policy check ensures that
userspace sends minimum specified length number of bytes.
Remove type assignment to NLA_BINARY from nla_policy of
NL80211_ATTR_PMKID to make this NLA_UNSPEC and to make sure minimum
WLAN_PMKID_LEN bytes are received from userspace with
NL80211_ATTR_PMKID.
Fixes: 67fbb16be69d ("nl80211: PMKSA caching support")
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/nl80211.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -291,8 +291,7 @@ static const struct nla_policy nl80211_p
[NL80211_ATTR_WPA_VERSIONS] = { .type = NLA_U32 },
[NL80211_ATTR_PID] = { .type = NLA_U32 },
[NL80211_ATTR_4ADDR] = { .type = NLA_U8 },
- [NL80211_ATTR_PMKID] = { .type = NLA_BINARY,
- .len = WLAN_PMKID_LEN },
+ [NL80211_ATTR_PMKID] = { .len = WLAN_PMKID_LEN },
[NL80211_ATTR_DURATION] = { .type = NLA_U32 },
[NL80211_ATTR_COOKIE] = { .type = NLA_U64 },
[NL80211_ATTR_TX_RATES] = { .type = NLA_NESTED },
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 31/84] cfg80211: Check if NAN service ID is of expected size
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (27 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 30/84] cfg80211: Check if PMKID attribute is of expected size Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 32/84] drm/amdgpu/gfx6: properly cache mc_arb_ramcfg Greg Kroah-Hartman
` (47 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Srinivas Dasari, Jouni Malinen,
Johannes Berg
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Srinivas Dasari <dasaris@qti.qualcomm.com>
commit 0a27844ce86d039d74221dd56cd8c0349b146b63 upstream.
nla policy checks for only maximum length of the attribute data when the
attribute type is NLA_BINARY. If userspace sends less data than
specified, cfg80211 may access illegal memory. When type is NLA_UNSPEC,
nla policy check ensures that userspace sends minimum specified length
number of bytes.
Remove type assignment to NLA_BINARY from nla_policy of
NL80211_NAN_FUNC_SERVICE_ID to make these NLA_UNSPEC and to make sure
minimum NL80211_NAN_FUNC_SERVICE_ID_LEN bytes are received from
userspace with NL80211_NAN_FUNC_SERVICE_ID.
Fixes: a442b761b24 ("cfg80211: add add_nan_func / del_nan_func")
Signed-off-by: Srinivas Dasari <dasaris@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -520,7 +520,7 @@ nl80211_bss_select_policy[NL80211_BSS_SE
static const struct nla_policy
nl80211_nan_func_policy[NL80211_NAN_FUNC_ATTR_MAX + 1] = {
[NL80211_NAN_FUNC_TYPE] = { .type = NLA_U8 },
- [NL80211_NAN_FUNC_SERVICE_ID] = { .type = NLA_BINARY,
+ [NL80211_NAN_FUNC_SERVICE_ID] = {
.len = NL80211_NAN_FUNC_SERVICE_ID_LEN },
[NL80211_NAN_FUNC_PUBLISH_TYPE] = { .type = NLA_U8 },
[NL80211_NAN_FUNC_PUBLISH_BCAST] = { .type = NLA_FLAG },
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 32/84] drm/amdgpu/gfx6: properly cache mc_arb_ramcfg
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (28 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 31/84] cfg80211: Check if NAN service ID " Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 33/84] KVM: ARM64: fix phy counter access failure in guest Greg Kroah-Hartman
` (46 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Huang Rui, Alex Deucher
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Deucher <alexander.deucher@amd.com>
commit 6653ebd48f493efe3f3598ff3fe7b3d5451665df upstream.
This was missing for gfx6.
Acked-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c
@@ -1688,7 +1688,8 @@ static void gfx_v6_0_gpu_init(struct amd
WREG32(mmBIF_FB_EN, BIF_FB_EN__FB_READ_EN_MASK | BIF_FB_EN__FB_WRITE_EN_MASK);
mc_shared_chmap = RREG32(mmMC_SHARED_CHMAP);
- mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
+ adev->gfx.config.mc_arb_ramcfg = RREG32(mmMC_ARB_RAMCFG);
+ mc_arb_ramcfg = adev->gfx.config.mc_arb_ramcfg;
adev->gfx.config.num_tile_pipes = adev->gfx.config.max_tile_pipes;
adev->gfx.config.mem_max_burst_length_bytes = 256;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 33/84] KVM: ARM64: fix phy counter access failure in guest.
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (29 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 32/84] drm/amdgpu/gfx6: properly cache mc_arb_ramcfg Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 34/84] KVM: PPC: Book3S: Fix typo in XICS-on-XIVE state saving code Greg Kroah-Hartman
` (45 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Hu Huajun, Christoffer Dall, Marc Zyngier
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hu Huajun <huhuajun@huawei.com>
commit 02d50cdaff36c135d222015cffdca3ff11d168ea upstream.
When reading the cntpct_el0 in guest with VHE (Virtual Host Extension)
enabled in host, the "Unsupported guest sys_reg access" error reported.
The reason is cnthctl_el2.EL1PCTEN is not enabled, which is expected
to be done in kvm_timer_init_vhe(). The problem is kvm_timer_init_vhe
is called by cpu_init_hyp_mode, and which is called when VHE is disabled.
This patch remove the incorrect call to kvm_timer_init_vhe() from
cpu_init_hyp_mode(), and calls kvm_timer_init_vhe() to enable
cnthctl_el2.EL1PCTEN in cpu_hyp_reinit().
Fixes: 488f94d7212b ("KVM: arm64: Access CNTHCTL_EL2 bit fields correctly on VHE systems")
Signed-off-by: Hu Huajun <huhuajun@huawei.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/arm/arm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1115,9 +1115,6 @@ static void cpu_init_hyp_mode(void *dumm
__cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
__cpu_init_stage2();
- if (is_kernel_in_hyp_mode())
- kvm_timer_init_vhe();
-
kvm_arm_init_debug();
}
@@ -1137,6 +1134,7 @@ static void cpu_hyp_reinit(void)
* event was cancelled before the CPU was reset.
*/
__cpu_init_stage2();
+ kvm_timer_init_vhe();
} else {
cpu_init_hyp_mode(NULL);
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 34/84] KVM: PPC: Book3S: Fix typo in XICS-on-XIVE state saving code
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (30 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 33/84] KVM: ARM64: fix phy counter access failure in guest Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 35/84] kvm-vfio: Decouple only when we match a group Greg Kroah-Hartman
` (44 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benjamin Herrenschmidt, Paul Mackerras
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul Mackerras <paulus@ozlabs.org>
commit 00c14757f6abacd78cad9b2690a0e1f42e4b76c8 upstream.
This fixes a typo where the wrong loop index was used to index
the kvmppc_xive_vcpu.queues[] array in xive_pre_save_scan().
The variable i contains the vcpu number; we need to index queues[]
using j, which iterates from 0 to KVMPPC_XIVE_Q_COUNT-1.
The effect of this bug is that things that save the interrupt
controller state, such as "virsh dump", on a VM with more than
8 vCPUs, result in xive_pre_save_queue() getting called on a
bogus queue structure, usually resulting in a crash like this:
[ 501.821107] Unable to handle kernel paging request for data at address 0x00000084
[ 501.821212] Faulting instruction address: 0xc008000004c7c6f8
[ 501.821234] Oops: Kernel access of bad area, sig: 11 [#1]
[ 501.821305] SMP NR_CPUS=1024
[ 501.821307] NUMA
[ 501.821376] PowerNV
[ 501.821470] Modules linked in: vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables ses enclosure scsi_transport_sas ipmi_powernv ipmi_devintf ipmi_msghandler powernv_op_panel kvm_hv nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc kvm tg3 ptp pps_core
[ 501.822477] CPU: 3 PID: 3934 Comm: live_migration Not tainted 4.11.0-4.git8caa70f.el7.centos.ppc64le #1
[ 501.822633] task: c0000003f9e3ae80 task.stack: c0000003f9ed4000
[ 501.822745] NIP: c008000004c7c6f8 LR: c008000004c7c628 CTR: 0000000030058018
[ 501.822877] REGS: c0000003f9ed7980 TRAP: 0300 Not tainted (4.11.0-4.git8caa70f.el7.centos.ppc64le)
[ 501.823030] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
[ 501.823047] CR: 28022244 XER: 00000000
[ 501.823203] CFAR: c008000004c7c77c DAR: 0000000000000084 DSISR: 40000000 SOFTE: 1
[ 501.823203] GPR00: c008000004c7c628 c0000003f9ed7c00 c008000004c91450 00000000000000ff
[ 501.823203] GPR04: c0000003f5580000 c0000003f559bf98 9000000000009033 0000000000000000
[ 501.823203] GPR08: 0000000000000084 0000000000000000 00000000000001e0 9000000000001003
[ 501.823203] GPR12: c00000000008a7d0 c00000000fdc1b00 000000000a9a0000 0000000000000000
[ 501.823203] GPR16: 00000000402954e8 000000000a9a0000 0000000000000004 0000000000000000
[ 501.823203] GPR20: 0000000000000008 c000000002e8f180 c000000002e8f1e0 0000000000000001
[ 501.823203] GPR24: 0000000000000008 c0000003f5580008 c0000003f4564018 c000000002e8f1e8
[ 501.823203] GPR28: 00003ff6e58bdc28 c0000003f4564000 0000000000000000 0000000000000000
[ 501.825441] NIP [c008000004c7c6f8] xive_get_attr+0x3b8/0x5b0 [kvm]
[ 501.825671] LR [c008000004c7c628] xive_get_attr+0x2e8/0x5b0 [kvm]
[ 501.825887] Call Trace:
[ 501.825991] [c0000003f9ed7c00] [c008000004c7c628] xive_get_attr+0x2e8/0x5b0 [kvm] (unreliable)
[ 501.826312] [c0000003f9ed7cd0] [c008000004c62ec4] kvm_device_ioctl_attr+0x64/0xa0 [kvm]
[ 501.826581] [c0000003f9ed7d20] [c008000004c62fcc] kvm_device_ioctl+0xcc/0xf0 [kvm]
[ 501.826843] [c0000003f9ed7d40] [c000000000350c70] do_vfs_ioctl+0xd0/0x8c0
[ 501.827060] [c0000003f9ed7de0] [c000000000351534] SyS_ioctl+0xd4/0xf0
[ 501.827282] [c0000003f9ed7e30] [c00000000000b8e0] system_call+0x38/0xfc
[ 501.827496] Instruction dump:
[ 501.827632] 419e0078 3b760008 e9160008 83fb000c 83db0010 80fb0008 2f280000 60000000
[ 501.827901] 60000000 60420000 419a0050 7be91764 <7d284c2c> 552a0ffe 7f8af040 419e003c
[ 501.828176] ---[ end trace 2d0529a5bbbbafed ]---
Fixes: 5af50993850a ("KVM: PPC: Book3S HV: Native usage of the XIVE interrupt controller")
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kvm/book3s_xive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/powerpc/kvm/book3s_xive.c
+++ b/arch/powerpc/kvm/book3s_xive.c
@@ -1257,8 +1257,8 @@ static void xive_pre_save_scan(struct kv
if (!xc)
continue;
for (j = 0; j < KVMPPC_XIVE_Q_COUNT; j++) {
- if (xc->queues[i].qpage)
- xive_pre_save_queue(xive, &xc->queues[i]);
+ if (xc->queues[j].qpage)
+ xive_pre_save_queue(xive, &xc->queues[j]);
}
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 35/84] kvm-vfio: Decouple only when we match a group
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (31 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 34/84] KVM: PPC: Book3S: Fix typo in XICS-on-XIVE state saving code Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 36/84] irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity Greg Kroah-Hartman
` (43 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Alex Williamson,
Alexey Kardashevskiy, Eric Auger, Paolo Bonzini
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Williamson <alex.williamson@redhat.com>
commit e323369b2e204da4dc771bbddceef986f4bf85d5 upstream.
Unset-KVM and decrement-assignment only when we find the group in our
list. Otherwise we can get out of sync if the user triggers this for
groups that aren't currently on our list.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Tested-by: Eric Auger <eric.auger@redhat.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
virt/kvm/vfio.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
--- a/virt/kvm/vfio.c
+++ b/virt/kvm/vfio.c
@@ -246,21 +246,20 @@ static int kvm_vfio_set_group(struct kvm
continue;
list_del(&kvg->node);
+ kvm_arch_end_assignment(dev->kvm);
+#ifdef CONFIG_SPAPR_TCE_IOMMU
+ kvm_spapr_tce_release_vfio_group(dev->kvm,
+ kvg->vfio_group);
+#endif
+ kvm_vfio_group_set_kvm(kvg->vfio_group, NULL);
kvm_vfio_group_put_external_user(kvg->vfio_group);
kfree(kvg);
ret = 0;
break;
}
- kvm_arch_end_assignment(dev->kvm);
-
mutex_unlock(&kv->lock);
-#ifdef CONFIG_SPAPR_TCE_IOMMU
- kvm_spapr_tce_release_vfio_group(dev->kvm, vfio_group);
-#endif
- kvm_vfio_group_set_kvm(vfio_group, NULL);
-
kvm_vfio_group_put_external_user(vfio_group);
kvm_vfio_update_coherency(dev);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 36/84] irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (32 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 35/84] kvm-vfio: Decouple only when we match a group Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 37/84] parisc: Report SIGSEGV instead of SIGBUS when running out of stack Greg Kroah-Hartman
` (42 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Suzuki K Poulose, Marc Zyngier
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suzuki K Poulose <suzuki.poulose@arm.com>
commit 866d7c1b0a3c70387646c4e455e727a58c5d465a upstream.
The GICv3 driver doesn't check if the target CPU for gic_set_affinity
is valid before going ahead and making the changes. This triggers the
following splat with KASAN:
[ 141.189434] BUG: KASAN: global-out-of-bounds in gic_set_affinity+0x8c/0x140
[ 141.189704] Read of size 8 at addr ffff200009741d20 by task swapper/1/0
[ 141.189958]
[ 141.190158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.12.0-rc7
[ 141.190458] Hardware name: Foundation-v8A (DT)
[ 141.190658] Call trace:
[ 141.190908] [<ffff200008089d70>] dump_backtrace+0x0/0x328
[ 141.191224] [<ffff20000808a1b4>] show_stack+0x14/0x20
[ 141.191507] [<ffff200008504c3c>] dump_stack+0xa4/0xc8
[ 141.191858] [<ffff20000826c19c>] print_address_description+0x13c/0x250
[ 141.192219] [<ffff20000826c5c8>] kasan_report+0x210/0x300
[ 141.192547] [<ffff20000826ad54>] __asan_load8+0x84/0x98
[ 141.192874] [<ffff20000854eeec>] gic_set_affinity+0x8c/0x140
[ 141.193158] [<ffff200008148b14>] irq_do_set_affinity+0x54/0xb8
[ 141.193473] [<ffff200008148d2c>] irq_set_affinity_locked+0x64/0xf0
[ 141.193828] [<ffff200008148e00>] __irq_set_affinity+0x48/0x78
[ 141.194158] [<ffff200008bc48a4>] arm_perf_starting_cpu+0x104/0x150
[ 141.194513] [<ffff2000080d73bc>] cpuhp_invoke_callback+0x17c/0x1f8
[ 141.194783] [<ffff2000080d94ec>] notify_cpu_starting+0x8c/0xb8
[ 141.195130] [<ffff2000080911ec>] secondary_start_kernel+0x15c/0x200
[ 141.195390] [<0000000080db81b4>] 0x80db81b4
[ 141.195603]
[ 141.195685] The buggy address belongs to the variable:
[ 141.196012] __cpu_logical_map+0x200/0x220
[ 141.196176]
[ 141.196315] Memory state around the buggy address:
[ 141.196586] ffff200009741c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 141.196913] ffff200009741c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 141.197158] >ffff200009741d00: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
[ 141.197487] ^
[ 141.197758] ffff200009741d80: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00
[ 141.198060] ffff200009741e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 141.198358] ==================================================================
[ 141.198609] Disabling lock debugging due to kernel taint
[ 141.198961] CPU1: Booted secondary processor [410fd051]
This patch adds the check to make sure the cpu is valid.
Fixes: commit 021f653791ad17e03f98 ("irqchip: gic-v3: Initial support for GICv3")
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/irqchip/irq-gic-v3.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -645,6 +645,9 @@ static int gic_set_affinity(struct irq_d
int enabled;
u64 val;
+ if (cpu >= nr_cpu_ids)
+ return -EINVAL;
+
if (gic_irq_in_rdist(d))
return -EINVAL;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 37/84] parisc: Report SIGSEGV instead of SIGBUS when running out of stack
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (33 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 36/84] irqchip/gic-v3: Fix out-of-bound access in gic_set_affinity Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 38/84] parisc: use compat_sys_keyctl() Greg Kroah-Hartman
` (41 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helge Deller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit 247462316f85a9e0479445c1a4223950b68ffac1 upstream.
When a process runs out of stack the parisc kernel wrongly faults with SIGBUS
instead of the expected SIGSEGV signal.
This example shows how the kernel faults:
do_page_fault() command='a.out' type=15 address=0xfaac2000 in libc-2.24.so[f8308000+16c000]
trap #15: Data TLB miss fault, vm_start = 0xfa2c2000, vm_end = 0xfaac2000
The vma->vm_end value is the first address which does not belong to the vma, so
adjust the check to include vma->vm_end to the range for which to send the
SIGSEGV signal.
This patch unbreaks building the debian libsigsegv package.
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/parisc/mm/fault.c
+++ b/arch/parisc/mm/fault.c
@@ -367,7 +367,7 @@ bad_area:
case 15: /* Data TLB miss fault/Data page fault */
/* send SIGSEGV when outside of vma */
if (!vma ||
- address < vma->vm_start || address > vma->vm_end) {
+ address < vma->vm_start || address >= vma->vm_end) {
si.si_signo = SIGSEGV;
si.si_code = SEGV_MAPERR;
break;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 38/84] parisc: use compat_sys_keyctl()
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (34 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 37/84] parisc: Report SIGSEGV instead of SIGBUS when running out of stack Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 39/84] parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs Greg Kroah-Hartman
` (40 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Eric Biggers, Helge Deller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit b0f94efd5aa8daa8a07d7601714c2573266cd4c9 upstream.
Architectures with a compat syscall table must put compat_sys_keyctl()
in it, not sys_keyctl(). The parisc architecture was not doing this;
fix it.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/kernel/syscall_table.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/parisc/kernel/syscall_table.S
+++ b/arch/parisc/kernel/syscall_table.S
@@ -361,7 +361,7 @@
ENTRY_SAME(ni_syscall) /* 263: reserved for vserver */
ENTRY_SAME(add_key)
ENTRY_SAME(request_key) /* 265 */
- ENTRY_SAME(keyctl)
+ ENTRY_COMP(keyctl)
ENTRY_SAME(ioprio_set)
ENTRY_SAME(ioprio_get)
ENTRY_SAME(inotify_init)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 39/84] parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (35 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 38/84] parisc: use compat_sys_keyctl() Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 40/84] parisc/mm: Ensure IRQs are off in switch_mm() Greg Kroah-Hartman
` (39 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Thomas Bogendoerfer, Helge Deller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
commit 33f9e02495d15a061f0c94ef46f5103a2d0c20f3 upstream.
Enabling parport pc driver on a B2600 (and probably other 64bit PARISC
systems) produced following BUG:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.12.0-rc5-30198-g1132d5e #156
task: 000000009e050000 task.stack: 000000009e04c000
YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00001000000001101111111100001111 Not tainted
r00-03 000000ff0806ff0f 000000009e04c990 0000000040871b78 000000009e04cac0
r04-07 0000000040c14de0 ffffffffffffffff 000000009e07f098 000000009d82d200
r08-11 000000009d82d210 0000000000000378 0000000000000000 0000000040c345e0
r12-15 0000000000000005 0000000040c345e0 0000000000000000 0000000040c9d5e0
r16-19 0000000040c345e0 00000000f00001c4 00000000f00001bc 0000000000000061
r20-23 000000009e04ce28 0000000000000010 0000000000000010 0000000040b89e40
r24-27 0000000000000003 0000000000ffffff 000000009d82d210 0000000040c14de0
r28-31 0000000000000000 000000009e04ca90 000000009e04cb40 0000000000000000
sr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000
IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000404aece0 00000000404aece4
IIR: 03ffe01f ISR: 0000000010340000 IOR: 000001781304cac8
CPU: 0 CR30: 000000009e04c000 CR31: 00000000e2976de2
ORIG_R28: 0000000000000200
IAOQ[0]: sba_dma_supported+0x80/0xd0
IAOQ[1]: sba_dma_supported+0x84/0xd0
RP(r2): parport_pc_probe_port+0x178/0x1200
Cause is a call to dma_coerce_mask_and_coherenet in parport_pc_probe_port,
which PARISC DMA API doesn't handle very nicely. This commit gives back
DMA_ERROR_CODE for DMA API calls, if device isn't capable of DMA
transaction.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/include/asm/dma-mapping.h | 11 +++++++----
drivers/parisc/ccio-dma.c | 12 ++++++++++++
drivers/parisc/dino.c | 5 ++++-
drivers/parisc/lba_pci.c | 6 ++++--
drivers/parisc/sba_iommu.c | 14 ++++++++++++++
5 files changed, 41 insertions(+), 7 deletions(-)
--- a/arch/parisc/include/asm/dma-mapping.h
+++ b/arch/parisc/include/asm/dma-mapping.h
@@ -20,6 +20,8 @@
** flush/purge and allocate "regular" cacheable pages for everything.
*/
+#define DMA_ERROR_CODE (~(dma_addr_t)0)
+
#ifdef CONFIG_PA11
extern const struct dma_map_ops pcxl_dma_ops;
extern const struct dma_map_ops pcx_dma_ops;
@@ -54,12 +56,13 @@ parisc_walk_tree(struct device *dev)
break;
}
}
- BUG_ON(!dev->platform_data);
return dev->platform_data;
}
-
-#define GET_IOC(dev) (HBA_DATA(parisc_walk_tree(dev))->iommu)
-
+
+#define GET_IOC(dev) ({ \
+ void *__pdata = parisc_walk_tree(dev); \
+ __pdata ? HBA_DATA(__pdata)->iommu : NULL; \
+})
#ifdef CONFIG_IOMMU_CCIO
struct parisc_device;
--- a/drivers/parisc/ccio-dma.c
+++ b/drivers/parisc/ccio-dma.c
@@ -741,6 +741,8 @@ ccio_map_single(struct device *dev, void
BUG_ON(!dev);
ioc = GET_IOC(dev);
+ if (!ioc)
+ return DMA_ERROR_CODE;
BUG_ON(size <= 0);
@@ -814,6 +816,10 @@ ccio_unmap_page(struct device *dev, dma_
BUG_ON(!dev);
ioc = GET_IOC(dev);
+ if (!ioc) {
+ WARN_ON(!ioc);
+ return;
+ }
DBG_RUN("%s() iovp 0x%lx/%x\n",
__func__, (long)iova, size);
@@ -918,6 +924,8 @@ ccio_map_sg(struct device *dev, struct s
BUG_ON(!dev);
ioc = GET_IOC(dev);
+ if (!ioc)
+ return 0;
DBG_RUN_SG("%s() START %d entries\n", __func__, nents);
@@ -990,6 +998,10 @@ ccio_unmap_sg(struct device *dev, struct
BUG_ON(!dev);
ioc = GET_IOC(dev);
+ if (!ioc) {
+ WARN_ON(!ioc);
+ return;
+ }
DBG_RUN_SG("%s() START %d entries, %p,%x\n",
__func__, nents, sg_virt(sglist), sglist->length);
--- a/drivers/parisc/dino.c
+++ b/drivers/parisc/dino.c
@@ -154,7 +154,10 @@ struct dino_device
};
/* Looks nice and keeps the compiler happy */
-#define DINO_DEV(d) ((struct dino_device *) d)
+#define DINO_DEV(d) ({ \
+ void *__pdata = d; \
+ BUG_ON(!__pdata); \
+ (struct dino_device *)__pdata; })
/*
--- a/drivers/parisc/lba_pci.c
+++ b/drivers/parisc/lba_pci.c
@@ -111,8 +111,10 @@ static u32 lba_t32;
/* Looks nice and keeps the compiler happy */
-#define LBA_DEV(d) ((struct lba_device *) (d))
-
+#define LBA_DEV(d) ({ \
+ void *__pdata = d; \
+ BUG_ON(!__pdata); \
+ (struct lba_device *)__pdata; })
/*
** Only allow 8 subsidiary busses per LBA
--- a/drivers/parisc/sba_iommu.c
+++ b/drivers/parisc/sba_iommu.c
@@ -691,6 +691,8 @@ static int sba_dma_supported( struct dev
return 0;
ioc = GET_IOC(dev);
+ if (!ioc)
+ return 0;
/*
* check if mask is >= than the current max IO Virt Address
@@ -722,6 +724,8 @@ sba_map_single(struct device *dev, void
int pide;
ioc = GET_IOC(dev);
+ if (!ioc)
+ return DMA_ERROR_CODE;
/* save offset bits */
offset = ((dma_addr_t) (long) addr) & ~IOVP_MASK;
@@ -813,6 +817,10 @@ sba_unmap_page(struct device *dev, dma_a
DBG_RUN("%s() iovp 0x%lx/%x\n", __func__, (long) iova, size);
ioc = GET_IOC(dev);
+ if (!ioc) {
+ WARN_ON(!ioc);
+ return;
+ }
offset = iova & ~IOVP_MASK;
iova ^= offset; /* clear offset bits */
size += offset;
@@ -952,6 +960,8 @@ sba_map_sg(struct device *dev, struct sc
DBG_RUN_SG("%s() START %d entries\n", __func__, nents);
ioc = GET_IOC(dev);
+ if (!ioc)
+ return 0;
/* Fast path single entry scatterlists. */
if (nents == 1) {
@@ -1037,6 +1047,10 @@ sba_unmap_sg(struct device *dev, struct
__func__, nents, sg_virt(sglist), sglist->length);
ioc = GET_IOC(dev);
+ if (!ioc) {
+ WARN_ON(!ioc);
+ return;
+ }
#ifdef SBA_COLLECT_STATS
ioc->usg_calls++;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 40/84] parisc/mm: Ensure IRQs are off in switch_mm()
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (36 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 39/84] parisc: DMA API: return error instead of BUG_ON for dma ops on non dma devs Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 41/84] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth Greg Kroah-Hartman
` (38 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Helge Deller
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <deller@gmx.de>
commit 649aa24254e85bf6bd7807dd372d083707852b1f upstream.
This is because of commit f98db6013c55 ("sched/core: Add switch_mm_irqs_off()
and use it in the scheduler") in which switch_mm_irqs_off() is called by the
scheduler, vs switch_mm() which is used by use_mm().
This patch lets the parisc code mirror the x86 and powerpc code, ie. it
disables interrupts in switch_mm(), and optimises the scheduler case by
defining switch_mm_irqs_off().
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/parisc/include/asm/mmu_context.h | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
--- a/arch/parisc/include/asm/mmu_context.h
+++ b/arch/parisc/include/asm/mmu_context.h
@@ -49,15 +49,26 @@ static inline void load_context(mm_conte
mtctl(__space_to_prot(context), 8);
}
-static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, struct task_struct *tsk)
+static inline void switch_mm_irqs_off(struct mm_struct *prev,
+ struct mm_struct *next, struct task_struct *tsk)
{
-
if (prev != next) {
mtctl(__pa(next->pgd), 25);
load_context(next->context);
}
}
+static inline void switch_mm(struct mm_struct *prev,
+ struct mm_struct *next, struct task_struct *tsk)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+ switch_mm_irqs_off(prev, next, tsk);
+ local_irq_restore(flags);
+}
+#define switch_mm_irqs_off switch_mm_irqs_off
+
#define deactivate_mm(tsk,mm) do { } while (0)
static inline void activate_mm(struct mm_struct *prev, struct mm_struct *next)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 41/84] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (37 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 40/84] parisc/mm: Ensure IRQs are off in switch_mm() Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 42/84] compiler, clang: always inline when CONFIG_OPTIMIZE_INLINING is disabled Greg Kroah-Hartman
` (37 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ben Hutchings, Sasha Levin,
Linus Torvalds, Peter Zijlstra, Thomas Gleixner, a.p.zijlstra,
Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <ben@decadent.org.uk>
commit 98dcea0cfd04e083ac74137ceb9a632604740e2d upstream.
liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix
lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is
within the range of lock_chain::depth and in liblockdep it is much
too large.
That should have resulted in a compiler error, but didn't because:
- the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep
so is assumed to be an (undeclared) function
- putting a function call inside a BUILD_BUG_ON() expression quietly
turns it into some nonsense involving a variable-length array
It did produce a compiler warning, but I didn't notice because
liblockdep already produces too many warnings if -Wall is enabled
(which I'll fix shortly).
Even before that commit, which reduced lock_chain::depth from 8 bits
to 6, MAX_LOCK_DEPTH was too large.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: a.p.zijlstra@chello.nl
Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/lib/lockdep/uinclude/linux/lockdep.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/tools/lib/lockdep/uinclude/linux/lockdep.h
+++ b/tools/lib/lockdep/uinclude/linux/lockdep.h
@@ -8,7 +8,7 @@
#include <linux/utsname.h>
#include <linux/compiler.h>
-#define MAX_LOCK_DEPTH 2000UL
+#define MAX_LOCK_DEPTH 63UL
#define asmlinkage
#define __visible
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 42/84] compiler, clang: always inline when CONFIG_OPTIMIZE_INLINING is disabled
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (38 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 41/84] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 43/84] thp, mm: fix crash due race in MADV_FREE handling Greg Kroah-Hartman
` (36 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David Rientjes, Sodagudi Prasad,
Matthias Kaehlcke, Mark Rutland, Will Deacon, Catalin Marinas,
Ingo Molnar, Peter Zijlstra, Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: David Rientjes <rientjes@google.com>
commit 9a04dbcfb33b4012d0ce8c0282f1e3ca694675b1 upstream.
The motivation for commit abb2ea7dfd82 ("compiler, clang: suppress
warning for unused static inline functions") was to suppress clang's
warnings about unused static inline functions.
For configs without CONFIG_OPTIMIZE_INLINING enabled, such as any non-x86
architecture, `inline' in the kernel implies that
__attribute__((always_inline)) is used.
Some code depends on that behavior, see
https://lkml.org/lkml/2017/6/13/918:
net/built-in.o: In function `__xchg_mb':
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to `__compiletime_assert_99'
arch/arm64/include/asm/cmpxchg.h:99: undefined reference to `__compiletime_assert_99
The full fix would be to identify these breakages and annotate the
functions with __always_inline instead of `inline'. But since we are
late in the 4.12-rc cycle, simply carry forward the forced inlining
behavior and work toward moving arm64, and other architectures, toward
CONFIG_OPTIMIZE_INLINING behavior.
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1706261552200.1075@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Reported-by: Sodagudi Prasad <psodagud@codeaurora.org>
Tested-by: Sodagudi Prasad <psodagud@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/compiler-clang.h | 8 --------
include/linux/compiler-gcc.h | 18 +++++++++++-------
2 files changed, 11 insertions(+), 15 deletions(-)
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -15,11 +15,3 @@
* with any version that can compile the kernel
*/
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-
-/*
- * GCC does not warn about unused static inline functions for
- * -Wunused-function. This turns out to avoid the need for complex #ifdef
- * directives. Suppress the warning in clang as well.
- */
-#undef inline
-#define inline inline __attribute__((unused)) notrace
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -66,18 +66,22 @@
/*
* Force always-inline if the user requests it so via the .config,
- * or if gcc is too old:
+ * or if gcc is too old.
+ * GCC does not warn about unused static inline functions for
+ * -Wunused-function. This turns out to avoid the need for complex #ifdef
+ * directives. Suppress the warning in clang as well by using "unused"
+ * function attribute, which is redundant but not harmful for gcc.
*/
#if !defined(CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING) || \
!defined(CONFIG_OPTIMIZE_INLINING) || (__GNUC__ < 4)
-#define inline inline __attribute__((always_inline)) notrace
-#define __inline__ __inline__ __attribute__((always_inline)) notrace
-#define __inline __inline __attribute__((always_inline)) notrace
+#define inline inline __attribute__((always_inline,unused)) notrace
+#define __inline__ __inline__ __attribute__((always_inline,unused)) notrace
+#define __inline __inline __attribute__((always_inline,unused)) notrace
#else
/* A lot of inline functions can cause havoc with function tracing */
-#define inline inline notrace
-#define __inline__ __inline__ notrace
-#define __inline __inline notrace
+#define inline inline __attribute__((unused)) notrace
+#define __inline__ __inline__ __attribute__((unused)) notrace
+#define __inline __inline __attribute__((unused)) notrace
#endif
#define __always_inline inline __attribute__((always_inline))
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 43/84] thp, mm: fix crash due race in MADV_FREE handling
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (39 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 42/84] compiler, clang: always inline when CONFIG_OPTIMIZE_INLINING is disabled Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 44/84] kernel/extable.c: mark core_kernel_text notrace Greg Kroah-Hartman
` (35 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kirill A. Shutemov, Reinette Chatre,
Dave Hansen, Michal Hocko, Minchan Kim, Huang Ying,
Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
commit bbf29ffc7f963bb894f84f0580c70cfea01c3892 upstream.
Reinette reported the following crash:
BUG: Bad page state in process log2exe pfn:57600
page:ffffea00015d8000 count:0 mapcount:0 mapping: (null) index:0x20200
flags: 0x4000000000040019(locked|uptodate|dirty|swapbacked)
raw: 4000000000040019 0000000000000000 0000000000020200 00000000ffffffff
raw: ffffea00015d8020 ffffea00015d8020 0000000000000000 0000000000000000
page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set
bad because of flags: 0x1(locked)
Modules linked in: rfcomm 8021q bnep intel_rapl x86_pkg_temp_thermal coretemp efivars btusb btrtl btbcm pwm_lpss_pci snd_hda_codec_hdmi btintel pwm_lpss snd_hda_codec_realtek snd_soc_skl snd_hda_codec_generic snd_soc_skl_ipc spi_pxa2xx_platform snd_soc_sst_ipc snd_soc_sst_dsp i2c_designware_platform i2c_designware_core snd_hda_ext_core snd_soc_sst_match snd_hda_intel snd_hda_codec mei_me snd_hda_core mei snd_soc_rt286 snd_soc_rl6347a snd_soc_core efivarfs
CPU: 1 PID: 354 Comm: log2exe Not tainted 4.12.0-rc7-test-test #19
Hardware name: Intel corporation NUC6CAYS/NUC6CAYB, BIOS AYAPLCEL.86A.0027.2016.1108.1529 11/08/2016
Call Trace:
bad_page+0x16a/0x1f0
free_pages_check_bad+0x117/0x190
free_hot_cold_page+0x7b1/0xad0
__put_page+0x70/0xa0
madvise_free_huge_pmd+0x627/0x7b0
madvise_free_pte_range+0x6f8/0x1150
__walk_page_range+0x6b5/0xe30
walk_page_range+0x13b/0x310
madvise_free_page_range.isra.16+0xad/0xd0
madvise_free_single_vma+0x2e4/0x470
SyS_madvise+0x8ce/0x1450
If somebody frees the page under us and we hold the last reference to
it, put_page() would attempt to free the page before unlocking it.
The fix is trivial reorder of operations.
Dave said:
"I came up with the exact same patch. For posterity, here's the test
case, generated by syzkaller and trimmed down by Reinette:
https://www.sr71.net/~dave/intel/log2.c
And the config that helps detect this:
https://www.sr71.net/~dave/intel/config-log2"
Fixes: b8d3c4c3009d ("mm/huge_memory.c: don't split THP page when MADV_FREE syscall is called")
Link: http://lkml.kernel.org/r/20170628101249.17879-1-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Reinette Chatre <reinette.chatre@intel.com>
Acked-by: Dave Hansen <dave.hansen@intel.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
mm/huge_memory.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1575,8 +1575,8 @@ bool madvise_free_huge_pmd(struct mmu_ga
get_page(page);
spin_unlock(ptl);
split_huge_page(page);
- put_page(page);
unlock_page(page);
+ put_page(page);
goto out_unlocked;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 44/84] kernel/extable.c: mark core_kernel_text notrace
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (40 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 43/84] thp, mm: fix crash due race in MADV_FREE handling Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 45/84] mm/list_lru.c: fix list_lru_count_node() to be race free Greg Kroah-Hartman
` (34 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Marcin Nowakowski, Masami Hiramatsu,
Peter Zijlstra, Thomas Meyer, Ingo Molnar, Steven Rostedt,
Daniel Borkmann, Paul Gortmaker, Thomas Gleixner, Andrew Morton,
Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
commit c0d80ddab89916273cb97114889d3f337bc370ae upstream.
core_kernel_text is used by MIPS in its function graph trace processing,
so having this method traced leads to an infinite set of recursive calls
such as:
Call Trace:
ftrace_return_to_handler+0x50/0x128
core_kernel_text+0x10/0x1b8
prepare_ftrace_return+0x6c/0x114
ftrace_graph_caller+0x20/0x44
return_to_handler+0x10/0x30
return_to_handler+0x0/0x30
return_to_handler+0x0/0x30
ftrace_ops_no_ops+0x114/0x1bc
core_kernel_text+0x10/0x1b8
core_kernel_text+0x10/0x1b8
core_kernel_text+0x10/0x1b8
ftrace_ops_no_ops+0x114/0x1bc
core_kernel_text+0x10/0x1b8
prepare_ftrace_return+0x6c/0x114
ftrace_graph_caller+0x20/0x44
(...)
Mark the function notrace to avoid it being traced.
Link: http://lkml.kernel.org/r/1498028607-6765-1-git-send-email-marcin.nowakowski@imgtec.com
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Meyer <thomas@m3y3r.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/extable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -69,7 +69,7 @@ static inline int init_kernel_text(unsig
return 0;
}
-int core_kernel_text(unsigned long addr)
+int notrace core_kernel_text(unsigned long addr)
{
if (addr >= (unsigned long)_stext &&
addr < (unsigned long)_etext)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 45/84] mm/list_lru.c: fix list_lru_count_node() to be race free
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (41 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 44/84] kernel/extable.c: mark core_kernel_text notrace Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 46/84] fs/dcache.c: fix spin lockup issue on nlru->lock Greg Kroah-Hartman
` (33 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sahitya Tummala, Vladimir Davydov,
Jan Kara, Alexander Polakov, Al Viro, Andrew Morton,
Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sahitya Tummala <stummala@codeaurora.org>
commit 2c80cd57c74339889a8752b20862a16c28929c3a upstream.
list_lru_count_node() iterates over all memcgs to get the total number of
entries on the node but it can race with memcg_drain_all_list_lrus(),
which migrates the entries from a dead cgroup to another. This can return
incorrect number of entries from list_lru_count_node().
Fix this by keeping track of entries per node and simply return it in
list_lru_count_node().
Link: http://lkml.kernel.org/r/1498707555-30525-1-git-send-email-stummala@codeaurora.org
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Jan Kara <jack@suse.cz>
Cc: Alexander Polakov <apolyakov@beget.ru>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/linux/list_lru.h | 1 +
mm/list_lru.c | 14 ++++++--------
2 files changed, 7 insertions(+), 8 deletions(-)
--- a/include/linux/list_lru.h
+++ b/include/linux/list_lru.h
@@ -44,6 +44,7 @@ struct list_lru_node {
/* for cgroup aware lrus points to per cgroup lists, otherwise NULL */
struct list_lru_memcg *memcg_lrus;
#endif
+ long nr_items;
} ____cacheline_aligned_in_smp;
struct list_lru {
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -117,6 +117,7 @@ bool list_lru_add(struct list_lru *lru,
l = list_lru_from_kmem(nlru, item);
list_add_tail(item, &l->list);
l->nr_items++;
+ nlru->nr_items++;
spin_unlock(&nlru->lock);
return true;
}
@@ -136,6 +137,7 @@ bool list_lru_del(struct list_lru *lru,
l = list_lru_from_kmem(nlru, item);
list_del_init(item);
l->nr_items--;
+ nlru->nr_items--;
spin_unlock(&nlru->lock);
return true;
}
@@ -183,15 +185,10 @@ EXPORT_SYMBOL_GPL(list_lru_count_one);
unsigned long list_lru_count_node(struct list_lru *lru, int nid)
{
- long count = 0;
- int memcg_idx;
+ struct list_lru_node *nlru;
- count += __list_lru_count_one(lru, nid, -1);
- if (list_lru_memcg_aware(lru)) {
- for_each_memcg_cache_index(memcg_idx)
- count += __list_lru_count_one(lru, nid, memcg_idx);
- }
- return count;
+ nlru = &lru->node[nid];
+ return nlru->nr_items;
}
EXPORT_SYMBOL_GPL(list_lru_count_node);
@@ -226,6 +223,7 @@ restart:
assert_spin_locked(&nlru->lock);
case LRU_REMOVED:
isolated++;
+ nlru->nr_items--;
/*
* If the lru lock has been dropped, our list
* traversal is now invalid and so we have to
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 46/84] fs/dcache.c: fix spin lockup issue on nlru->lock
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (42 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 45/84] mm/list_lru.c: fix list_lru_count_node() to be race free Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 47/84] checkpatch: silence perl 5.26.0 unescaped left brace warnings Greg Kroah-Hartman
` (32 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Sahitya Tummala, Jan Kara,
Vladimir Davydov, Alexander Polakov, Al Viro, Andrew Morton,
Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sahitya Tummala <stummala@codeaurora.org>
commit b17c070fb624cf10162cf92ea5e1ec25cd8ac176 upstream.
__list_lru_walk_one() acquires nlru spin lock (nlru->lock) for longer
duration if there are more number of items in the lru list. As per the
current code, it can hold the spin lock for upto maximum UINT_MAX
entries at a time. So if there are more number of items in the lru
list, then "BUG: spinlock lockup suspected" is observed in the below
path:
spin_bug+0x90
do_raw_spin_lock+0xfc
_raw_spin_lock+0x28
list_lru_add+0x28
dput+0x1c8
path_put+0x20
terminate_walk+0x3c
path_lookupat+0x100
filename_lookup+0x6c
user_path_at_empty+0x54
SyS_faccessat+0xd0
el0_svc_naked+0x24
This nlru->lock is acquired by another CPU in this path -
d_lru_shrink_move+0x34
dentry_lru_isolate_shrink+0x48
__list_lru_walk_one.isra.10+0x94
list_lru_walk_node+0x40
shrink_dcache_sb+0x60
do_remount_sb+0xbc
do_emergency_remount+0xb0
process_one_work+0x228
worker_thread+0x2e0
kthread+0xf4
ret_from_fork+0x10
Fix this lockup by reducing the number of entries to be shrinked from
the lru list to 1024 at once. Also, add cond_resched() before
processing the lru list again.
Link: http://marc.info/?t=149722864900001&r=1&w=2
Link: http://lkml.kernel.org/r/1498707575-2472-1-git-send-email-stummala@codeaurora.org
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Suggested-by: Jan Kara <jack@suse.cz>
Suggested-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Acked-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Alexander Polakov <apolyakov@beget.ru>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/dcache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1133,11 +1133,12 @@ void shrink_dcache_sb(struct super_block
LIST_HEAD(dispose);
freed = list_lru_walk(&sb->s_dentry_lru,
- dentry_lru_isolate_shrink, &dispose, UINT_MAX);
+ dentry_lru_isolate_shrink, &dispose, 1024);
this_cpu_sub(nr_dentry_unused, freed);
shrink_dentry_list(&dispose);
- } while (freed > 0);
+ cond_resched();
+ } while (list_lru_count(&sb->s_dentry_lru) > 0);
}
EXPORT_SYMBOL(shrink_dcache_sb);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 47/84] checkpatch: silence perl 5.26.0 unescaped left brace warnings
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (43 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 46/84] fs/dcache.c: fix spin lockup issue on nlru->lock Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 48/84] binfmt_elf: use ELF_ET_DYN_BASE only for PIE Greg Kroah-Hartman
` (31 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Cyril Bur, Joe Perches,
Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Cyril Bur <cyrilbur@gmail.com>
commit 8d81ae05d0176da1c54aeaed697fa34be5c5575e upstream.
As of perl 5, version 26, subversion 0 (v5.26.0) some new warnings have
occurred when running checkpatch.
Unescaped left brace in regex is deprecated here (and will be fatal in
Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.\s*){
<-- HERE \s*/ at scripts/checkpatch.pl line 3544.
Unescaped left brace in regex is deprecated here (and will be fatal in
Perl 5.30), passed through in regex; marked by <-- HERE in m/^(.\s*){
<-- HERE \s*/ at scripts/checkpatch.pl line 3885.
Unescaped left brace in regex is deprecated here (and will be fatal in
Perl 5.30), passed through in regex; marked by <-- HERE in
m/^(\+.*(?:do|\))){ <-- HERE / at scripts/checkpatch.pl line 4374.
It seems perfectly reasonable to do as the warning suggests and simply
escape the left brace in these three locations.
Link: http://lkml.kernel.org/r/20170607060135.17384-1-cyrilbur@gmail.com
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
Acked-by: Joe Perches <joe@perches.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
scripts/checkpatch.pl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3541,7 +3541,7 @@ sub process {
$fixedline =~ s/\s*=\s*$/ = {/;
fix_insert_line($fixlinenr, $fixedline);
$fixedline = $line;
- $fixedline =~ s/^(.\s*){\s*/$1/;
+ $fixedline =~ s/^(.\s*)\{\s*/$1/;
fix_insert_line($fixlinenr, $fixedline);
}
}
@@ -3882,7 +3882,7 @@ sub process {
my $fixedline = rtrim($prevrawline) . " {";
fix_insert_line($fixlinenr, $fixedline);
$fixedline = $rawline;
- $fixedline =~ s/^(.\s*){\s*/$1\t/;
+ $fixedline =~ s/^(.\s*)\{\s*/$1\t/;
if ($fixedline !~ /^\+\s*$/) {
fix_insert_line($fixlinenr, $fixedline);
}
@@ -4371,7 +4371,7 @@ sub process {
if (ERROR("SPACING",
"space required before the open brace '{'\n" . $herecurr) &&
$fix) {
- $fixed[$fixlinenr] =~ s/^(\+.*(?:do|\))){/$1 {/;
+ $fixed[$fixlinenr] =~ s/^(\+.*(?:do|\)))\{/$1 {/;
}
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 48/84] binfmt_elf: use ELF_ET_DYN_BASE only for PIE
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (44 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 47/84] checkpatch: silence perl 5.26.0 unescaped left brace warnings Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 49/84] arm: move ELF_ET_DYN_BASE to 4MB Greg Kroah-Hartman
` (30 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Rik van Riel,
Daniel Micay, Qualys Security Advisory, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Alexander Viro, Dmitry Safonov,
Andy Lutomirski, Grzegorz Andrejczuk, Masahiro Yamada,
Benjamin Herrenschmidt, Catalin Marinas, Heiko Carstens,
James Hogan, Martin Schwidefsky, Michael Ellerman,
Paul Mackerras, Pratyush Anand, Russell King, Will Deacon,
Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit eab09532d40090698b05a07c1c87f39fdbc5fab5 upstream.
The ELF_ET_DYN_BASE position was originally intended to keep loaders
away from ET_EXEC binaries. (For example, running "/lib/ld-linux.so.2
/bin/cat" might cause the subsequent load of /bin/cat into where the
loader had been loaded.)
With the advent of PIE (ET_DYN binaries with an INTERP Program Header),
ELF_ET_DYN_BASE continued to be used since the kernel was only looking
at ET_DYN. However, since ELF_ET_DYN_BASE is traditionally set at the
top 1/3rd of the TASK_SIZE, a substantial portion of the address space
is unused.
For 32-bit tasks when RLIMIT_STACK is set to RLIM_INFINITY, programs are
loaded above the mmap region. This means they can be made to collide
(CVE-2017-1000370) or nearly collide (CVE-2017-1000371) with
pathological stack regions.
Lowering ELF_ET_DYN_BASE solves both by moving programs below the mmap
region in all cases, and will now additionally avoid programs falling
back to the mmap region by enforcing MAP_FIXED for program loads (i.e.
if it would have collided with the stack, now it will fail to load
instead of falling back to the mmap region).
To allow for a lower ELF_ET_DYN_BASE, loaders (ET_DYN without INTERP)
are loaded into the mmap region, leaving space available for either an
ET_EXEC binary with a fixed location or PIE being loaded into mmap by
the loader. Only PIE programs are loaded offset from ELF_ET_DYN_BASE,
which means architectures can now safely lower their values without risk
of loaders colliding with their subsequently loaded programs.
For 64-bit, ELF_ET_DYN_BASE is best set to 4GB to allow runtimes to use
the entire 32-bit address space for 32-bit pointers.
Thanks to PaX Team, Daniel Micay, and Rik van Riel for inspiration and
suggestions on how to implement this solution.
Fixes: d1fd836dcf00 ("mm: split ET_DYN ASLR from mmap ASLR")
Link: http://lkml.kernel.org/r/20170621173201.GA114489@beast
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/elf.h | 13 +++++----
fs/binfmt_elf.c | 59 ++++++++++++++++++++++++++++++++++++++-------
2 files changed, 58 insertions(+), 14 deletions(-)
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -245,12 +245,13 @@ extern int force_personality32;
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE 4096
-/* This is the location that an ET_DYN program is loaded if exec'ed. Typical
- use of this is to invoke "./ld.so someprog" to test out a new version of
- the loader. We need to make sure that it is out of the way of the program
- that it will "exec", and that there is sufficient room for the brk. */
-
-#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)
+/*
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
+ */
+#define ELF_ET_DYN_BASE (mmap_is_ia32() ? 0x000400000UL : \
+ 0x100000000UL)
/* This yields a mask that user programs can use to figure out what
instruction set this CPU supports. This could be done in user space,
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -927,17 +927,60 @@ static int load_elf_binary(struct linux_
elf_flags = MAP_PRIVATE | MAP_DENYWRITE | MAP_EXECUTABLE;
vaddr = elf_ppnt->p_vaddr;
+ /*
+ * If we are loading ET_EXEC or we have already performed
+ * the ET_DYN load_addr calculations, proceed normally.
+ */
if (loc->elf_ex.e_type == ET_EXEC || load_addr_set) {
elf_flags |= MAP_FIXED;
} else if (loc->elf_ex.e_type == ET_DYN) {
- /* Try and get dynamic programs out of the way of the
- * default mmap base, as well as whatever program they
- * might try to exec. This is because the brk will
- * follow the loader, and is not movable. */
- load_bias = ELF_ET_DYN_BASE - vaddr;
- if (current->flags & PF_RANDOMIZE)
- load_bias += arch_mmap_rnd();
- load_bias = ELF_PAGESTART(load_bias);
+ /*
+ * This logic is run once for the first LOAD Program
+ * Header for ET_DYN binaries to calculate the
+ * randomization (load_bias) for all the LOAD
+ * Program Headers, and to calculate the entire
+ * size of the ELF mapping (total_size). (Note that
+ * load_addr_set is set to true later once the
+ * initial mapping is performed.)
+ *
+ * There are effectively two types of ET_DYN
+ * binaries: programs (i.e. PIE: ET_DYN with INTERP)
+ * and loaders (ET_DYN without INTERP, since they
+ * _are_ the ELF interpreter). The loaders must
+ * be loaded away from programs since the program
+ * may otherwise collide with the loader (especially
+ * for ET_EXEC which does not have a randomized
+ * position). For example to handle invocations of
+ * "./ld.so someprog" to test out a new version of
+ * the loader, the subsequent program that the
+ * loader loads must avoid the loader itself, so
+ * they cannot share the same load range. Sufficient
+ * room for the brk must be allocated with the
+ * loader as well, since brk must be available with
+ * the loader.
+ *
+ * Therefore, programs are loaded offset from
+ * ELF_ET_DYN_BASE and loaders are loaded into the
+ * independently randomized mmap region (0 load_bias
+ * without MAP_FIXED).
+ */
+ if (elf_interpreter) {
+ load_bias = ELF_ET_DYN_BASE;
+ if (current->flags & PF_RANDOMIZE)
+ load_bias += arch_mmap_rnd();
+ elf_flags |= MAP_FIXED;
+ } else
+ load_bias = 0;
+
+ /*
+ * Since load_bias is used for all subsequent loading
+ * calculations, we must lower it by the first vaddr
+ * so that the remaining calculations based on the
+ * ELF vaddrs will be correctly offset. The result
+ * is then page aligned.
+ */
+ load_bias = ELF_PAGESTART(load_bias - vaddr);
+
total_size = total_mapping_size(elf_phdata,
loc->elf_ex.e_phnum);
if (!total_size) {
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 49/84] arm: move ELF_ET_DYN_BASE to 4MB
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (45 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 48/84] binfmt_elf: use ELF_ET_DYN_BASE only for PIE Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 50/84] arm64: move ELF_ET_DYN_BASE to 4GB / 4MB Greg Kroah-Hartman
` (29 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Russell King,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
H. Peter Anvin, Alexander Viro, Andy Lutomirski, Daniel Micay,
Dmitry Safonov, Grzegorz Andrejczuk, Masahiro Yamada,
Qualys Security Advisory, Rik van Riel, Thomas Gleixner,
Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit 6a9af90a3bcde217a1c053e135f5f43e5d5fafbd upstream.
Now that explicitly executed loaders are loaded in the mmap region, we
have more freedom to decide where we position PIE binaries in the
address space to avoid possible collisions with mmap or stack regions.
4MB is chosen here mainly to have parity with x86, where this is the
traditional minimum load location, likely to avoid historically
requiring a 4MB page table entry when only a portion of the first 4MB
would be used (since the NULL address is avoided).
For ARM the position could be 0x8000, the standard ET_EXEC load address,
but that is needlessly close to the NULL address, and anyone running PIE
on 32-bit ARM will have an MMU, so the tight mapping is not needed.
Link: http://lkml.kernel.org/r/1498154792-49952-2-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Daniel Micay <danielmicay@gmail.com>
Cc: Dmitry Safonov <dsafonov@virtuozzo.com>
Cc: Grzegorz Andrejczuk <grzegorz.andrejczuk@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Qualys Security Advisory <qsa@qualys.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/elf.h | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/arch/arm/include/asm/elf.h
+++ b/arch/arm/include/asm/elf.h
@@ -112,12 +112,8 @@ int dump_task_regs(struct task_struct *t
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE 4096
-/* This is the location that an ET_DYN program is loaded if exec'ed. Typical
- use of this is to invoke "./ld.so someprog" to test out a new version of
- the loader. We need to make sure that it is out of the way of the program
- that it will "exec", and that there is sufficient room for the brk. */
-
-#define ELF_ET_DYN_BASE (TASK_SIZE / 3 * 2)
+/* This is the base location for PIE (ET_DYN with INTERP) loads. */
+#define ELF_ET_DYN_BASE 0x400000UL
/* When the program starts, a1 contains a pointer to a function to be
registered with atexit, as per the SVR4 ABI. A value of 0 means we
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 50/84] arm64: move ELF_ET_DYN_BASE to 4GB / 4MB
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (46 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 49/84] arm: move ELF_ET_DYN_BASE to 4MB Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 51/84] powerpc: " Greg Kroah-Hartman
` (28 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Ard Biesheuvel,
Catalin Marinas, Mark Rutland, Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit 02445990a96e60a67526510d8b00f7e3d14101c3 upstream.
Now that explicitly executed loaders are loaded in the mmap region, we
have more freedom to decide where we position PIE binaries in the
address space to avoid possible collisions with mmap or stack regions.
For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
address space for 32-bit pointers. On 32-bit use 4MB, to match ARM.
This could be 0x8000, the standard ET_EXEC load address, but that is
needlessly close to the NULL address, and anyone running arm compat PIE
will have an MMU, so the tight mapping is not needed.
Link: http://lkml.kernel.org/r/1498251600-132458-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/elf.h | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -113,12 +113,11 @@
#define ELF_EXEC_PAGESIZE PAGE_SIZE
/*
- * This is the location that an ET_DYN program is loaded if exec'ed. Typical
- * use of this is to invoke "./ld.so someprog" to test out a new version of
- * the loader. We need to make sure that it is out of the way of the program
- * that it will "exec", and that there is sufficient room for the brk.
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
*/
-#define ELF_ET_DYN_BASE (2 * TASK_SIZE_64 / 3)
+#define ELF_ET_DYN_BASE 0x100000000UL
#ifndef __ASSEMBLY__
@@ -173,7 +172,8 @@ extern int arch_setup_additional_pages(s
#ifdef CONFIG_COMPAT
-#define COMPAT_ELF_ET_DYN_BASE (2 * TASK_SIZE_32 / 3)
+/* PIE load location for compat arm. Must match ARM ELF_ET_DYN_BASE. */
+#define COMPAT_ELF_ET_DYN_BASE 0x000400000UL
/* AArch32 registers. */
#define COMPAT_ELF_NGREG 18
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 51/84] powerpc: move ELF_ET_DYN_BASE to 4GB / 4MB
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (47 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 50/84] arm64: move ELF_ET_DYN_BASE to 4GB / 4MB Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 52/84] s390: reduce ELF_ET_DYN_BASE Greg Kroah-Hartman
` (27 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Michael Ellerman,
Russell King, Catalin Marinas, Will Deacon,
Benjamin Herrenschmidt, Paul Mackerras, Martin Schwidefsky,
Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit 47ebb09d54856500c5a5e14824781902b3bb738e upstream.
Now that explicitly executed loaders are loaded in the mmap region, we
have more freedom to decide where we position PIE binaries in the
address space to avoid possible collisions with mmap or stack regions.
For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
address space for 32-bit pointers. On 32-bit use 4MB, which is the
traditional x86 minimum load location, likely to avoid historically
requiring a 4MB page table entry when only a portion of the first 4MB
would be used (since the NULL address is avoided).
Link: http://lkml.kernel.org/r/1498154792-49952-4-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Tested-by: Michael Ellerman <mpe@ellerman.id.au>
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/include/asm/elf.h | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- a/arch/powerpc/include/asm/elf.h
+++ b/arch/powerpc/include/asm/elf.h
@@ -23,12 +23,13 @@
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE PAGE_SIZE
-/* This is the location that an ET_DYN program is loaded if exec'ed. Typical
- use of this is to invoke "./ld.so someprog" to test out a new version of
- the loader. We need to make sure that it is out of the way of the program
- that it will "exec", and that there is sufficient room for the brk. */
-
-#define ELF_ET_DYN_BASE 0x20000000
+/*
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
+ */
+#define ELF_ET_DYN_BASE (is_32bit_task() ? 0x000400000UL : \
+ 0x100000000UL)
#define ELF_CORE_EFLAGS (is_elf2_task() ? 2 : 0)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 52/84] s390: reduce ELF_ET_DYN_BASE
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (48 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 51/84] powerpc: " Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:43 ` [PATCH 4.12 53/84] exec: Limit arg stack to at most 75% of _STK_LIM Greg Kroah-Hartman
` (26 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Kees Cook, Russell King,
Catalin Marinas, Will Deacon, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Martin Schwidefsky,
Heiko Carstens, James Hogan, Pratyush Anand, Ingo Molnar,
Andrew Morton, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit a73dc5370e153ac63718d850bddf0c9aa9d871e6 upstream.
Now that explicitly executed loaders are loaded in the mmap region, we
have more freedom to decide where we position PIE binaries in the
address space to avoid possible collisions with mmap or stack regions.
For 64-bit, align to 4GB to allow runtimes to use the entire 32-bit
address space for 32-bit pointers. On 32-bit use 4MB, which is the
traditional x86 minimum load location, likely to avoid historically
requiring a 4MB page table entry when only a portion of the first 4MB
would be used (since the NULL address is avoided). For s390 the
position could be 0x10000, but that is needlessly close to the NULL
address.
Link: http://lkml.kernel.org/r/1498154792-49952-5-git-send-email-keescook@chromium.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Pratyush Anand <panand@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/s390/include/asm/elf.h | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
--- a/arch/s390/include/asm/elf.h
+++ b/arch/s390/include/asm/elf.h
@@ -161,14 +161,13 @@ extern unsigned int vdso_enabled;
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE 4096
-/* This is the location that an ET_DYN program is loaded if exec'ed. Typical
- use of this is to invoke "./ld.so someprog" to test out a new version of
- the loader. We need to make sure that it is out of the way of the program
- that it will "exec", and that there is sufficient room for the brk. 64-bit
- tasks are aligned to 4GB. */
-#define ELF_ET_DYN_BASE (is_compat_task() ? \
- (STACK_TOP / 3 * 2) : \
- (STACK_TOP / 3 * 2) & ~((1UL << 32) - 1))
+/*
+ * This is the base location for PIE (ET_DYN with INTERP) loads. On
+ * 64-bit, this is raised to 4GB to leave the entire 32-bit address
+ * space open for things that want to use the area for 32-bit pointers.
+ */
+#define ELF_ET_DYN_BASE (is_compat_task() ? 0x000400000UL : \
+ 0x100000000UL)
/* This yields a mask that user programs can use to figure out what
instruction set this CPU supports. */
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 53/84] exec: Limit arg stack to at most 75% of _STK_LIM
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (49 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 52/84] s390: reduce ELF_ET_DYN_BASE Greg Kroah-Hartman
@ 2017-07-19 9:43 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 54/84] powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR Greg Kroah-Hartman
` (25 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:43 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Kees Cook, Linus Torvalds
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kees Cook <keescook@chromium.org>
commit da029c11e6b12f321f36dac8771e833b65cec962 upstream.
To avoid pathological stack usage or the need to special-case setuid
execs, just limit all arg stack usage to at most 75% of _STK_LIM (6MB).
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/exec.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -220,8 +220,7 @@ static struct page *get_arg_page(struct
if (write) {
unsigned long size = bprm->vma->vm_end - bprm->vma->vm_start;
- unsigned long ptr_size;
- struct rlimit *rlim;
+ unsigned long ptr_size, limit;
/*
* Since the stack will hold pointers to the strings, we
@@ -250,14 +249,16 @@ static struct page *get_arg_page(struct
return page;
/*
- * Limit to 1/4-th the stack size for the argv+env strings.
+ * Limit to 1/4 of the max stack size or 3/4 of _STK_LIM
+ * (whichever is smaller) for the argv+env strings.
* This ensures that:
* - the remaining binfmt code will not run out of stack space,
* - the program will have a reasonable amount of stack left
* to work from.
*/
- rlim = current->signal->rlim;
- if (size > READ_ONCE(rlim[RLIMIT_STACK].rlim_cur) / 4)
+ limit = _STK_LIM / 4 * 3;
+ limit = min(limit, rlimit(RLIMIT_STACK) / 4);
+ if (size > limit)
goto fail;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 54/84] powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (50 preceding siblings ...)
2017-07-19 9:43 ` [PATCH 4.12 53/84] exec: Limit arg stack to at most 75% of _STK_LIM Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 55/84] ARM64: dts: marvell: armada37xx: Fix timer interrupt specifiers Greg Kroah-Hartman
` (24 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Benjamin Herrenschmidt, Balbir Singh,
Michael Ellerman
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Balbir Singh <bsingharora@gmail.com>
commit 1e2a516e89fc412a754327522ab271b42f99c6b4 upstream.
This patch fixes a crash seen while doing a kexec from radix mode to
hash mode. Key 0 is special in hash and used in the RPN by default, we
set the key values to 0 today. In radix mode key 0 is used to control
supervisor<->user access. In hash key 0 is used by default, so the
first instruction after the switch causes a crash on kexec.
Commit 3b10d0095a1e ("powerpc/mm/radix: Prevent kernel execution of
user space") introduced the setting of IAMR and AMOR values to prevent
execution of user mode instructions from supervisor mode. We need to
clean up these SPR's on kexec.
Fixes: 3b10d0095a1e ("powerpc/mm/radix: Prevent kernel execution of user space")
Reported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/powerpc/kernel/misc_64.S | 12 ++++++++++++
1 file changed, 12 insertions(+)
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -614,6 +614,18 @@ _GLOBAL(kexec_sequence)
li r0,0
std r0,16(r1)
+BEGIN_FTR_SECTION
+ /*
+ * This is the best time to turn AMR/IAMR off.
+ * key 0 is used in radix for supervisor<->user
+ * protection, but on hash key 0 is reserved
+ * ideally we want to enter with a clean state.
+ * NOTE, we rely on r0 being 0 from above.
+ */
+ mtspr SPRN_IAMR,r0
+ mtspr SPRN_AMOR,r0
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300)
+
/* save regs for local vars on new stack.
* yes, we won't go back, but ...
*/
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 55/84] ARM64: dts: marvell: armada37xx: Fix timer interrupt specifiers
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (51 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 54/84] powerpc/kexec: Fix radix to hash kexec due to IAMR/AMOR Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 56/84] arm64: Preventing READ_IMPLIES_EXEC propagation Greg Kroah-Hartman
` (23 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Marc Zyngier, Gregory CLEMENT
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marc Zyngier <marc.zyngier@arm.com>
commit 88cda00733f0731711c76e535d4972c296ac512e upstream.
Contrary to popular belief, PPIs connected to a GICv3 to not have
an affinity field similar to that of GICv2. That is consistent
with the fact that GICv3 is designed to accomodate thousands of
CPUs, and fitting them as a bitmap in a byte is... difficult.
Fixes: adbc3695d9e4 ("arm64: dts: add the Marvell Armada 3700 family and a development board")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -75,14 +75,10 @@
timer {
compatible = "arm,armv8-timer";
- interrupts = <GIC_PPI 13
- (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
- <GIC_PPI 14
- (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
- <GIC_PPI 11
- (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>,
- <GIC_PPI 10
- (GIC_CPU_MASK_SIMPLE(2) | IRQ_TYPE_LEVEL_HIGH)>;
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_HIGH>;
};
soc {
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 56/84] arm64: Preventing READ_IMPLIES_EXEC propagation
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (52 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 55/84] ARM64: dts: marvell: armada37xx: Fix timer interrupt specifiers Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 57/84] vt: fix unchecked __put_user() in tioclinux ioctls Greg Kroah-Hartman
` (22 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Maydell, Dong Bo, Will Deacon
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dong Bo <dongbo4@huawei.com>
commit 48f99c8ec0b25756d0283ab058826ae07d14fad7 upstream.
Like arch/arm/, we inherit the READ_IMPLIES_EXEC personality flag across
fork(). This is undesirable for a number of reasons:
* ELF files that don't require executable stack can end up with it
anyway
* We end up performing un-necessary I-cache maintenance when mapping
what should be non-executable pages
* Restricting what is executable is generally desirable when defending
against overflow attacks
This patch clears the personality flag when setting up the personality for
newly spwaned native tasks. Given that semi-recent AArch64 toolchains emit
a non-executable PT_GNU_STACK header, userspace applications can already
not rely on READ_IMPLIES_EXEC so shouldn't be adversely affected by this
change.
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Dong Bo <dongbo4@huawei.com>
[will: added comment to compat code, rewrote commit message]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm64/include/asm/elf.h | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -141,6 +141,7 @@ typedef struct user_fpsimd_state elf_fpr
({ \
clear_bit(TIF_32BIT, ¤t->mm->context.flags); \
clear_thread_flag(TIF_32BIT); \
+ current->personality &= ~READ_IMPLIES_EXEC; \
})
/* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
@@ -187,6 +188,11 @@ typedef compat_elf_greg_t compat_elf_gr
((x)->e_flags & EF_ARM_EABI_MASK))
#define compat_start_thread compat_start_thread
+/*
+ * Unlike the native SET_PERSONALITY macro, the compat version inherits
+ * READ_IMPLIES_EXEC across a fork() since this is the behaviour on
+ * arch/arm/.
+ */
#define COMPAT_SET_PERSONALITY(ex) \
({ \
set_bit(TIF_32BIT, ¤t->mm->context.flags); \
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 57/84] vt: fix unchecked __put_user() in tioclinux ioctls
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (53 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 56/84] arm64: Preventing READ_IMPLIES_EXEC propagation Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 58/84] rcu: Add memory barriers for NOCB leader wakeup Greg Kroah-Hartman
` (21 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Adam Borowski
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adam Borowski <kilobyte@angband.pl>
commit 6987dc8a70976561d22450b5858fc9767788cc1c upstream.
Only read access is checked before this call.
Actually, at the moment this is not an issue, as every in-tree arch does
the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU
to tell them apart, but this wasn't the case in the past and may happen
again on some odd arch in the future.
If anyone cares about 3.7 and earlier, this is a security hole (untested)
on real 80386 CPUs.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/vt/vt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -2709,13 +2709,13 @@ int tioclinux(struct tty_struct *tty, un
* related to the kernel should not use this.
*/
data = vt_get_shift_state();
- ret = __put_user(data, p);
+ ret = put_user(data, p);
break;
case TIOCL_GETMOUSEREPORTING:
console_lock(); /* May be overkill */
data = mouse_reporting();
console_unlock();
- ret = __put_user(data, p);
+ ret = put_user(data, p);
break;
case TIOCL_SETVESABLANK:
console_lock();
@@ -2724,7 +2724,7 @@ int tioclinux(struct tty_struct *tty, un
break;
case TIOCL_GETKMSGREDIRECT:
data = vt_get_kmsg_redirect();
- ret = __put_user(data, p);
+ ret = put_user(data, p);
break;
case TIOCL_SETKMSGREDIRECT:
if (!capable(CAP_SYS_ADMIN)) {
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 58/84] rcu: Add memory barriers for NOCB leader wakeup
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (54 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 57/84] vt: fix unchecked __put_user() in tioclinux ioctls Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 59/84] nvmem: core: fix leaks on registration errors Greg Kroah-Hartman
` (20 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Paul E. McKenney, Krister Johansen
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
commit 6b5fc3a1331810db407c9e0e673dc1837afdc9d0 upstream.
Wait/wakeup operations do not guarantee ordering on their own. Instead,
either locking or memory barriers are required. This commit therefore
adds memory barriers to wake_nocb_leader() and nocb_leader_wait().
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Krister Johansen <kjlx@templeofstupid.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tree_plugin.h | 2 ++
1 file changed, 2 insertions(+)
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1769,6 +1769,7 @@ static void wake_nocb_leader(struct rcu_
if (READ_ONCE(rdp_leader->nocb_leader_sleep) || force) {
/* Prior smp_mb__after_atomic() orders against prior enqueue. */
WRITE_ONCE(rdp_leader->nocb_leader_sleep, false);
+ smp_mb(); /* ->nocb_leader_sleep before swake_up(). */
swake_up(&rdp_leader->nocb_wq);
}
}
@@ -2023,6 +2024,7 @@ wait_again:
* nocb_gp_head, where they await a grace period.
*/
gotcbs = false;
+ smp_mb(); /* wakeup before ->nocb_head reads. */
for (rdp = my_rdp; rdp; rdp = rdp->nocb_next_follower) {
rdp->nocb_gp_head = READ_ONCE(rdp->nocb_head);
if (!rdp->nocb_gp_head)
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 59/84] nvmem: core: fix leaks on registration errors
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (55 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 58/84] rcu: Add memory barriers for NOCB leader wakeup Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 60/84] Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page Greg Kroah-Hartman
` (19 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrew Lunn, Srinivas Kandagatla,
Mika Westerberg, Johan Hovold, Andrey Smirnov
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Johan Hovold <johan@kernel.org>
commit 3360acdf839170b612f5b212539694c20e3f16d0 upstream.
Make sure to deregister and release the nvmem device and underlying
memory on registration errors.
Note that the private data must be freed using put_device() once the
struct device has been initialised.
Also note that there's a related reference leak in the deregistration
function as reported by Mika Westerberg which is being fixed separately.
Fixes: b6c217ab9be6 ("nvmem: Add backwards compatibility support for older EEPROM drivers.")
Fixes: eace75cfdcf7 ("nvmem: Add a simple NVMEM framework for nvmem providers")
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/nvmem/core.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -489,21 +489,24 @@ struct nvmem_device *nvmem_register(cons
rval = device_add(&nvmem->dev);
if (rval)
- goto out;
+ goto err_put_device;
if (config->compat) {
rval = nvmem_setup_compat(nvmem, config);
if (rval)
- goto out;
+ goto err_device_del;
}
if (config->cells)
nvmem_add_cells(nvmem, config);
return nvmem;
-out:
- ida_simple_remove(&nvmem_ida, nvmem->id);
- kfree(nvmem);
+
+err_device_del:
+ device_del(&nvmem->dev);
+err_put_device:
+ put_device(&nvmem->dev);
+
return ERR_PTR(rval);
}
EXPORT_SYMBOL_GPL(nvmem_register);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 60/84] Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (56 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 59/84] nvmem: core: fix leaks on registration errors Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 61/84] mnt: In umount propagation reparent in a separate pass Greg Kroah-Hartman
` (18 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Michael Kelley, K. Y. Srinivasan
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michael Kelley <mikelley@microsoft.com>
commit 13b9abfc92be7c4454bff912021b9f835dea6e15 upstream.
Extend the disabling of preemption to include the hypercall so that
another thread can't get the CPU and corrupt the per-cpu page used
for hypercall arguments.
Signed-off-by: Michael Kelley <mikelley@microsoft.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/hv/hv.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- a/drivers/hv/hv.c
+++ b/drivers/hv/hv.c
@@ -82,10 +82,15 @@ int hv_post_message(union hv_connection_
aligned_msg->message_type = message_type;
aligned_msg->payload_size = payload_size;
memcpy((void *)aligned_msg->payload, payload, payload_size);
- put_cpu_ptr(hv_cpu);
status = hv_do_hypercall(HVCALL_POST_MESSAGE, aligned_msg, NULL);
+ /* Preemption must remain disabled until after the hypercall
+ * so some other thread can't get scheduled onto this cpu and
+ * corrupt the per-cpu post_msg_page
+ */
+ put_cpu_ptr(hv_cpu);
+
return status & 0xFFFF;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 61/84] mnt: In umount propagation reparent in a separate pass
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (57 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 60/84] Drivers: hv: vmbus: Close timing hole that can corrupt per-cpu page Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 62/84] mnt: In propgate_umount handle visiting mounts in any order Greg Kroah-Hartman
` (17 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrei Vagin, Ram Pai, Eric W. Biederman
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman <ebiederm@xmission.com>
commit 570487d3faf2a1d8a220e6ee10f472163123d7da upstream.
It was observed that in some pathlogical cases that the current code
does not unmount everything it should. After investigation it
was determined that the issue is that mnt_change_mntpoint can
can change which mounts are available to be unmounted during mount
propagation which is wrong.
The trivial reproducer is:
$ cat ./pathological.sh
mount -t tmpfs test-base /mnt
cd /mnt
mkdir 1 2 1/1
mount --bind 1 1
mount --make-shared 1
mount --bind 1 2
mount --bind 1/1 1/1
mount --bind 1/1 1/1
echo
grep test-base /proc/self/mountinfo
umount 1/1
echo
grep test-base /proc/self/mountinfo
$ unshare -Urm ./pathological.sh
The expected output looks like:
46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
49 54 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
50 53 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
51 49 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
54 47 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
53 48 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
52 50 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
The output without the fix looks like:
46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
49 54 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
50 53 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
51 49 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
54 47 0:25 /1/1 /mnt/1/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
53 48 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
52 50 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
46 31 0:25 / /mnt rw,relatime - tmpfs test-base rw,uid=1000,gid=1000
47 46 0:25 /1 /mnt/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
48 46 0:25 /1 /mnt/2 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
52 48 0:25 /1/1 /mnt/2/1 rw,relatime shared:1 - tmpfs test-base rw,uid=1000,gid=1000
That last mount in the output was in the propgation tree to be unmounted but
was missed because the mnt_change_mountpoint changed it's parent before the walk
through the mount propagation tree observed it.
Fixes: 1064f874abc0 ("mnt: Tuck mounts under others instead of creating shadow/side mounts.")
Acked-by: Andrei Vagin <avagin@virtuozzo.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/mount.h | 1 +
fs/namespace.c | 1 +
fs/pnode.c | 35 ++++++++++++++++++++++++++++++-----
3 files changed, 32 insertions(+), 5 deletions(-)
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -58,6 +58,7 @@ struct mount {
struct mnt_namespace *mnt_ns; /* containing namespace */
struct mountpoint *mnt_mp; /* where is it mounted */
struct hlist_node mnt_mp_list; /* list mounts with the same mountpoint */
+ struct list_head mnt_reparent; /* reparent list entry */
#ifdef CONFIG_FSNOTIFY
struct fsnotify_mark_connector __rcu *mnt_fsnotify_marks;
__u32 mnt_fsnotify_mask;
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -236,6 +236,7 @@ static struct mount *alloc_vfsmnt(const
INIT_LIST_HEAD(&mnt->mnt_slave_list);
INIT_LIST_HEAD(&mnt->mnt_slave);
INIT_HLIST_NODE(&mnt->mnt_mp_list);
+ INIT_LIST_HEAD(&mnt->mnt_reparent);
init_fs_pin(&mnt->mnt_umount, drop_mountpoint);
}
return mnt;
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -439,7 +439,7 @@ static void mark_umount_candidates(struc
* NOTE: unmounting 'mnt' naturally propagates to all other mounts its
* parent propagates to.
*/
-static void __propagate_umount(struct mount *mnt)
+static void __propagate_umount(struct mount *mnt, struct list_head *to_reparent)
{
struct mount *parent = mnt->mnt_parent;
struct mount *m;
@@ -464,17 +464,38 @@ static void __propagate_umount(struct mo
*/
topper = find_topper(child);
if (topper)
- mnt_change_mountpoint(child->mnt_parent, child->mnt_mp,
- topper);
+ list_add_tail(&topper->mnt_reparent, to_reparent);
- if (list_empty(&child->mnt_mounts)) {
+ if (topper || list_empty(&child->mnt_mounts)) {
list_del_init(&child->mnt_child);
+ list_del_init(&child->mnt_reparent);
child->mnt.mnt_flags |= MNT_UMOUNT;
list_move_tail(&child->mnt_list, &mnt->mnt_list);
}
}
}
+static void reparent_mounts(struct list_head *to_reparent)
+{
+ while (!list_empty(to_reparent)) {
+ struct mount *mnt, *parent;
+ struct mountpoint *mp;
+
+ mnt = list_first_entry(to_reparent, struct mount, mnt_reparent);
+ list_del_init(&mnt->mnt_reparent);
+
+ /* Where should this mount be reparented to? */
+ mp = mnt->mnt_mp;
+ parent = mnt->mnt_parent;
+ while (parent->mnt.mnt_flags & MNT_UMOUNT) {
+ mp = parent->mnt_mp;
+ parent = parent->mnt_parent;
+ }
+
+ mnt_change_mountpoint(parent, mp, mnt);
+ }
+}
+
/*
* collect all mounts that receive propagation from the mount in @list,
* and return these additional mounts in the same list.
@@ -485,11 +506,15 @@ static void __propagate_umount(struct mo
int propagate_umount(struct list_head *list)
{
struct mount *mnt;
+ LIST_HEAD(to_reparent);
list_for_each_entry_reverse(mnt, list, mnt_list)
mark_umount_candidates(mnt);
list_for_each_entry(mnt, list, mnt_list)
- __propagate_umount(mnt);
+ __propagate_umount(mnt, &to_reparent);
+
+ reparent_mounts(&to_reparent);
+
return 0;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 62/84] mnt: In propgate_umount handle visiting mounts in any order
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (58 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 61/84] mnt: In umount propagation reparent in a separate pass Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 63/84] mnt: Make propagate_umount less slow for overlapping mount propagation trees Greg Kroah-Hartman
` (16 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrei Vagin, Eric W. Biederman
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman <ebiederm@xmission.com>
commit 99b19d16471e9c3faa85cad38abc9cbbe04c6d55 upstream.
While investigating some poor umount performance I realized that in
the case of overlapping mount trees where some of the mounts are locked
the code has been failing to unmount all of the mounts it should
have been unmounting.
This failure to unmount all of the necessary
mounts can be reproduced with:
$ cat locked_mounts_test.sh
mount -t tmpfs test-base /mnt
mount --make-shared /mnt
mkdir -p /mnt/b
mount -t tmpfs test1 /mnt/b
mount --make-shared /mnt/b
mkdir -p /mnt/b/10
mount -t tmpfs test2 /mnt/b/10
mount --make-shared /mnt/b/10
mkdir -p /mnt/b/10/20
mount --rbind /mnt/b /mnt/b/10/20
unshare -Urm --propagation unchaged /bin/sh -c 'sleep 5; if [ $(grep test /proc/self/mountinfo | wc -l) -eq 1 ] ; then echo SUCCESS ; else echo FAILURE ; fi'
sleep 1
umount -l /mnt/b
wait %%
$ unshare -Urm ./locked_mounts_test.sh
This failure is corrected by removing the prepass that marks mounts
that may be umounted.
A first pass is added that umounts mounts if possible and if not sets
mount mark if they could be unmounted if they weren't locked and adds
them to a list to umount possibilities. This first pass reconsiders
the mounts parent if it is on the list of umount possibilities, ensuring
that information of umoutability will pass from child to mount parent.
A second pass then walks through all mounts that are umounted and processes
their children unmounting them or marking them for reparenting.
A last pass cleans up the state on the mounts that could not be umounted
and if applicable reparents them to their first parent that remained
mounted.
While a bit longer than the old code this code is much more robust
as it allows information to flow up from the leaves and down
from the trunk making the order in which mounts are encountered
in the umount propgation tree irrelevant.
Fixes: 0c56fe31420c ("mnt: Don't propagate unmounts to locked mounts")
Reviewed-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/mount.h | 2
fs/namespace.c | 2
fs/pnode.c | 150 +++++++++++++++++++++++++++++++++------------------------
3 files changed, 91 insertions(+), 63 deletions(-)
--- a/fs/mount.h
+++ b/fs/mount.h
@@ -58,7 +58,7 @@ struct mount {
struct mnt_namespace *mnt_ns; /* containing namespace */
struct mountpoint *mnt_mp; /* where is it mounted */
struct hlist_node mnt_mp_list; /* list mounts with the same mountpoint */
- struct list_head mnt_reparent; /* reparent list entry */
+ struct list_head mnt_umounting; /* list entry for umount propagation */
#ifdef CONFIG_FSNOTIFY
struct fsnotify_mark_connector __rcu *mnt_fsnotify_marks;
__u32 mnt_fsnotify_mask;
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -236,7 +236,7 @@ static struct mount *alloc_vfsmnt(const
INIT_LIST_HEAD(&mnt->mnt_slave_list);
INIT_LIST_HEAD(&mnt->mnt_slave);
INIT_HLIST_NODE(&mnt->mnt_mp_list);
- INIT_LIST_HEAD(&mnt->mnt_reparent);
+ INIT_LIST_HEAD(&mnt->mnt_umounting);
init_fs_pin(&mnt->mnt_umount, drop_mountpoint);
}
return mnt;
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -413,86 +413,95 @@ void propagate_mount_unlock(struct mount
}
}
-/*
- * Mark all mounts that the MNT_LOCKED logic will allow to be unmounted.
- */
-static void mark_umount_candidates(struct mount *mnt)
+static void umount_one(struct mount *mnt, struct list_head *to_umount)
{
- struct mount *parent = mnt->mnt_parent;
- struct mount *m;
-
- BUG_ON(parent == mnt);
-
- for (m = propagation_next(parent, parent); m;
- m = propagation_next(m, parent)) {
- struct mount *child = __lookup_mnt(&m->mnt,
- mnt->mnt_mountpoint);
- if (!child || (child->mnt.mnt_flags & MNT_UMOUNT))
- continue;
- if (!IS_MNT_LOCKED(child) || IS_MNT_MARKED(m)) {
- SET_MNT_MARK(child);
- }
- }
+ CLEAR_MNT_MARK(mnt);
+ mnt->mnt.mnt_flags |= MNT_UMOUNT;
+ list_del_init(&mnt->mnt_child);
+ list_del_init(&mnt->mnt_umounting);
+ list_move_tail(&mnt->mnt_list, to_umount);
}
/*
* NOTE: unmounting 'mnt' naturally propagates to all other mounts its
* parent propagates to.
*/
-static void __propagate_umount(struct mount *mnt, struct list_head *to_reparent)
+static bool __propagate_umount(struct mount *mnt,
+ struct list_head *to_umount,
+ struct list_head *to_restore)
{
- struct mount *parent = mnt->mnt_parent;
- struct mount *m;
+ bool progress = false;
+ struct mount *child;
- BUG_ON(parent == mnt);
-
- for (m = propagation_next(parent, parent); m;
- m = propagation_next(m, parent)) {
- struct mount *topper;
- struct mount *child = __lookup_mnt(&m->mnt,
- mnt->mnt_mountpoint);
- /*
- * umount the child only if the child has no children
- * and the child is marked safe to unmount.
- */
- if (!child || !IS_MNT_MARKED(child))
+ /*
+ * The state of the parent won't change if this mount is
+ * already unmounted or marked as without children.
+ */
+ if (mnt->mnt.mnt_flags & (MNT_UMOUNT | MNT_MARKED))
+ goto out;
+
+ /* Verify topper is the only grandchild that has not been
+ * speculatively unmounted.
+ */
+ list_for_each_entry(child, &mnt->mnt_mounts, mnt_child) {
+ if (child->mnt_mountpoint == mnt->mnt.mnt_root)
+ continue;
+ if (!list_empty(&child->mnt_umounting) && IS_MNT_MARKED(child))
continue;
- CLEAR_MNT_MARK(child);
+ /* Found a mounted child */
+ goto children;
+ }
- /* If there is exactly one mount covering all of child
- * replace child with that mount.
- */
- topper = find_topper(child);
- if (topper)
- list_add_tail(&topper->mnt_reparent, to_reparent);
-
- if (topper || list_empty(&child->mnt_mounts)) {
- list_del_init(&child->mnt_child);
- list_del_init(&child->mnt_reparent);
- child->mnt.mnt_flags |= MNT_UMOUNT;
- list_move_tail(&child->mnt_list, &mnt->mnt_list);
+ /* Mark mounts that can be unmounted if not locked */
+ SET_MNT_MARK(mnt);
+ progress = true;
+
+ /* If a mount is without children and not locked umount it. */
+ if (!IS_MNT_LOCKED(mnt)) {
+ umount_one(mnt, to_umount);
+ } else {
+children:
+ list_move_tail(&mnt->mnt_umounting, to_restore);
+ }
+out:
+ return progress;
+}
+
+static void umount_list(struct list_head *to_umount,
+ struct list_head *to_restore)
+{
+ struct mount *mnt, *child, *tmp;
+ list_for_each_entry(mnt, to_umount, mnt_list) {
+ list_for_each_entry_safe(child, tmp, &mnt->mnt_mounts, mnt_child) {
+ /* topper? */
+ if (child->mnt_mountpoint == mnt->mnt.mnt_root)
+ list_move_tail(&child->mnt_umounting, to_restore);
+ else
+ umount_one(child, to_umount);
}
}
}
-static void reparent_mounts(struct list_head *to_reparent)
+static void restore_mounts(struct list_head *to_restore)
{
- while (!list_empty(to_reparent)) {
+ /* Restore mounts to a clean working state */
+ while (!list_empty(to_restore)) {
struct mount *mnt, *parent;
struct mountpoint *mp;
- mnt = list_first_entry(to_reparent, struct mount, mnt_reparent);
- list_del_init(&mnt->mnt_reparent);
+ mnt = list_first_entry(to_restore, struct mount, mnt_umounting);
+ CLEAR_MNT_MARK(mnt);
+ list_del_init(&mnt->mnt_umounting);
- /* Where should this mount be reparented to? */
+ /* Should this mount be reparented? */
mp = mnt->mnt_mp;
parent = mnt->mnt_parent;
while (parent->mnt.mnt_flags & MNT_UMOUNT) {
mp = parent->mnt_mp;
parent = parent->mnt_parent;
}
-
- mnt_change_mountpoint(parent, mp, mnt);
+ if (parent != mnt->mnt_parent)
+ mnt_change_mountpoint(parent, mp, mnt);
}
}
@@ -506,15 +515,34 @@ static void reparent_mounts(struct list_
int propagate_umount(struct list_head *list)
{
struct mount *mnt;
- LIST_HEAD(to_reparent);
-
- list_for_each_entry_reverse(mnt, list, mnt_list)
- mark_umount_candidates(mnt);
+ LIST_HEAD(to_restore);
+ LIST_HEAD(to_umount);
- list_for_each_entry(mnt, list, mnt_list)
- __propagate_umount(mnt, &to_reparent);
+ list_for_each_entry(mnt, list, mnt_list) {
+ struct mount *parent = mnt->mnt_parent;
+ struct mount *m;
+
+ for (m = propagation_next(parent, parent); m;
+ m = propagation_next(m, parent)) {
+ struct mount *child = __lookup_mnt(&m->mnt,
+ mnt->mnt_mountpoint);
+ if (!child)
+ continue;
+
+ /* Check the child and parents while progress is made */
+ while (__propagate_umount(child,
+ &to_umount, &to_restore)) {
+ /* Is the parent a umount candidate? */
+ child = child->mnt_parent;
+ if (list_empty(&child->mnt_umounting))
+ break;
+ }
+ }
+ }
- reparent_mounts(&to_reparent);
+ umount_list(&to_umount, &to_restore);
+ restore_mounts(&to_restore);
+ list_splice_tail(&to_umount, list);
return 0;
}
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 63/84] mnt: Make propagate_umount less slow for overlapping mount propagation trees
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (59 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 62/84] mnt: In propgate_umount handle visiting mounts in any order Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 64/84] selftests/capabilities: Fix the test_execve test Greg Kroah-Hartman
` (15 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Andrei Vagin, Andrei Vagin,
Eric W. Biederman
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric W. Biederman <ebiederm@xmission.com>
commit 296990deb389c7da21c78030376ba244dc1badf5 upstream.
Andrei Vagin pointed out that time to executue propagate_umount can go
non-linear (and take a ludicrious amount of time) when the mount
propogation trees of the mounts to be unmunted by a lazy unmount
overlap.
Make the walk of the mount propagation trees nearly linear by
remembering which mounts have already been visited, allowing
subsequent walks to detect when walking a mount propgation tree or a
subtree of a mount propgation tree would be duplicate work and to skip
them entirely.
Walk the list of mounts whose propgatation trees need to be traversed
from the mount highest in the mount tree to mounts lower in the mount
tree so that odds are higher that the code will walk the largest trees
first, allowing later tree walks to be skipped entirely.
Add cleanup_umount_visitation to remover the code's memory of which
mounts have been visited.
Add the functions last_slave and skip_propagation_subtree to allow
skipping appropriate parts of the mount propagation tree without
needing to change the logic of the rest of the code.
A script to generate overlapping mount propagation trees:
$ cat runs.h
set -e
mount -t tmpfs zdtm /mnt
mkdir -p /mnt/1 /mnt/2
mount -t tmpfs zdtm /mnt/1
mount --make-shared /mnt/1
mkdir /mnt/1/1
iteration=10
if [ -n "$1" ] ; then
iteration=$1
fi
for i in $(seq $iteration); do
mount --bind /mnt/1/1 /mnt/1/1
done
mount --rbind /mnt/1 /mnt/2
TIMEFORMAT='%Rs'
nr=$(( ( 2 ** ( $iteration + 1 ) ) + 1 ))
echo -n "umount -l /mnt/1 -> $nr "
time umount -l /mnt/1
nr=$(cat /proc/self/mountinfo | grep zdtm | wc -l )
time umount -l /mnt/2
$ for i in $(seq 9 19); do echo $i; unshare -Urm bash ./run.sh $i; done
Here are the performance numbers with and without the patch:
mhash | 8192 | 8192 | 1048576 | 1048576
mounts | before | after | before | after
------------------------------------------------
1025 | 0.040s | 0.016s | 0.038s | 0.019s
2049 | 0.094s | 0.017s | 0.080s | 0.018s
4097 | 0.243s | 0.019s | 0.206s | 0.023s
8193 | 1.202s | 0.028s | 1.562s | 0.032s
16385 | 9.635s | 0.036s | 9.952s | 0.041s
32769 | 60.928s | 0.063s | 44.321s | 0.064s
65537 | | 0.097s | | 0.097s
131073 | | 0.233s | | 0.176s
262145 | | 0.653s | | 0.344s
524289 | | 2.305s | | 0.735s
1048577 | | 7.107s | | 2.603s
Andrei Vagin reports fixing the performance problem is part of the
work to fix CVE-2016-6213.
Fixes: a05964f3917c ("[PATCH] shared mounts handling: umount")
Reported-by: Andrei Vagin <avagin@openvz.org>
Reviewed-by: Andrei Vagin <avagin@virtuozzo.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/pnode.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 1 deletion(-)
--- a/fs/pnode.c
+++ b/fs/pnode.c
@@ -24,6 +24,11 @@ static inline struct mount *first_slave(
return list_entry(p->mnt_slave_list.next, struct mount, mnt_slave);
}
+static inline struct mount *last_slave(struct mount *p)
+{
+ return list_entry(p->mnt_slave_list.prev, struct mount, mnt_slave);
+}
+
static inline struct mount *next_slave(struct mount *p)
{
return list_entry(p->mnt_slave.next, struct mount, mnt_slave);
@@ -162,6 +167,19 @@ static struct mount *propagation_next(st
}
}
+static struct mount *skip_propagation_subtree(struct mount *m,
+ struct mount *origin)
+{
+ /*
+ * Advance m such that propagation_next will not return
+ * the slaves of m.
+ */
+ if (!IS_MNT_NEW(m) && !list_empty(&m->mnt_slave_list))
+ m = last_slave(m);
+
+ return m;
+}
+
static struct mount *next_group(struct mount *m, struct mount *origin)
{
while (1) {
@@ -505,6 +523,15 @@ static void restore_mounts(struct list_h
}
}
+static void cleanup_umount_visitations(struct list_head *visited)
+{
+ while (!list_empty(visited)) {
+ struct mount *mnt =
+ list_first_entry(visited, struct mount, mnt_umounting);
+ list_del_init(&mnt->mnt_umounting);
+ }
+}
+
/*
* collect all mounts that receive propagation from the mount in @list,
* and return these additional mounts in the same list.
@@ -517,11 +544,23 @@ int propagate_umount(struct list_head *l
struct mount *mnt;
LIST_HEAD(to_restore);
LIST_HEAD(to_umount);
+ LIST_HEAD(visited);
- list_for_each_entry(mnt, list, mnt_list) {
+ /* Find candidates for unmounting */
+ list_for_each_entry_reverse(mnt, list, mnt_list) {
struct mount *parent = mnt->mnt_parent;
struct mount *m;
+ /*
+ * If this mount has already been visited it is known that it's
+ * entire peer group and all of their slaves in the propagation
+ * tree for the mountpoint has already been visited and there is
+ * no need to visit them again.
+ */
+ if (!list_empty(&mnt->mnt_umounting))
+ continue;
+
+ list_add_tail(&mnt->mnt_umounting, &visited);
for (m = propagation_next(parent, parent); m;
m = propagation_next(m, parent)) {
struct mount *child = __lookup_mnt(&m->mnt,
@@ -529,6 +568,27 @@ int propagate_umount(struct list_head *l
if (!child)
continue;
+ if (!list_empty(&child->mnt_umounting)) {
+ /*
+ * If the child has already been visited it is
+ * know that it's entire peer group and all of
+ * their slaves in the propgation tree for the
+ * mountpoint has already been visited and there
+ * is no need to visit this subtree again.
+ */
+ m = skip_propagation_subtree(m, parent);
+ continue;
+ } else if (child->mnt.mnt_flags & MNT_UMOUNT) {
+ /*
+ * We have come accross an partially unmounted
+ * mount in list that has not been visited yet.
+ * Remember it has been visited and continue
+ * about our merry way.
+ */
+ list_add_tail(&child->mnt_umounting, &visited);
+ continue;
+ }
+
/* Check the child and parents while progress is made */
while (__propagate_umount(child,
&to_umount, &to_restore)) {
@@ -542,6 +602,7 @@ int propagate_umount(struct list_head *l
umount_list(&to_umount, &to_restore);
restore_mounts(&to_restore);
+ cleanup_umount_visitations(&visited);
list_splice_tail(&to_umount, list);
return 0;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 64/84] selftests/capabilities: Fix the test_execve test
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (60 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 63/84] mnt: Make propagate_umount less slow for overlapping mount propagation trees Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 67/84] crypto: atmel - only treat EBUSY as transient if backlog Greg Kroah-Hartman
` (14 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Naresh Kamboju, Eric W. Biederman,
Kees Cook, Shuah Khan, Greg KH, linux-kselftest, Andy Lutomirski
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Lutomirski <luto@kernel.org>
commit 796a3bae2fba6810427efdb314a1c126c9490fb3 upstream.
test_execve does rather odd mount manipulations to safely create
temporary setuid and setgid executables that aren't visible to the
rest of the system. Those executables end up in the test's cwd, but
that cwd is MNT_DETACHed.
The core namespace code considers MNT_DETACHed trees to belong to no
mount namespace at all and, in general, MNT_DETACHed trees are only
barely function. This interacted with commit 380cf5ba6b0a ("fs:
Treat foreign mounts as nosuid") to cause all MNT_DETACHed trees to
act as though they're nosuid, breaking the test.
Fix it by just not detaching the tree. It's still in a private
mount namespace and is therefore still invisible to the rest of the
system (except via /proc, and the same nosuid logic will protect all
other programs on the system from believing in test_execve's setuid
bits).
While we're at it, fix some blatant whitespace problems.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: 380cf5ba6b0a ("fs: Treat foreign mounts as nosuid")
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Shuah Khan <shuahkh@osg.samsung.com>
Cc: Greg KH <greg@kroah.com>
Cc: linux-kselftest@vger.kernel.org
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
tools/testing/selftests/capabilities/test_execve.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
--- a/tools/testing/selftests/capabilities/test_execve.c
+++ b/tools/testing/selftests/capabilities/test_execve.c
@@ -138,9 +138,6 @@ static void chdir_to_tmpfs(void)
if (chdir(cwd) != 0)
err(1, "chdir to private tmpfs");
-
- if (umount2(".", MNT_DETACH) != 0)
- err(1, "detach private tmpfs");
}
static void copy_fromat_to(int fromfd, const char *fromname, const char *toname)
@@ -248,7 +245,7 @@ static int do_tests(int uid, const char
err(1, "chown");
if (chmod("validate_cap_sgidnonroot", S_ISGID | 0710) != 0)
err(1, "chmod");
-}
+ }
capng_get_caps_process();
@@ -384,7 +381,7 @@ static int do_tests(int uid, const char
} else {
printf("[RUN]\tNon-root +ia, sgidnonroot => i\n");
exec_other_validate_cap("./validate_cap_sgidnonroot",
- false, false, true, false);
+ false, false, true, false);
if (fork_wait()) {
printf("[RUN]\tNon-root +ia, sgidroot => i\n");
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 67/84] crypto: atmel - only treat EBUSY as transient if backlog
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (61 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 64/84] selftests/capabilities: Fix the test_execve test Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 68/84] crypto: sha1-ssse3 - Disable avx2 Greg Kroah-Hartman
` (13 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Gilad Ben-Yossef, Herbert Xu
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gilad Ben-Yossef <gilad@benyossef.com>
commit 1606043f214f912a52195293614935811a6e3e53 upstream.
The Atmel SHA driver was treating -EBUSY as indication of queueing
to backlog without checking that backlog is enabled for the request.
Fix it by checking request flags.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/crypto/atmel-sha.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -1204,7 +1204,9 @@ static int atmel_sha_finup(struct ahash_
ctx->flags |= SHA_FLAGS_FINUP;
err1 = atmel_sha_update(req);
- if (err1 == -EINPROGRESS || err1 == -EBUSY)
+ if (err1 == -EINPROGRESS ||
+ (err1 == -EBUSY && (ahash_request_flags(req) &
+ CRYPTO_TFM_REQ_MAY_BACKLOG)))
return err1;
/*
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 68/84] crypto: sha1-ssse3 - Disable avx2
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (62 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 67/84] crypto: atmel - only treat EBUSY as transient if backlog Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 71/84] KEYS: DH: validate __spare field Greg Kroah-Hartman
` (12 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Jan Stancek, Herbert Xu
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Herbert Xu <herbert@gondor.apana.org.au>
commit b82ce24426a4071da9529d726057e4e642948667 upstream.
It has been reported that sha1-avx2 can cause page faults by reading
beyond the end of the input. This patch disables it until it can be
fixed.
Fixes: 7c1da8d0d046 ("crypto: sha - SHA1 transform x86_64 AVX2")
Reported-by: Jan Stancek <jstancek@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/crypto/sha1_ssse3_glue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/crypto/sha1_ssse3_glue.c
+++ b/arch/x86/crypto/sha1_ssse3_glue.c
@@ -201,7 +201,7 @@ asmlinkage void sha1_transform_avx2(u32
static bool avx2_usable(void)
{
- if (avx_usable() && boot_cpu_has(X86_FEATURE_AVX2)
+ if (false && avx_usable() && boot_cpu_has(X86_FEATURE_AVX2)
&& boot_cpu_has(X86_FEATURE_BMI1)
&& boot_cpu_has(X86_FEATURE_BMI2))
return true;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 71/84] KEYS: DH: validate __spare field
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (63 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 68/84] crypto: sha1-ssse3 - Disable avx2 Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 72/84] sched/headers/uapi: Fix linux/sched/types.h userspace compilation errors Greg Kroah-Hartman
` (11 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Eric Biggers, David Howells, James Morris
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Biggers <ebiggers@google.com>
commit 4f9dabfaf8df971f8a3b6aa324f8f817be38d538 upstream.
Syscalls must validate that their reserved arguments are zero and return
EINVAL otherwise. Otherwise, it will be impossible to actually use them
for anything in the future because existing programs may be passing
garbage in. This is standard practice when adding new APIs.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
security/keys/compat_dh.c | 2 ++
security/keys/dh.c | 5 +++++
2 files changed, 7 insertions(+)
--- a/security/keys/compat_dh.c
+++ b/security/keys/compat_dh.c
@@ -33,6 +33,8 @@ long compat_keyctl_dh_compute(struct key
kdfcopy.hashname = compat_ptr(compat_kdfcopy.hashname);
kdfcopy.otherinfo = compat_ptr(compat_kdfcopy.otherinfo);
kdfcopy.otherinfolen = compat_kdfcopy.otherinfolen;
+ memcpy(kdfcopy.__spare, compat_kdfcopy.__spare,
+ sizeof(kdfcopy.__spare));
return __keyctl_dh_compute(params, buffer, buflen, &kdfcopy);
}
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -266,6 +266,11 @@ long __keyctl_dh_compute(struct keyctl_d
if (kdfcopy) {
char *hashname;
+ if (memchr_inv(kdfcopy->__spare, 0, sizeof(kdfcopy->__spare))) {
+ ret = -EINVAL;
+ goto out1;
+ }
+
if (buflen > KEYCTL_KDF_MAX_OUTPUT_LEN ||
kdfcopy->otherinfolen > KEYCTL_KDF_MAX_OI_LEN) {
ret = -EMSGSIZE;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 72/84] sched/headers/uapi: Fix linux/sched/types.h userspace compilation errors
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (64 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 71/84] KEYS: DH: validate __spare field Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 73/84] sched/topology: Fix building of overlapping sched-groups Greg Kroah-Hartman
` (10 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dmitry V. Levin, Linus Torvalds,
Peter Zijlstra, Thomas Gleixner, Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry V. Levin <ldv@altlinux.org>
commit 242fc35290bd8cf0effc6e3474e3a417985de2f3 upstream.
Consistently use types provided by <linux/types.h> to fix the following
linux/sched/types.h userspace compilation errors:
/usr/include/linux/sched/types.h:57:2: error: unknown type name 'u32'
u32 size;
...
u64 sched_period;
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: e2d1e2aec572 ("sched/headers: Move various ABI definitions to <uapi/linux/sched/types.h>")
Link: http://lkml.kernel.org/r/20170705162328.GA11026@altlinux.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
include/uapi/linux/sched/types.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
--- a/include/uapi/linux/sched/types.h
+++ b/include/uapi/linux/sched/types.h
@@ -54,21 +54,21 @@ struct sched_param {
* available in the scheduling class file or in Documentation/.
*/
struct sched_attr {
- u32 size;
+ __u32 size;
- u32 sched_policy;
- u64 sched_flags;
+ __u32 sched_policy;
+ __u64 sched_flags;
/* SCHED_NORMAL, SCHED_BATCH */
- s32 sched_nice;
+ __s32 sched_nice;
/* SCHED_FIFO, SCHED_RR */
- u32 sched_priority;
+ __u32 sched_priority;
/* SCHED_DEADLINE */
- u64 sched_runtime;
- u64 sched_deadline;
- u64 sched_period;
+ __u64 sched_runtime;
+ __u64 sched_deadline;
+ __u64 sched_period;
};
#endif /* _UAPI_LINUX_SCHED_TYPES_H */
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 73/84] sched/topology: Fix building of overlapping sched-groups
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (65 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 72/84] sched/headers/uapi: Fix linux/sched/types.h userspace compilation errors Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 74/84] sched/topology: Optimize build_group_mask() Greg Kroah-Hartman
` (9 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Zijlstra (Intel),
Linus Torvalds, Mike Galbraith, Thomas Gleixner, Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <peterz@infradead.org>
commit 0372dd2736e02672ac6e189c31f7d8c02ad543cd upstream.
When building the overlapping groups, we very obviously should start
with the previous domain of _this_ @cpu, not CPU-0.
This can be readily demonstrated with a topology like:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10
Where (for example) CPU1 ends up generating the following nonsensical groups:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 2 0
[] domain 1: span 0-3 level NUMA
[] groups: 1-3 (cpu_capacity = 3072) 0-1,3 (cpu_capacity = 3072)
Where the fact that domain 1 doesn't include a group with span 0-2 is
the obvious fail.
With patch this looks like:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 0 2
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (cpu_capacity = 3072) 0,2-3 (cpu_capacity = 3072)
Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -525,7 +525,7 @@ build_overlap_sched_groups(struct sched_
cpumask_clear(covered);
- for_each_cpu(i, span) {
+ for_each_cpu_wrap(i, span, cpu) {
struct cpumask *sg_span;
if (cpumask_test_cpu(i, covered))
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 74/84] sched/topology: Optimize build_group_mask()
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (66 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 73/84] sched/topology: Fix building of overlapping sched-groups Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 75/84] sched/topology: Fix overlapping sched_group_mask Greg Kroah-Hartman
` (8 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Lauro Ramos Venancio,
Peter Zijlstra (Intel),
Linus Torvalds, Mike Galbraith, Thomas Gleixner, lwang, riel,
Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lauro Ramos Venancio <lvenanci@redhat.com>
commit f32d782e31bf079f600dcec126ed117b0577e85c upstream.
The group mask is always used in intersection with the group CPUs. So,
when building the group mask, we don't have to care about CPUs that are
not part of the group.
Signed-off-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: lwang@redhat.com
Cc: riel@redhat.com
Link: http://lkml.kernel.org/r/1492717903-5195-2-git-send-email-lvenanci@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/topology.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -490,12 +490,12 @@ enum s_alloc {
*/
static void build_group_mask(struct sched_domain *sd, struct sched_group *sg)
{
- const struct cpumask *span = sched_domain_span(sd);
+ const struct cpumask *sg_span = sched_group_cpus(sg);
struct sd_data *sdd = sd->private;
struct sched_domain *sibling;
int i;
- for_each_cpu(i, span) {
+ for_each_cpu(i, sg_span) {
sibling = *per_cpu_ptr(sdd->sd, i);
if (!cpumask_test_cpu(i, sched_domain_span(sibling)))
continue;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 75/84] sched/topology: Fix overlapping sched_group_mask
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (67 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 74/84] sched/topology: Optimize build_group_mask() Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 76/84] PM / wakeirq: Convert to SRCU Greg Kroah-Hartman
` (7 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Peter Zijlstra (Intel),
Linus Torvalds, Mike Galbraith, Thomas Gleixner, Ingo Molnar
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peter Zijlstra <peterz@infradead.org>
commit 73bb059f9b8a00c5e1bf2f7ca83138c05d05e600 upstream.
The point of sched_group_mask is to select those CPUs from
sched_group_cpus that can actually arrive at this balance domain.
The current code gets it wrong, as can be readily demonstrated with a
topology like:
node 0 1 2 3
0: 10 20 30 20
1: 20 10 20 30
2: 30 20 10 20
3: 20 30 20 10
Where (for example) domain 1 on CPU1 ends up with a mask that includes
CPU0:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 (mask: 1), 2, 0
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (mask: 0-2) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)
This causes sched_balance_cpu() to compute the wrong CPU and
consequently should_we_balance() will terminate early resulting in
missed load-balance opportunities.
The fixed topology looks like:
[] CPU1 attaching sched-domain:
[] domain 0: span 0-2 level NUMA
[] groups: 1 (mask: 1), 2, 0
[] domain 1: span 0-3 level NUMA
[] groups: 0-2 (mask: 1) (cpu_capacity: 3072), 0,2-3 (cpu_capacity: 3072)
(note: this relies on OVERLAP domains to always have children, this is
true because the regular topology domains are still here -- this is
before degenerate trimming)
Debugged-by: Lauro Ramos Venancio <lvenanci@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Fixes: e3589f6c81e4 ("sched: Allow for overlapping sched_domain spans")
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/sched/topology.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -480,6 +480,9 @@ enum s_alloc {
* Build an iteration mask that can exclude certain CPUs from the upwards
* domain traversal.
*
+ * Only CPUs that can arrive at this group should be considered to continue
+ * balancing.
+ *
* Asymmetric node setups can result in situations where the domain tree is of
* unequal depth, make sure to skip domains that already cover the entire
* range.
@@ -497,11 +500,24 @@ static void build_group_mask(struct sche
for_each_cpu(i, sg_span) {
sibling = *per_cpu_ptr(sdd->sd, i);
- if (!cpumask_test_cpu(i, sched_domain_span(sibling)))
+
+ /*
+ * Can happen in the asymmetric case, where these siblings are
+ * unused. The mask will not be empty because those CPUs that
+ * do have the top domain _should_ span the domain.
+ */
+ if (!sibling->child)
+ continue;
+
+ /* If we would not end up here, we can't continue from here */
+ if (!cpumask_equal(sg_span, sched_domain_span(sibling->child)))
continue;
cpumask_set_cpu(i, sched_group_mask(sg));
}
+
+ /* We must not have empty masks here */
+ WARN_ON_ONCE(cpumask_empty(sched_group_mask(sg)));
}
/*
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 76/84] PM / wakeirq: Convert to SRCU
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (68 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 75/84] sched/topology: Fix overlapping sched_group_mask Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 77/84] pstore: Fix leaked pstore_record in pstore_get_backend_records() Greg Kroah-Hartman
` (6 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Brian Norris, Paul E. McKenney,
Thomas Gleixner, Tony Lindgren, Rafael J. Wysocki
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Gleixner <tglx@linutronix.de>
commit ea0212f40c6bc0594c8eff79266759e3ecd4bacc upstream.
The wakeirq infrastructure uses RCU to protect the list of wakeirqs. That
breaks the irq bus locking infrastructure, which is allows sleeping
functions to be called so interrupt controllers behind slow busses,
e.g. i2c, can be handled.
The wakeirq functions hold rcu_read_lock and call into irq functions, which
in case of interrupts using the irq bus locking will trigger a
might_sleep() splat.
Convert the wakeirq infrastructure to Sleepable RCU and unbreak it.
Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Reported-by: Brian Norris <briannorris@chromium.org>
Suggested-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/power/wakeup.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -60,6 +60,8 @@ static LIST_HEAD(wakeup_sources);
static DECLARE_WAIT_QUEUE_HEAD(wakeup_count_wait_queue);
+DEFINE_STATIC_SRCU(wakeup_srcu);
+
static struct wakeup_source deleted_ws = {
.name = "deleted",
.lock = __SPIN_LOCK_UNLOCKED(deleted_ws.lock),
@@ -198,7 +200,7 @@ void wakeup_source_remove(struct wakeup_
spin_lock_irqsave(&events_lock, flags);
list_del_rcu(&ws->entry);
spin_unlock_irqrestore(&events_lock, flags);
- synchronize_rcu();
+ synchronize_srcu(&wakeup_srcu);
}
EXPORT_SYMBOL_GPL(wakeup_source_remove);
@@ -332,12 +334,12 @@ void device_wakeup_detach_irq(struct dev
void device_wakeup_arm_wake_irqs(void)
{
struct wakeup_source *ws;
+ int srcuidx;
- rcu_read_lock();
+ srcuidx = srcu_read_lock(&wakeup_srcu);
list_for_each_entry_rcu(ws, &wakeup_sources, entry)
dev_pm_arm_wake_irq(ws->wakeirq);
-
- rcu_read_unlock();
+ srcu_read_unlock(&wakeup_srcu, srcuidx);
}
/**
@@ -348,12 +350,12 @@ void device_wakeup_arm_wake_irqs(void)
void device_wakeup_disarm_wake_irqs(void)
{
struct wakeup_source *ws;
+ int srcuidx;
- rcu_read_lock();
+ srcuidx = srcu_read_lock(&wakeup_srcu);
list_for_each_entry_rcu(ws, &wakeup_sources, entry)
dev_pm_disarm_wake_irq(ws->wakeirq);
-
- rcu_read_unlock();
+ srcu_read_unlock(&wakeup_srcu, srcuidx);
}
/**
@@ -804,10 +806,10 @@ EXPORT_SYMBOL_GPL(pm_wakeup_dev_event);
void pm_print_active_wakeup_sources(void)
{
struct wakeup_source *ws;
- int active = 0;
+ int srcuidx, active = 0;
struct wakeup_source *last_activity_ws = NULL;
- rcu_read_lock();
+ srcuidx = srcu_read_lock(&wakeup_srcu);
list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
if (ws->active) {
pr_debug("active wakeup source: %s\n", ws->name);
@@ -823,7 +825,7 @@ void pm_print_active_wakeup_sources(void
if (!active && last_activity_ws)
pr_debug("last active wakeup source: %s\n",
last_activity_ws->name);
- rcu_read_unlock();
+ srcu_read_unlock(&wakeup_srcu, srcuidx);
}
EXPORT_SYMBOL_GPL(pm_print_active_wakeup_sources);
@@ -950,8 +952,9 @@ void pm_wakep_autosleep_enabled(bool set
{
struct wakeup_source *ws;
ktime_t now = ktime_get();
+ int srcuidx;
- rcu_read_lock();
+ srcuidx = srcu_read_lock(&wakeup_srcu);
list_for_each_entry_rcu(ws, &wakeup_sources, entry) {
spin_lock_irq(&ws->lock);
if (ws->autosleep_enabled != set) {
@@ -965,7 +968,7 @@ void pm_wakep_autosleep_enabled(bool set
}
spin_unlock_irq(&ws->lock);
}
- rcu_read_unlock();
+ srcu_read_unlock(&wakeup_srcu, srcuidx);
}
#endif /* CONFIG_PM_AUTOSLEEP */
@@ -1026,15 +1029,16 @@ static int print_wakeup_source_stats(str
static int wakeup_sources_stats_show(struct seq_file *m, void *unused)
{
struct wakeup_source *ws;
+ int srcuidx;
seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
"expire_count\tactive_since\ttotal_time\tmax_time\t"
"last_change\tprevent_suspend_time\n");
- rcu_read_lock();
+ srcuidx = srcu_read_lock(&wakeup_srcu);
list_for_each_entry_rcu(ws, &wakeup_sources, entry)
print_wakeup_source_stats(m, ws);
- rcu_read_unlock();
+ srcu_read_unlock(&wakeup_srcu, srcuidx);
print_wakeup_source_stats(m, &deleted_ws);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 77/84] pstore: Fix leaked pstore_record in pstore_get_backend_records()
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (69 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 76/84] PM / wakeirq: Convert to SRCU Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 79/84] ALSA: hda/realtek - change the location for one of two front microphones Greg Kroah-Hartman
` (5 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Douglas Anderson, Kees Cook
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <dianders@chromium.org>
commit f6525b96dd9f68efe374e5aef864975e628de991 upstream.
When the "if (record->size <= 0)" test is true in
pstore_get_backend_records() it's pretty clear that nobody holds a
reference to the allocated pstore_record, yet we don't free it.
Let's free it.
Fixes: 2a2b0acf768c ("pstore: Allocate records on heap instead of stack")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
fs/pstore/platform.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -846,8 +846,10 @@ void pstore_get_backend_records(struct p
record->size = psi->read(record);
/* No more records left in backend? */
- if (record->size <= 0)
+ if (record->size <= 0) {
+ kfree(record);
break;
+ }
decompress_record(record);
rc = pstore_mkfile(root, record);
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 79/84] ALSA: hda/realtek - change the location for one of two front microphones
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (70 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 77/84] pstore: Fix leaked pstore_record in pstore_get_backend_records() Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 80/84] PM / QoS: return -EINVAL for bogus strings Greg Kroah-Hartman
` (4 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Hui Wang, Takashi Iwai
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hui Wang <hui.wang@canonical.com>
commit f33f79f3d0e5caf04dd889cd7cf636261970f009 upstream.
On this Lenovo machine, there are two front mics, and both of them are
assigned the same name "Mic", but pulseaudio can't support two mics
with the same name, as a workaround, we change the location for one of
them, then the driver will assign "Front Mic" and "Mic" for them.
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -4964,6 +4964,7 @@ enum {
ALC233_FIXUP_ASUS_MIC_NO_PRESENCE,
ALC233_FIXUP_EAPD_COEF_AND_MIC_NO_PRESENCE,
ALC233_FIXUP_LENOVO_MULTI_CODECS,
+ ALC294_FIXUP_LENOVO_MIC_LOCATION,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -5737,6 +5738,18 @@ static const struct hda_fixup alc269_fix
.type = HDA_FIXUP_FUNC,
.v.func = alc233_alc662_fixup_lenovo_dual_codecs,
},
+ [ALC294_FIXUP_LENOVO_MIC_LOCATION] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ /* Change the mic location from front to right, otherwise there are
+ two front mics with the same name, pulseaudio can't handle them.
+ This is just a temporary workaround, after applying this fixup,
+ there will be one "Front Mic" and one "Mic" in this machine.
+ */
+ { 0x1a, 0x04a19040 },
+ { }
+ },
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -5918,6 +5931,7 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x17aa, 0x2233, "Thinkpad", ALC292_FIXUP_TPT460),
SND_PCI_QUIRK(0x17aa, 0x30bb, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
SND_PCI_QUIRK(0x17aa, 0x30e2, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
+ SND_PCI_QUIRK(0x17aa, 0x310c, "ThinkCentre Station", ALC294_FIXUP_LENOVO_MIC_LOCATION),
SND_PCI_QUIRK(0x17aa, 0x3112, "ThinkCentre AIO", ALC233_FIXUP_LENOVO_LINE2_MIC_HOTKEY),
SND_PCI_QUIRK(0x17aa, 0x3902, "Lenovo E50-80", ALC269_FIXUP_DMIC_THINKPAD_ACPI),
SND_PCI_QUIRK(0x17aa, 0x3977, "IdeaPad S210", ALC283_FIXUP_INT_MIC),
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 80/84] PM / QoS: return -EINVAL for bogus strings
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (71 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 79/84] ALSA: hda/realtek - change the location for one of two front microphones Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
2017-07-19 9:44 ` [PATCH 4.12 84/84] kvm: vmx: allow host to access guest MSR_IA32_BNDCFGS Greg Kroah-Hartman
` (3 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Dan Carpenter, Pavel Machek,
Rafael J. Wysocki
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <dan.carpenter@oracle.com>
commit 2ca30331c156ca9e97643ad05dd8930b8fe78b01 upstream.
In the current code, if the user accidentally writes a bogus command to
this sysfs file, then we set the latency tolerance to an uninitialized
variable.
Fixes: 2d984ad132a8 (PM / QoS: Introcuce latency tolerance device PM QoS type)
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/power/sysfs.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/base/power/sysfs.c
+++ b/drivers/base/power/sysfs.c
@@ -272,6 +272,8 @@ static ssize_t pm_qos_latency_tolerance_
value = PM_QOS_LATENCY_TOLERANCE_NO_CONSTRAINT;
else if (!strcmp(buf, "any") || !strcmp(buf, "any\n"))
value = PM_QOS_LATENCY_ANY;
+ else
+ return -EINVAL;
}
ret = dev_pm_qos_update_user_latency_tolerance(dev, value);
return ret < 0 ? ret : n;
^ permalink raw reply [flat|nested] 106+ messages in thread* [PATCH 4.12 84/84] kvm: vmx: allow host to access guest MSR_IA32_BNDCFGS
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (72 preceding siblings ...)
2017-07-19 9:44 ` [PATCH 4.12 80/84] PM / QoS: return -EINVAL for bogus strings Greg Kroah-Hartman
@ 2017-07-19 9:44 ` Greg Kroah-Hartman
[not found] ` <596f88cd.48b4df0a.797d0.d5e3@mx.google.com>
` (2 subsequent siblings)
76 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-19 9:44 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Haozhong Zhang, Paolo Bonzini
4.12-stable review patch. If anyone has any objections, please let me know.
------------------
From: Haozhong Zhang <haozhong.zhang@intel.com>
commit 691bd4340bef49cf7e5855d06cf24444b5bf2d85 upstream.
It's easier for host applications, such as QEMU, if they can always
access guest MSR_IA32_BNDCFGS in VMCS, even though MPX is disabled in
guest cpuid.
Signed-off-by: Haozhong Zhang <haozhong.zhang@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3195,7 +3195,8 @@ static int vmx_get_msr(struct kvm_vcpu *
msr_info->data = vmcs_readl(GUEST_SYSENTER_ESP);
break;
case MSR_IA32_BNDCFGS:
- if (!kvm_mpx_supported() || !guest_cpuid_has_mpx(vcpu))
+ if (!kvm_mpx_supported() ||
+ (!msr_info->host_initiated && !guest_cpuid_has_mpx(vcpu)))
return 1;
msr_info->data = vmcs_read64(GUEST_BNDCFGS);
break;
@@ -3277,7 +3278,8 @@ static int vmx_set_msr(struct kvm_vcpu *
vmcs_writel(GUEST_SYSENTER_ESP, data);
break;
case MSR_IA32_BNDCFGS:
- if (!kvm_mpx_supported() || !guest_cpuid_has_mpx(vcpu))
+ if (!kvm_mpx_supported() ||
+ (!msr_info->host_initiated && !guest_cpuid_has_mpx(vcpu)))
return 1;
if (is_noncanonical_address(data & PAGE_MASK) ||
(data & MSR_IA32_BNDCFGS_RSVD))
^ permalink raw reply [flat|nested] 106+ messages in thread[parent not found: <596f88cd.48b4df0a.797d0.d5e3@mx.google.com>]
* Re: [PATCH 4.12 00/84] 4.12.3-stable review
[not found] ` <596f88cd.48b4df0a.797d0.d5e3@mx.google.com>
@ 2017-07-19 16:36 ` Shuah Khan
2017-07-22 15:47 ` Kevin Hilman
[not found] ` <7hfudosc1k.fsf@baylibre.com>
1 sibling, 1 reply; 106+ messages in thread
From: Shuah Khan @ 2017-07-19 16:36 UTC (permalink / raw)
To: kernelci.org bot, Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, Shuah Khan
On 07/19/2017 10:29 AM, kernelci.org bot wrote:
> stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed (v4.12.2-85-g908a8d27d1c5)
>
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
>
> Tree: stable-rc
> Branch: linux-4.12.y
> Git Describe: v4.12.2-85-g908a8d27d1c5
> Git Commit: 908a8d27d1c52aaafab80d7267e8e61f9a174ecc
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 44 unique boards, 14 SoC families, 24 builds out of 204
>
> Boot Regressions Detected:
>
> arm:
>
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> exynos5422-odroidxu3:
> lab-collabora: new failure (last pass: v4.12.2)
I am seeing boot failure on odroid-xu4 with 4.13-rc1 with exynos_defconfig.
4.12 is fine.
I am debugging this and based on this report it sounds like it might be
easier for me to start with 4.12 and try to isolate the change. Will keep
you posted.
-- Shuah
>
> Boot Failures Detected:
>
> arm:
>
> multi_v7_defconfig
> imx6ul-pico-hobbit_rootfs:nfs: 1 failed lab
>
> tegra_defconfig
> tegra124-jetson-tk1_rootfs:nfs: 1 failed lab
>
> mvebu_v5_defconfig
> kirkwood-openblocks_a7_rootfs:nfs: 1 failed lab
>
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
> exynos5422-odroidxu3: 1 failed lab
> omap4-panda: 1 failed lab
>
> ---
> For more info write to <info@kernelci.org>
>
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 00/84] 4.12.3-stable review
2017-07-19 16:36 ` [PATCH 4.12 00/84] 4.12.3-stable review Shuah Khan
@ 2017-07-22 15:47 ` Kevin Hilman
2017-07-24 9:11 ` Sjoerd Simons
0 siblings, 1 reply; 106+ messages in thread
From: Kevin Hilman @ 2017-07-22 15:47 UTC (permalink / raw)
To: Shuah Khan
Cc: kernelci.org bot, Greg Kroah-Hartman, linux-kernel, torvalds,
akpm, linux, patches, ben.hutchings, stable, sjoerd.simons
+ Sjoerd @ Collabora
Shuah Khan <shuahkh@osg.samsung.com> writes:
> On 07/19/2017 10:29 AM, kernelci.org bot wrote:
>> stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed (v4.12.2-85-g908a8d27d1c5)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
>>
>> Tree: stable-rc
>> Branch: linux-4.12.y
>> Git Describe: v4.12.2-85-g908a8d27d1c5
>> Git Commit: 908a8d27d1c52aaafab80d7267e8e61f9a174ecc
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 44 unique boards, 14 SoC families, 24 builds out of 204
>>
>> Boot Regressions Detected:
>>
>> arm:
>>
>> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
>> exynos5422-odroidxu3:
>> lab-collabora: new failure (last pass: v4.12.2)
>
> I am seeing boot failure on odroid-xu4 with 4.13-rc1 with exynos_defconfig.
> 4.12 is fine.
>
> I am debugging this and based on this report it sounds like it might be
> easier for me to start with 4.12 and try to isolate the change. Will keep
> you posted.
I suspect that these CONFIG_PROVE_LOCKING=y issues are actually not
kernel issues directly, but kernel size limitations based on the load
addresses used in lab-collabora LAVA.
Comparing against my lab, I'm using load address: 0x42000000 where as
lab-collabora is using 0x41000000. I'm wondering if that is not enough
room to ucompress down to the default boot address without overwriting itself?
I suspect the same problem in the lab-collabora panda boots since the
load address differes from mine in the same way.
@Sjoerd: can someone in lab-collabora maybe have a closer look?
Kevin
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 00/84] 4.12.3-stable review
2017-07-22 15:47 ` Kevin Hilman
@ 2017-07-24 9:11 ` Sjoerd Simons
0 siblings, 0 replies; 106+ messages in thread
From: Sjoerd Simons @ 2017-07-24 9:11 UTC (permalink / raw)
To: Kevin Hilman, Shuah Khan
Cc: kernelci.org bot, Greg Kroah-Hartman, linux-kernel, torvalds,
akpm, linux, patches, ben.hutchings, stable, Guillaume Tucker
On Sat, 2017-07-22 at 08:47 -0700, Kevin Hilman wrote:
> + Sjoerd @ Collabora
>
> Shuah Khan <shuahkh@osg.samsung.com> writes:
>
> > On 07/19/2017 10:29 AM, kernelci.org bot wrote:
> > > stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed
> > > (v4.12.2-85-g908a8d27d1c5)
> > >
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/br
> > > anch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/l
> > > inux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
> > >
> > > Tree: stable-rc
> > > Branch: linux-4.12.y
> > > Git Describe: v4.12.2-85-g908a8d27d1c5
> > > Git Commit: 908a8d27d1c52aaafab80d7267e8e61f9a174ecc
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/li
> > > nux-stable-rc.git
> > > Tested: 44 unique boards, 14 SoC families, 24 builds out of 204
> > >
> > > Boot Regressions Detected:
> > >
> > > arm:
> > >
> > > multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > > exynos5422-odroidxu3:
> > > lab-collabora: new failure (last pass: v4.12.2)
> >
> > I am seeing boot failure on odroid-xu4 with 4.13-rc1 with
> > exynos_defconfig.
> > 4.12 is fine.
> >
> > I am debugging this and based on this report it sounds like it
> > might be
> > easier for me to start with 4.12 and try to isolate the change.
> > Will keep
> > you posted.
>
> I suspect that these CONFIG_PROVE_LOCKING=y issues are actually not
> kernel issues directly, but kernel size limitations based on the load
> addresses used in lab-collabora LAVA.
>
> Comparing against my lab, I'm using load address: 0x42000000 where as
> lab-collabora is using 0x41000000. I'm wondering if that is not
> enough
> room to ucompress down to the default boot address without
> overwriting itself?
Adjusting the load address for XU3 resolved the boot failure (changing
from memory start + 16M to memory start + 32M which is the default for
that board in u-boot/lava as well these days)
> I suspect the same problem in the lab-collabora panda boots since the
> load address differes from mine in the same way.
Correct, tuning the load addresses there results in a happy boot.
The kernel does relocate itself on boot if it detects decompression
will overwrite itself. On the panda though that seemingly meant the dtb
got overwritten, just bumping that out of the way made it boot as well.
I didn't check if the same happened on XU3 (which has/had far more
space between the kernel and the dtb).. That said, it's far safer (and
faster) to avoid running into that corner case :)
> @Sjoerd: can someone in lab-collabora maybe have a closer look?
>
> Kevin
--
Sjoerd Simons
Collabora Ltd.
^ permalink raw reply [flat|nested] 106+ messages in thread
[parent not found: <7hfudosc1k.fsf@baylibre.com>]
* Re: [PATCH 4.12 00/84] 4.12.3-stable review
[not found] ` <7hfudosc1k.fsf@baylibre.com>
@ 2017-08-01 8:21 ` Jan Lübbe
0 siblings, 0 replies; 106+ messages in thread
From: Jan Lübbe @ 2017-08-01 8:21 UTC (permalink / raw)
To: Kevin Hilman, kernelci.org bot
Cc: Greg Kroah-Hartman, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
On Sat, 2017-07-22 at 08:53 -0700, Kevin Hilman wrote:
> > Boot Failures Detected:
> >
> > arm:
> >
> > multi_v7_defconfig
> > imx6ul-pico-hobbit_rootfs:nfs: 1 failed lab
> >
> > tegra_defconfig
> > tegra124-jetson-tk1_rootfs:nfs: 1 failed lab
>
> @Jan looks like a couple boards in your lab are having NFS issues
> with stable kernels. Could you have a closer look?
NFS was not configured correctly in our lab. We've fixed it and they
now boot correctly via NFS.
Regards,
Jan
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 00/84] 4.12.3-stable review
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (74 preceding siblings ...)
[not found] ` <596f88cd.48b4df0a.797d0.d5e3@mx.google.com>
@ 2017-07-19 20:35 ` Guenter Roeck
2017-07-20 5:06 ` Greg Kroah-Hartman
2017-07-19 23:37 ` Shuah Khan
76 siblings, 1 reply; 106+ messages in thread
From: Guenter Roeck @ 2017-07-19 20:35 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Wed, Jul 19, 2017 at 11:43:06AM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.12.3 release.
> There are 84 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Jul 21 09:22:37 UTC 2017.
> Anything received after that time might be too late.
>
Build results:
total: 145 pass: 145 fail: 0
Qemu test results:
total: 122 pass: 122 fail: 0
Details are available at http://kerneltests.org/builders.
Guenter
^ permalink raw reply [flat|nested] 106+ messages in thread* Re: [PATCH 4.12 00/84] 4.12.3-stable review
2017-07-19 20:35 ` Guenter Roeck
@ 2017-07-20 5:06 ` Greg Kroah-Hartman
0 siblings, 0 replies; 106+ messages in thread
From: Greg Kroah-Hartman @ 2017-07-20 5:06 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings, stable
On Wed, Jul 19, 2017 at 01:35:59PM -0700, Guenter Roeck wrote:
> On Wed, Jul 19, 2017 at 11:43:06AM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.12.3 release.
> > There are 84 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Fri Jul 21 09:22:37 UTC 2017.
> > Anything received after that time might be too late.
> >
> Build results:
> total: 145 pass: 145 fail: 0
> Qemu test results:
> total: 122 pass: 122 fail: 0
>
> Details are available at http://kerneltests.org/builders.
Great, thanks for letting me know about all of these.
greg k-h
^ permalink raw reply [flat|nested] 106+ messages in thread
* Re: [PATCH 4.12 00/84] 4.12.3-stable review
2017-07-19 9:43 [PATCH 4.12 00/84] 4.12.3-stable review Greg Kroah-Hartman
` (75 preceding siblings ...)
2017-07-19 20:35 ` Guenter Roeck
@ 2017-07-19 23:37 ` Shuah Khan
76 siblings, 0 replies; 106+ messages in thread
From: Shuah Khan @ 2017-07-19 23:37 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, patches, ben.hutchings, stable, shuah Khan
On 07/19/2017 03:43 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.12.3 release.
> There are 84 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Fri Jul 21 09:22:37 UTC 2017.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.12.3-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.12.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 106+ messages in thread