* Patch "IB/ipoib: Replace list_del of the neigh->list with list_del_init" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex,
yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Replace list_del of the neigh->list with list_del_init
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:27 +0200
Subject: IB/ipoib: Replace list_del of the neigh->list with list_del_init
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit c586071d1dc8227a7182179b8e50ee92cc43f6d2 ]
In order to resolve a situation where a few process delete
the same list element in sequence and cause panic, list_del
is replaced with list_del_init. In this case if the first
process that calls list_del releases the lock before acquiring
it again, other processes who can acquire the lock will call
list_del_init.
Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_main.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -1302,7 +1302,7 @@ static void __ipoib_reap_neigh(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1466,7 +1466,7 @@ void ipoib_neigh_free(struct ipoib_neigh
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
return;
} else {
@@ -1551,7 +1551,7 @@ void ipoib_del_neighs_by_gid(struct net_
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from parent list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
} else {
np = &neigh->hnext;
@@ -1593,7 +1593,7 @@ static void ipoib_flush_neighs(struct ip
rcu_dereference_protected(neigh->hnext,
lockdep_is_held(&priv->lock)));
/* remove from path/mc list */
- list_del(&neigh->list);
+ list_del_init(&neigh->list);
call_rcu(&neigh->rcu, ipoib_neigh_reclaim);
}
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.9/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.9/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.9/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "IB/ipoib: Fix deadlock over vlan_mutex" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon, valex
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: Fix deadlock over vlan_mutex
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-fix-deadlock-over-vlan_mutex.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:22 +0200
Subject: IB/ipoib: Fix deadlock over vlan_mutex
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 1c3098cdb05207e740715857df7b0998e372f527 ]
This patch fixes Deadlock while executing ipoib_vlan_delete.
The function takes the vlan_rwsem semaphore and calls
unregister_netdevice. The later function calls
ipoib_mcast_stop_thread that cause workqueue flush.
When the queue has one of the ipoib_ib_dev_flush_xxx events,
a deadlock occur because these events also tries to catch the
same vlan_rwsem semaphore.
To fix, unregister_netdevice should be called after releasing
the semaphore.
Fixes: cbbe1efa4972 ("IPoIB: Fix deadlock between ipoib_open() and child interface create")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -193,7 +193,6 @@ int ipoib_vlan_delete(struct net_device
list_for_each_entry_safe(priv, tpriv, &ppriv->child_intfs, list) {
if (priv->pkey == pkey &&
priv->child_type == IPOIB_LEGACY_CHILD) {
- unregister_netdevice(priv->dev);
list_del(&priv->list);
dev = priv->dev;
break;
@@ -201,6 +200,11 @@ int ipoib_vlan_delete(struct net_device
}
up_write(&ppriv->vlan_rwsem);
+ if (dev) {
+ ipoib_dbg(ppriv, "delete child vlan %s\n", dev->name);
+ unregister_netdevice(dev);
+ }
+
rtnl_unlock();
if (dev) {
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.9/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.9/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.9/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "IB/rxe: Add a runtime check in alloc_index()" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: bart.vanassche, alexander.levin, andrew.boyer, dledford, gregkh,
monis
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/rxe: Add a runtime check in alloc_index()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-rxe-add-a-runtime-check-in-alloc_index.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Tue, 10 Jan 2017 11:15:48 -0800
Subject: IB/rxe: Add a runtime check in alloc_index()
From: Bart Van Assche <bart.vanassche@sandisk.com>
[ Upstream commit 642c7cbcaf2ffc1e27f67eda3dc47347ac5aff37 ]
Since index values equal to or above 'range' can trigger memory
corruption, complain if index >= range.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Andrew Boyer <andrew.boyer@dell.com>
Cc: Moni Shoua <monis@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_pool.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/infiniband/sw/rxe/rxe_pool.c
+++ b/drivers/infiniband/sw/rxe/rxe_pool.c
@@ -274,6 +274,7 @@ static u32 alloc_index(struct rxe_pool *
if (index >= range)
index = find_first_zero_bit(pool->table, range);
+ WARN_ON_ONCE(index >= range);
set_bit(index, pool->table);
pool->last = index;
return index + pool->min_index;
Patches currently in stable-queue which might be from bart.vanassche@sandisk.com are
queue-4.9/ib-rxe-add-a-runtime-check-in-alloc_index.patch
queue-4.9/ib-rxe-fix-a-mr-reference-leak-in-check_rkey.patch
^ permalink raw reply
* Patch "IB/ipoib: rtnl_unlock can not come after free_netdev" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ferasda, alexander.levin, dledford, erezsh, gregkh, leon,
ogerlitz, yuval.shaia
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/ipoib: rtnl_unlock can not come after free_netdev
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Feras Daoud <ferasda@mellanox.com>
Date: Wed, 28 Dec 2016 14:47:24 +0200
Subject: IB/ipoib: rtnl_unlock can not come after free_netdev
From: Feras Daoud <ferasda@mellanox.com>
[ Upstream commit 89a3987ab7a923c047c6dec008e60ad6f41fac22 ]
The ipoib_vlan_add function calls rtnl_unlock after free_netdev,
rtnl_unlock not only releases the lock, but also calls netdev_run_todo.
The latter function browses the net_todo_list array and completes the
unregistration of all its net_device instances. If we call free_netdev
before rtnl_unlock, then netdev_run_todo call over the freed device causes
panic.
To fix, move rtnl_unlock call before free_netdev call.
Fixes: 9baa0b036410 ("IB/ipoib: Add rtnl_link_ops support")
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/ulp/ipoib/ipoib_vlan.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_vlan.c
@@ -165,11 +165,11 @@ int ipoib_vlan_add(struct net_device *pd
out:
up_write(&ppriv->vlan_rwsem);
+ rtnl_unlock();
+
if (result)
free_netdev(priv->dev);
- rtnl_unlock();
-
return result;
}
Patches currently in stable-queue which might be from ferasda@mellanox.com are
queue-4.9/ib-ipoib-replace-list_del-of-the-neigh-list-with-list_del_init.patch
queue-4.9/ib-ipoib-rtnl_unlock-can-not-come-after-free_netdev.patch
queue-4.9/ib-ipoib-fix-deadlock-over-vlan_mutex.patch
^ permalink raw reply
* Patch "ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: nfont, alexander.levin, davem, gregkh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ibmvnic-free-tx-rx-scrq-pointer-array-when-releasing-sub-crqs.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Date: Wed, 15 Mar 2017 23:38:07 -0400
Subject: ibmvnic: Free tx/rx scrq pointer array when releasing sub-crqs
From: Nathan Fontenot <nfont@linux.vnet.ibm.com>
[ Upstream commit 9501df3cd9204f5859f649182431616a31ee88a1 ]
The pointer array for the tx/rx sub crqs should be free'ed when
releasing the tx/rx sub crqs.
Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/ibm/ibmvnic.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -1253,6 +1253,7 @@ static void release_sub_crqs(struct ibmv
release_sub_crq_queue(adapter,
adapter->tx_scrq[i]);
}
+ kfree(adapter->tx_scrq);
adapter->tx_scrq = NULL;
}
@@ -1265,6 +1266,7 @@ static void release_sub_crqs(struct ibmv
release_sub_crq_queue(adapter,
adapter->rx_scrq[i]);
}
+ kfree(adapter->rx_scrq);
adapter->rx_scrq = NULL;
}
Patches currently in stable-queue which might be from nfont@linux.vnet.ibm.com are
queue-4.9/ibmvnic-free-tx-rx-scrq-pointer-array-when-releasing-sub-crqs.patch
^ permalink raw reply
* Patch "IB/rxe: Fix a MR reference leak in check_rkey()" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: bart.vanassche, alexander.levin, andrew.boyer, dledford, gregkh,
monis
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
IB/rxe: Fix a MR reference leak in check_rkey()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ib-rxe-fix-a-mr-reference-leak-in-check_rkey.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Bart Van Assche <bart.vanassche@sandisk.com>
Date: Tue, 10 Jan 2017 11:15:51 -0800
Subject: IB/rxe: Fix a MR reference leak in check_rkey()
From: Bart Van Assche <bart.vanassche@sandisk.com>
[ Upstream commit b3a459961014b14c267544c327db033669493295 ]
Avoid that calling check_rkey() for mem->state == RXE_MEM_STATE_FREE
triggers an MR reference leak.
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Reviewed-by: Andrew Boyer <andrew.boyer@dell.com>
Cc: Moni Shoua <monis@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/infiniband/sw/rxe/rxe_resp.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -418,7 +418,7 @@ static enum resp_states check_length(str
static enum resp_states check_rkey(struct rxe_qp *qp,
struct rxe_pkt_info *pkt)
{
- struct rxe_mem *mem;
+ struct rxe_mem *mem = NULL;
u64 va;
u32 rkey;
u32 resid;
@@ -452,38 +452,38 @@ static enum resp_states check_rkey(struc
mem = lookup_mem(qp->pd, access, rkey, lookup_remote);
if (!mem) {
state = RESPST_ERR_RKEY_VIOLATION;
- goto err1;
+ goto err;
}
if (unlikely(mem->state == RXE_MEM_STATE_FREE)) {
state = RESPST_ERR_RKEY_VIOLATION;
- goto err1;
+ goto err;
}
if (mem_check_range(mem, va, resid)) {
state = RESPST_ERR_RKEY_VIOLATION;
- goto err2;
+ goto err;
}
if (pkt->mask & RXE_WRITE_MASK) {
if (resid > mtu) {
if (pktlen != mtu || bth_pad(pkt)) {
state = RESPST_ERR_LENGTH;
- goto err2;
+ goto err;
}
qp->resp.resid = mtu;
} else {
if (pktlen != resid) {
state = RESPST_ERR_LENGTH;
- goto err2;
+ goto err;
}
if ((bth_pad(pkt) != (0x3 & (-resid)))) {
/* This case may not be exactly that
* but nothing else fits.
*/
state = RESPST_ERR_LENGTH;
- goto err2;
+ goto err;
}
}
}
@@ -493,9 +493,9 @@ static enum resp_states check_rkey(struc
qp->resp.mr = mem;
return RESPST_EXECUTE;
-err2:
- rxe_drop_ref(mem);
-err1:
+err:
+ if (mem)
+ rxe_drop_ref(mem);
return state;
}
Patches currently in stable-queue which might be from bart.vanassche@sandisk.com are
queue-4.9/ib-rxe-add-a-runtime-check-in-alloc_index.patch
queue-4.9/ib-rxe-fix-a-mr-reference-leak-in-check_rkey.patch
^ permalink raw reply
* Patch "iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: hdegoede, alexander.levin, gregkh, jic23, wens; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iio-adc-axp288-drop-bogus-axp288_adc_ts_pin_ctrl-register-modifications.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 14 Dec 2016 14:55:25 +0100
Subject: iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit fa2849e9649b5180ffc4cb3c3b005261c403093a ]
For some reason the axp288_adc driver was modifying the
AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on
whether the GP_ADC channel or another channel was written.
These bits control when a bias current is send to the TS_PIN, the
GP_ADC has its own pin and a separate bit in another register to
control the bias current.
Not only does changing when to enable the TS_PIN bias current
(always or only when sampling) when reading the GP_ADC make no sense
at all, the code is modifying these bits is writing the entire register,
assuming that all the other bits have their default value.
So if the firmware has configured a different bias-current for either
pin, then that change gets clobbered by the write, likewise if the
firmware has set bit 2 to indicate that the battery has no thermal sensor,
this will get clobbered by the write.
This commit fixes all this, by simply removing all writes to the
AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the
GP_ADC pin, and can actually be harmful.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/axp288_adc.c | 32 +-------------------------------
1 file changed, 1 insertion(+), 31 deletions(-)
--- a/drivers/iio/adc/axp288_adc.c
+++ b/drivers/iio/adc/axp288_adc.c
@@ -28,8 +28,6 @@
#include <linux/iio/driver.h>
#define AXP288_ADC_EN_MASK 0xF1
-#define AXP288_ADC_TS_PIN_GPADC 0xF2
-#define AXP288_ADC_TS_PIN_ON 0xF3
enum axp288_adc_id {
AXP288_ADC_TS,
@@ -123,16 +121,6 @@ static int axp288_adc_read_channel(int *
return IIO_VAL_INT;
}
-static int axp288_adc_set_ts(struct regmap *regmap, unsigned int mode,
- unsigned long address)
-{
- /* channels other than GPADC do not need to switch TS pin */
- if (address != AXP288_GP_ADC_H)
- return 0;
-
- return regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, mode);
-}
-
static int axp288_adc_read_raw(struct iio_dev *indio_dev,
struct iio_chan_spec const *chan,
int *val, int *val2, long mask)
@@ -143,16 +131,7 @@ static int axp288_adc_read_raw(struct ii
mutex_lock(&indio_dev->mlock);
switch (mask) {
case IIO_CHAN_INFO_RAW:
- if (axp288_adc_set_ts(info->regmap, AXP288_ADC_TS_PIN_GPADC,
- chan->address)) {
- dev_err(&indio_dev->dev, "GPADC mode\n");
- ret = -EINVAL;
- break;
- }
ret = axp288_adc_read_channel(val, chan->address, info->regmap);
- if (axp288_adc_set_ts(info->regmap, AXP288_ADC_TS_PIN_ON,
- chan->address))
- dev_err(&indio_dev->dev, "TS pin restore\n");
break;
default:
ret = -EINVAL;
@@ -162,15 +141,6 @@ static int axp288_adc_read_raw(struct ii
return ret;
}
-static int axp288_adc_set_state(struct regmap *regmap)
-{
- /* ADC should be always enabled for internal FG to function */
- if (regmap_write(regmap, AXP288_ADC_TS_PIN_CTRL, AXP288_ADC_TS_PIN_ON))
- return -EIO;
-
- return regmap_write(regmap, AXP20X_ADC_EN1, AXP288_ADC_EN_MASK);
-}
-
static const struct iio_info axp288_adc_iio_info = {
.read_raw = &axp288_adc_read_raw,
.driver_module = THIS_MODULE,
@@ -199,7 +169,7 @@ static int axp288_adc_probe(struct platf
* Set ADC to enabled state at all time, including system suspend.
* otherwise internal fuel gauge functionality may be affected.
*/
- ret = axp288_adc_set_state(axp20x->regmap);
+ ret = regmap_write(info->regmap, AXP20X_ADC_EN1, AXP288_ADC_EN_MASK);
if (ret) {
dev_err(&pdev->dev, "unable to enable ADC device\n");
return ret;
Patches currently in stable-queue which might be from hdegoede@redhat.com are
queue-4.9/iio-adc-axp288-drop-bogus-axp288_adc_ts_pin_ctrl-register-modifications.patch
queue-4.9/power-supply-axp288_fuel_gauge-fix-fuel_gauge_reg_readb-return-on-error.patch
queue-4.9/extcon-axp288-use-vbus-valid-instead-of-present-to-determine-cable-presence.patch
^ permalink raw reply
* Patch "igb: re-assign hw address pointer on reset after PCI error" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: gpiccoli, aaron.f.brown, ahthai, alexander.levin, gregkh,
hathyaga, jeffrey.t.kirsher
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
igb: re-assign hw address pointer on reset after PCI error
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
igb-re-assign-hw-address-pointer-on-reset-after-pci-error.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Date: Thu, 10 Nov 2016 16:46:43 -0200
Subject: igb: re-assign hw address pointer on reset after PCI error
From: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
[ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ]
Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0xFFFFFFFF), it will detach the
net_device, clear the hw_addr pointer and warn to the user that adapter's
link is lost - those steps happen on igb_rd32().
In case a PCI error happens on Power architecture, there's a recovery
mechanism called EEH, that will reset the PCI slot and call driver's
handlers to reset the adapter and network functionality as well.
We observed that once hw_addr is NULL after the error is detected on
igb_rd32(), it's never assigned back, so in the process of resetting
the network functionality we got a NULL pointer dereference in both
igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid
such bug, this patch re-assigns the hw_addr value in the slot_reset
handler.
Reported-by: Anthony H Thai <ahthai@us.ibm.com>
Reported-by: Harsha Thyagaraja <hathyaga@in.ibm.com>
Signed-off-by: Guilherme G Piccoli <gpiccoli@linux.vnet.ibm.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/intel/igb/igb_main.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -7882,6 +7882,11 @@ static pci_ers_result_t igb_io_slot_rese
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
+ /* In case of PCI error, adapter lose its HW address
+ * so we should re-assign it here.
+ */
+ hw->hw_addr = adapter->io_addr;
+
igb_reset(adapter);
wr32(E1000_WUS, ~0);
result = PCI_ERS_RESULT_RECOVERED;
Patches currently in stable-queue which might be from gpiccoli@linux.vnet.ibm.com are
queue-4.9/igb-re-assign-hw-address-pointer-on-reset-after-pci-error.patch
^ permalink raw reply
* Patch "iio: adc: imx25-gcq: Fix module autoload" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: javier, alexander.levin, gregkh, jic23; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: adc: imx25-gcq: Fix module autoload
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iio-adc-imx25-gcq-fix-module-autoload.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Mon, 2 Jan 2017 09:45:45 -0300
Subject: iio: adc: imx25-gcq: Fix module autoload
From: Javier Martinez Canillas <javier@osg.samsung.com>
[ Upstream commit 8f0d7daf53972da0004f7a5a4d938c85333db300 ]
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
$
After this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
alias: of:N*T*Cfsl,imx25-gcqC*
alias: of:N*T*Cfsl,imx25-gcq
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iio/adc/fsl-imx25-gcq.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/iio/adc/fsl-imx25-gcq.c
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -401,6 +401,7 @@ static const struct of_device_id mx25_gc
{ .compatible = "fsl,imx25-gcq", },
{ /* Sentinel */ }
};
+MODULE_DEVICE_TABLE(of, mx25_gcq_ids);
static struct platform_driver mx25_gcq_driver = {
.driver = {
Patches currently in stable-queue which might be from javier@osg.samsung.com are
queue-4.9/exynos-gsc-do-not-swap-cb-cr-for-semi-planar-formats.patch
queue-4.9/iio-adc-imx25-gcq-fix-module-autoload.patch
^ permalink raw reply
* Patch "iio: adc: hx711: Add DT binding for avia,hx711" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: ak, alexander.levin, gregkh, jic23, robh; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iio: adc: hx711: Add DT binding for avia,hx711
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iio-adc-hx711-add-dt-binding-for-avia-hx711.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Andreas Klinger <ak@it-klinger.de>
Date: Thu, 5 Jan 2017 18:51:36 +0100
Subject: iio: adc: hx711: Add DT binding for avia,hx711
From: Andreas Klinger <ak@it-klinger.de>
[ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger <ak@it-klinger.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Documentation/devicetree/bindings/iio/adc/avia-hx711.txt | 18 +++++++++++++++
Documentation/devicetree/bindings/vendor-prefixes.txt | 1
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/avia-hx711.txt
@@ -0,0 +1,18 @@
+* AVIA HX711 ADC chip for weight cells
+ Bit-banging driver
+
+Required properties:
+ - compatible: Should be "avia,hx711"
+ - sck-gpios: Definition of the GPIO for the clock
+ - dout-gpios: Definition of the GPIO for data-out
+ See Documentation/devicetree/bindings/gpio/gpio.txt
+ - avdd-supply: Definition of the regulator used as analog supply
+
+Example:
+weight@0 {
+ compatible = "avia,hx711";
+ sck-gpios = <&gpio3 10 GPIO_ACTIVE_HIGH>;
+ dout-gpios = <&gpio0 7 GPIO_ACTIVE_HIGH>;
+ avdd-suppy = <&avdd>;
+};
+
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -38,6 +38,7 @@ atmel Atmel Corporation
auo AU Optronics Corporation
auvidea Auvidea GmbH
avago Avago Technologies
+avia avia semiconductor
avic Shanghai AVIC Optoelectronics Co., Ltd.
axis Axis Communications AB
boe BOE Technology Group Co., Ltd.
Patches currently in stable-queue which might be from ak@it-klinger.de are
queue-4.9/iio-adc-hx711-add-dt-binding-for-avia-hx711.patch
^ permalink raw reply
* Patch "iommu/exynos: Block SYSMMU while invalidating FLPD cache" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: m.szyprowski, alexander.levin, gregkh, jroedel; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iommu/exynos: Block SYSMMU while invalidating FLPD cache
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iommu-exynos-block-sysmmu-while-invalidating-flpd-cache.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Mon, 20 Mar 2017 10:17:56 +0100
Subject: iommu/exynos: Block SYSMMU while invalidating FLPD cache
From: Marek Szyprowski <m.szyprowski@samsung.com>
[ Upstream commit 7d2aa6b814476a2e2794960f844344519246df72 ]
Documentation specifies that SYSMMU should be in blocked state while
performing TLB/FLPD cache invalidation, so add needed calls to
sysmmu_block/unblock.
Fixes: 66a7ed84b345d ("iommu/exynos: Apply workaround of caching fault page table entries")
CC: stable@vger.kernel.org # v4.10+
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/exynos-iommu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -542,7 +542,10 @@ static void sysmmu_tlb_invalidate_flpdca
spin_lock_irqsave(&data->lock, flags);
if (is_sysmmu_active(data) && data->version >= MAKE_MMU_VER(3, 3)) {
clk_enable(data->clk_master);
- __sysmmu_tlb_invalidate_entry(data, iova, 1);
+ if (sysmmu_block(data)) {
+ __sysmmu_tlb_invalidate_entry(data, iova, 1);
+ sysmmu_unblock(data);
+ }
clk_disable(data->clk_master);
}
spin_unlock_irqrestore(&data->lock, flags);
Patches currently in stable-queue which might be from m.szyprowski@samsung.com are
queue-4.9/iommu-exynos-block-sysmmu-while-invalidating-flpd-cache.patch
^ permalink raw reply
* Re: [PATCH 2/5] KVM: arm/arm64: replace power_off with mp_state=STOPPED
From: Marc Zyngier @ 2017-10-05 8:32 UTC (permalink / raw)
To: Andrew Jones, kvmarm; +Cc: cdall
In-Reply-To: <20170929113041.24371-3-drjones@redhat.com>
On 29/09/17 12:30, Andrew Jones wrote:
> This prepares for more MP states to be used.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> arch/arm/include/asm/kvm_host.h | 6 ++++--
> arch/arm64/include/asm/kvm_host.h | 6 ++++--
> virt/kvm/arm/arm.c | 26 ++++++++++++++------------
> virt/kvm/arm/psci.c | 17 +++++------------
> 4 files changed, 27 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index 4a879f6ff13b..85f3c20b9759 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -171,8 +171,8 @@ struct kvm_vcpu_arch {
> * here.
> */
>
> - /* vcpu power-off state */
> - bool power_off;
> + /* Current VCPU MP state */
> + u32 mp_state;
What is the rational for not using a struct kvm_mp_state directly here?
It is the same thing (a u32), but I certainly find it more explicit than
a bare u32.
>
> /* Don't run the guest (internal implementation need) */
> bool pause;
> @@ -227,6 +227,8 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
>
> struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
> struct kvm_vcpu __percpu **kvm_get_running_vcpus(void);
> +void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
> +void kvm_arm_vcpu_power_on(struct kvm_vcpu *vcpu);
> void kvm_arm_halt_guest(struct kvm *kvm);
> void kvm_arm_resume_guest(struct kvm *kvm);
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index e923b58606e2..25545a87de11 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -255,8 +255,8 @@ struct kvm_vcpu_arch {
> u32 mdscr_el1;
> } guest_debug_preserved;
>
> - /* vcpu power-off state */
> - bool power_off;
> + /* Current VCPU MP state */
> + u32 mp_state;
>
> /* Don't run the guest (internal implementation need) */
> bool pause;
> @@ -328,6 +328,8 @@ int kvm_test_age_hva(struct kvm *kvm, unsigned long hva);
>
> struct kvm_vcpu *kvm_arm_get_running_vcpu(void);
> struct kvm_vcpu * __percpu *kvm_get_running_vcpus(void);
> +void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu);
> +void kvm_arm_vcpu_power_on(struct kvm_vcpu *vcpu);
> void kvm_arm_halt_guest(struct kvm *kvm);
> void kvm_arm_resume_guest(struct kvm *kvm);
>
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index e4bec508ee5b..954e77608d29 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -368,21 +368,23 @@ void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu)
> kvm_timer_vcpu_put(vcpu);
> }
>
> -static void vcpu_power_off(struct kvm_vcpu *vcpu)
> +void kvm_arm_vcpu_power_off(struct kvm_vcpu *vcpu)
> {
> - vcpu->arch.power_off = true;
> + vcpu->arch.mp_state = KVM_MP_STATE_STOPPED;
> kvm_make_request(KVM_REQ_SLEEP, vcpu);
> kvm_vcpu_kick(vcpu);
> }
>
> +void kvm_arm_vcpu_power_on(struct kvm_vcpu *vcpu)
> +{
> + vcpu->arch.mp_state = KVM_MP_STATE_RUNNABLE;
> + kvm_vcpu_kick(vcpu);
> +}
> +
> int kvm_arch_vcpu_ioctl_get_mpstate(struct kvm_vcpu *vcpu,
> struct kvm_mp_state *mp_state)
> {
> - if (vcpu->arch.power_off)
> - mp_state->mp_state = KVM_MP_STATE_STOPPED;
> - else
> - mp_state->mp_state = KVM_MP_STATE_RUNNABLE;
> -
> + mp_state->mp_state = vcpu->arch.mp_state;
> return 0;
> }
>
> @@ -391,10 +393,10 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
> {
> switch (mp_state->mp_state) {
> case KVM_MP_STATE_RUNNABLE:
> - vcpu->arch.power_off = false;
> + kvm_arm_vcpu_power_on(vcpu);
> break;
> case KVM_MP_STATE_STOPPED:
> - vcpu_power_off(vcpu);
> + kvm_arm_vcpu_power_off(vcpu);
> break;
> default:
> return -EINVAL;
> @@ -405,7 +407,7 @@ int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
>
> static bool vcpu_should_sleep(struct kvm_vcpu *vcpu)
> {
> - return vcpu->arch.power_off || vcpu->arch.pause;
> + return vcpu->arch.mp_state == KVM_MP_STATE_STOPPED || vcpu->arch.pause;
> }
>
> /**
> @@ -919,9 +921,9 @@ static int kvm_arch_vcpu_ioctl_vcpu_init(struct kvm_vcpu *vcpu,
> * Handle the "start in power-off" case.
> */
> if (test_bit(KVM_ARM_VCPU_POWER_OFF, vcpu->arch.features))
> - vcpu_power_off(vcpu);
> + kvm_arm_vcpu_power_off(vcpu);
> else
> - vcpu->arch.power_off = false;
> + kvm_arm_vcpu_power_on(vcpu);
>
> return 0;
> }
> diff --git a/virt/kvm/arm/psci.c b/virt/kvm/arm/psci.c
> index f1e363bab5e8..a7bf152f1247 100644
> --- a/virt/kvm/arm/psci.c
> +++ b/virt/kvm/arm/psci.c
> @@ -64,16 +64,13 @@ static unsigned long kvm_psci_vcpu_suspend(struct kvm_vcpu *vcpu)
>
> static void kvm_psci_vcpu_off(struct kvm_vcpu *vcpu)
> {
> - vcpu->arch.power_off = true;
> - kvm_make_request(KVM_REQ_SLEEP, vcpu);
> - kvm_vcpu_kick(vcpu);
> + kvm_arm_vcpu_power_off(vcpu);
> }
>
> static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> {
> struct kvm *kvm = source_vcpu->kvm;
> struct kvm_vcpu *vcpu = NULL;
> - struct swait_queue_head *wq;
> unsigned long cpu_id;
> unsigned long context_id;
> phys_addr_t target_pc;
> @@ -90,7 +87,7 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> */
> if (!vcpu)
> return PSCI_RET_INVALID_PARAMS;
> - if (!vcpu->arch.power_off) {
> + if (vcpu->arch.mp_state != KVM_MP_STATE_STOPPED) {
Would it make sense to have a new helper to wrap that condition (also
used below)?
> if (kvm_psci_version(source_vcpu) != KVM_ARM_PSCI_0_1)
> return PSCI_RET_ALREADY_ON;
> else
> @@ -118,11 +115,7 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
> * the general puspose registers are undefined upon CPU_ON.
> */
> vcpu_set_reg(vcpu, 0, context_id);
> - vcpu->arch.power_off = false;
> - smp_mb(); /* Make sure the above is visible */
> -
> - wq = kvm_arch_vcpu_wq(vcpu);
> - swake_up(wq);
> + kvm_arm_vcpu_power_on(vcpu);
What guarantees that the mp_state update is now visible to other agents?
Or was the smp_mb() here superfluous? This should anyhow deserve a
mention in the commit message.
>
> return PSCI_RET_SUCCESS;
> }
> @@ -156,7 +149,7 @@ static unsigned long kvm_psci_vcpu_affinity_info(struct kvm_vcpu *vcpu)
> mpidr = kvm_vcpu_get_mpidr_aff(tmp);
> if ((mpidr & target_affinity_mask) == target_affinity) {
> matching_cpus++;
> - if (!tmp->arch.power_off)
> + if (tmp->arch.mp_state != KVM_MP_STATE_STOPPED)
> return PSCI_0_2_AFFINITY_LEVEL_ON;
> }
> }
> @@ -182,7 +175,7 @@ static void kvm_prepare_system_event(struct kvm_vcpu *vcpu, u32 type)
> * re-initialized.
> */
> kvm_for_each_vcpu(i, tmp, vcpu->kvm)
> - tmp->arch.power_off = true;
> + tmp->arch.mp_state = KVM_MP_STATE_STOPPED;
Ah, shame we can't get rid of this with a power_off...
> kvm_make_all_cpus_request(vcpu->kvm, KVM_REQ_SLEEP);
>
> memset(&vcpu->run->system_event, 0, sizeof(vcpu->run->system_event));
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* Patch "iommu/io-pgtable-arm: Check for leaf entry before dereferencing it" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: oleksandr_tyshchenko, alexander.levin, gregkh, robin.murphy,
will.deacon
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iommu/io-pgtable-arm: Check for leaf entry before dereferencing it
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iommu-io-pgtable-arm-check-for-leaf-entry-before-dereferencing-it.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Date: Mon, 27 Feb 2017 14:30:25 +0200
Subject: iommu/io-pgtable-arm: Check for leaf entry before dereferencing it
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
[ Upstream commit ed46e66cc1b3d684042f92dfa2ab15ee917b4cac ]
Do a check for already installed leaf entry at the current level before
dereferencing it in order to avoid walking the page table down with
wrong pointer to the next level.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
CC: Will Deacon <will.deacon@arm.com>
CC: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/io-pgtable-arm.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -335,8 +335,12 @@ static int __arm_lpae_map(struct arm_lpa
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
pte |= ARM_LPAE_PTE_NSTABLE;
__arm_lpae_set_pte(ptep, pte, cfg);
- } else {
+ } else if (!iopte_leaf(pte, lvl)) {
cptep = iopte_deref(pte, data);
+ } else {
+ /* We require an unmap first */
+ WARN_ON(!selftest_running);
+ return -EEXIST;
}
/* Rinse, repeat */
Patches currently in stable-queue which might be from oleksandr_tyshchenko@epam.com are
queue-4.9/iommu-io-pgtable-arm-check-for-leaf-entry-before-dereferencing-it.patch
^ permalink raw reply
* Patch "iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: sricharan, alexander.levin, gregkh, will.deacon; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
iommu-arm-smmu-set-privileged-attribute-to-default-instead-of-unprivileged.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Sricharan R <sricharan@codeaurora.org>
Date: Fri, 6 Jan 2017 18:58:15 +0530
Subject: iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'
From: Sricharan R <sricharan@codeaurora.org>
[ Upstream commit e19898077cfb642fe151ba22981e795c74d9e114 ]
Currently the driver sets all the device transactions privileges
to UNPRIVILEGED, but there are cases where the iommu masters wants
to isolate privileged supervisor and unprivileged user.
So don't override the privileged setting to unprivileged, instead
set it to default as incoming and let it be controlled by the pagetable
settings.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1211,7 +1211,7 @@ static int arm_smmu_domain_add_master(st
continue;
s2cr[idx].type = type;
- s2cr[idx].privcfg = S2CR_PRIVCFG_UNPRIV;
+ s2cr[idx].privcfg = S2CR_PRIVCFG_DEFAULT;
s2cr[idx].cbndx = cbndx;
arm_smmu_write_s2cr(smmu, idx);
}
Patches currently in stable-queue which might be from sricharan@codeaurora.org are
queue-4.9/iommu-arm-smmu-set-privileged-attribute-to-default-instead-of-unprivileged.patch
^ permalink raw reply
* Patch "kasan: do not sanitize kexec purgatory" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: efault, akpm, alexander.levin, aryabinin, dvyukov, glider, gregkh,
torvalds
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
kasan: do not sanitize kexec purgatory
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kasan-do-not-sanitize-kexec-purgatory.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Mike Galbraith <efault@gmx.de>
Date: Fri, 31 Mar 2017 15:12:12 -0700
Subject: kasan: do not sanitize kexec purgatory
From: Mike Galbraith <efault@gmx.de>
[ Upstream commit 13a6798e4a03096b11bf402a063786a7be55d426 ]
Fixes this:
kexec: Undefined symbol: __asan_load8_noabort
kexec-bzImage64: Loading purgatory failed
Link: http://lkml.kernel.org/r/1489672155.4458.7.camel@gmx.de
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/purgatory/Makefile | 1 +
1 file changed, 1 insertion(+)
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -8,6 +8,7 @@ PURGATORY_OBJS = $(addprefix $(obj)/,$(p
LDFLAGS_purgatory.ro := -e purgatory_start -r --no-undefined -nostdlib -z nodefaultlib
targets += purgatory.ro
+KASAN_SANITIZE := n
KCOV_INSTRUMENT := n
# Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That
Patches currently in stable-queue which might be from efault@gmx.de are
queue-4.9/kasan-do-not-sanitize-kexec-purgatory.patch
^ permalink raw reply
* Patch "lkdtm: Fix Oops when unloading the module" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: juerg.haefliger, alexander.levin, gregkh, keescook; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
lkdtm: Fix Oops when unloading the module
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
lkdtm-fix-oops-when-unloading-the-module.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Juerg Haefliger <juerg.haefliger@hpe.com>
Date: Thu, 19 Jan 2017 11:40:13 +0100
Subject: lkdtm: Fix Oops when unloading the module
From: Juerg Haefliger <juerg.haefliger@hpe.com>
[ Upstream commit 9ba60573638e2006170ebcc5489fb1e068afbc8f ]
No jprobe is registered when the module is loaded without specifying a
crashpoint that uses a jprobe. At the moment, we unconditionally try to
unregister the jprobe on module unload which results in an Oops. Add a
check to fix this.
Signed-off-by: Juerg Haefliger <juerg.haefliger@hpe.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/misc/lkdtm_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/misc/lkdtm_core.c
+++ b/drivers/misc/lkdtm_core.c
@@ -533,7 +533,9 @@ static void __exit lkdtm_module_exit(voi
/* Handle test-specific clean-up. */
lkdtm_usercopy_exit();
- unregister_jprobe(lkdtm_jprobe);
+ if (lkdtm_jprobe != NULL)
+ unregister_jprobe(lkdtm_jprobe);
+
pr_info("Crash point unregistered\n");
}
Patches currently in stable-queue which might be from juerg.haefliger@hpe.com are
queue-4.9/lkdtm-fix-oops-when-unloading-the-module.patch
^ permalink raw reply
* Patch "md/raid10: submit bio directly to replacement disk" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: shli, alexander.levin, gregkh, neilb; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
md/raid10: submit bio directly to replacement disk
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
md-raid10-submit-bio-directly-to-replacement-disk.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Shaohua Li <shli@fb.com>
Date: Thu, 23 Feb 2017 12:26:41 -0800
Subject: md/raid10: submit bio directly to replacement disk
From: Shaohua Li <shli@fb.com>
[ Upstream commit 6d399783e9d4e9bd44931501948059d24ad96ff8 ]
Commit 57c67df(md/raid10: submit IO from originating thread instead of
md thread) submits bio directly for normal disks but not for replacement
disks. There is no point we shouldn't do this for replacement disks.
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/md/raid10.c | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -1407,11 +1407,24 @@ retry_write:
mbio->bi_private = r10_bio;
atomic_inc(&r10_bio->remaining);
+
+ cb = blk_check_plugged(raid10_unplug, mddev,
+ sizeof(*plug));
+ if (cb)
+ plug = container_of(cb, struct raid10_plug_cb,
+ cb);
+ else
+ plug = NULL;
spin_lock_irqsave(&conf->device_lock, flags);
- bio_list_add(&conf->pending_bio_list, mbio);
- conf->pending_count++;
+ if (plug) {
+ bio_list_add(&plug->pending, mbio);
+ plug->pending_cnt++;
+ } else {
+ bio_list_add(&conf->pending_bio_list, mbio);
+ conf->pending_count++;
+ }
spin_unlock_irqrestore(&conf->device_lock, flags);
- if (!mddev_check_plugged(mddev))
+ if (!plug)
md_wakeup_thread(mddev->thread);
}
}
Patches currently in stable-queue which might be from shli@fb.com are
queue-4.9/md-raid10-submit-bio-directly-to-replacement-disk.patch
^ permalink raw reply
* Patch "libata: transport: Remove circular dependency at free time" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: gwendal, alexander.levin, gregkh, tedheadster, tj; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
libata: transport: Remove circular dependency at free time
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
libata-transport-remove-circular-dependency-at-free-time.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Gwendal Grignou <gwendal@chromium.org>
Date: Fri, 3 Mar 2017 09:00:09 -0800
Subject: libata: transport: Remove circular dependency at free time
From: Gwendal Grignou <gwendal@chromium.org>
[ Upstream commit d85fc67dd11e9a32966140677d4d6429ca540b25 ]
Without this patch, failed probe would not free resources like irq.
ata port tdev object currently hold a reference to the ata port
object. Therefore the ata port object release function will not get
called until the ata_tport_release is called. But that would never
happen, releasing the last reference of ata port dev is done by
scsi_host_release, which is called by ata_host_release when the ata
port object is released.
The ata device objects actually do not need to explicitly hold a
reference to their real counterpart, given the transport objects are
the children of these objects and device_add() is call for each child.
We know the parent will not be deleted until we call the child's
device_del().
Reported-by: Matthew Whitehead <tedheadster@gmail.com>
Tested-by: Matthew Whitehead <tedheadster@gmail.com>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/ata/libata-transport.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
--- a/drivers/ata/libata-transport.c
+++ b/drivers/ata/libata-transport.c
@@ -224,7 +224,6 @@ static DECLARE_TRANSPORT_CLASS(ata_port_
static void ata_tport_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -284,7 +283,7 @@ int ata_tport_add(struct device *parent,
device_initialize(dev);
dev->type = &ata_port_type;
- dev->parent = get_device(parent);
+ dev->parent = parent;
dev->release = ata_tport_release;
dev_set_name(dev, "ata%d", ap->print_id);
transport_setup_device(dev);
@@ -348,7 +347,6 @@ static DECLARE_TRANSPORT_CLASS(ata_link_
static void ata_tlink_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -410,7 +408,7 @@ int ata_tlink_add(struct ata_link *link)
int error;
device_initialize(dev);
- dev->parent = get_device(&ap->tdev);
+ dev->parent = &ap->tdev;
dev->release = ata_tlink_release;
if (ata_is_host_link(link))
dev_set_name(dev, "link%d", ap->print_id);
@@ -589,7 +587,6 @@ static DECLARE_TRANSPORT_CLASS(ata_dev_c
static void ata_tdev_release(struct device *dev)
{
- put_device(dev->parent);
}
/**
@@ -662,7 +659,7 @@ static int ata_tdev_add(struct ata_devic
int error;
device_initialize(dev);
- dev->parent = get_device(&link->tdev);
+ dev->parent = &link->tdev;
dev->release = ata_tdev_release;
if (ata_is_host_link(link))
dev_set_name(dev, "dev%d.%d", ap->print_id,ata_dev->devno);
Patches currently in stable-queue which might be from gwendal@chromium.org are
queue-4.9/libata-transport-remove-circular-dependency-at-free-time.patch
^ permalink raw reply
* Patch "MIPS: Ensure bss section ends on a long-aligned address" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: paul.burton, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: Ensure bss section ends on a long-aligned address
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-ensure-bss-section-ends-on-a-long-aligned-address.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Paul Burton <paul.burton@imgtec.com>
Date: Mon, 7 Nov 2016 11:52:19 +0000
Subject: MIPS: Ensure bss section ends on a long-aligned address
From: Paul Burton <paul.burton@imgtec.com>
[ Upstream commit 3f00f4d8f083bc61005d0a1ef592b149f5c88bbd ]
When clearing the .bss section in kernel_entry we do so using LONG_S
instructions, and branch whilst the current write address doesn't equal
the end of the .bss section minus the size of a long integer. The .bss
section always begins at a long-aligned address and we always increment
the write pointer by the size of a long integer - we therefore rely upon
the .bss section ending at a long-aligned address. If this is not the
case then the long-aligned write address can never be equal to the
non-long-aligned end address & we will continue to increment past the
end of the .bss section, attempting to zero the rest of memory.
Despite this requirement that .bss end at a long-aligned address we pass
0 as the end alignment requirement to the BSS_SECTION macro and thus
don't guarantee any particular alignment, allowing us to hit the error
condition described above.
Fix this by instead passing 8 bytes as the end alignment argument to
the BSS_SECTION macro, ensuring that the end of the .bss section is
always at least long-aligned.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14526/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/vmlinux.lds.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/kernel/vmlinux.lds.S
+++ b/arch/mips/kernel/vmlinux.lds.S
@@ -182,7 +182,7 @@ SECTIONS
* Force .bss to 64K alignment so that .bss..swapper_pg_dir
* gets that alignment. .sbss should be empty, so there will be
* no holes after __init_end. */
- BSS_SECTION(0, 0x10000, 0)
+ BSS_SECTION(0, 0x10000, 8)
_end = . ;
Patches currently in stable-queue which might be from paul.burton@imgtec.com are
queue-4.9/mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
queue-4.9/mips-smp-cps-fix-retrieval-of-vpe-mask-on-big-endian-cpus.patch
queue-4.9/mips-ensure-bss-section-ends-on-a-long-aligned-address.patch
^ permalink raw reply
* Patch "mips: ath79: clock:- Unmap region obtained by of_iomap" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: arvind.yadav.cs, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
mips: ath79: clock:- Unmap region obtained by of_iomap
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-ath79-clock-unmap-region-obtained-by-of_iomap.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
Date: Mon, 2 Jan 2017 15:18:21 +0530
Subject: mips: ath79: clock:- Unmap region obtained by of_iomap
From: Arvind Yadav <arvind.yadav.cs@gmail.com>
[ Upstream commit b3d91db3f71d5f70ea60d900425a3f96aeb3d065 ]
Free memory mapping, if ath79_clocks_init_dt_ng is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Fixes: 3bdf1071ba7d ("MIPS: ath79: update devicetree clock support for AR9132")
Cc: antonynpavlov@gmail.com
Cc: albeu@free.fr
Cc: hackpascal@gmail.com
Cc: sboyd@codeaurora.org
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14915/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/ath79/clock.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/arch/mips/ath79/clock.c
+++ b/arch/mips/ath79/clock.c
@@ -508,16 +508,19 @@ static void __init ath79_clocks_init_dt_
ar9330_clk_init(ref_clk, pll_base);
else {
pr_err("%s: could not find any appropriate clk_init()\n", dnfn);
- goto err_clk;
+ goto err_iounmap;
}
if (of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data)) {
pr_err("%s: could not register clk provider\n", dnfn);
- goto err_clk;
+ goto err_iounmap;
}
return;
+err_iounmap:
+ iounmap(pll_base);
+
err_clk:
clk_put(ref_clk);
Patches currently in stable-queue which might be from arvind.yadav.cs@gmail.com are
queue-4.9/parisc-perf-fix-potential-null-pointer-dereference.patch
queue-4.9/mips-ath79-clock-unmap-region-obtained-by-of_iomap.patch
^ permalink raw reply
* Re: [PATCH v5 1/9] net/i40e: add API to convert VF MAC to VF id
From: Hunt, David @ 2017-10-05 8:31 UTC (permalink / raw)
To: santosh, dev
Cc: konstantin.ananyev, jingjing.wu, Sexton, Rory, Nemanja Marjanovic
In-Reply-To: <0e15f564-a4f1-cdfd-69bf-b7cb9bc4617c@caviumnetworks.com>
Hi Santosh,
On 4/10/2017 4:41 PM, santosh wrote:
> Hi David,
>
>
> On Wednesday 04 October 2017 08:55 PM, David Hunt wrote:
>> From: "Sexton, Rory" <rory.sexton@intel.com>
>>
>> Need a way to convert a vf id to a pf id on the host so as to query the pf
>> for relevant statistics which are used for the frequency changes in the
>> vm_power_manager app. Used when profiles are passed down from the guest
>> to the host, allowing the host to map the vfs to pfs.
>>
>> Signed-off-by: Nemanja Marjanovic <nemanja.marjanovic@intel.com>
>> Signed-off-by: Rory Sexton <rory.sexton@intel.com>
>> Signed-off-by: David Hunt <david.hunt@intel.com>
>> ---
> I see that you just now sent out v5;)
> But I guess v4 comment on this patch [1]
> is still applicable (imo).
> Thanks.
>
> [1] http://dpdk.org/dev/patchwork/patch/29577/
The v5 went out just as you were commenting on v4. :)
I agree that your comment above needs addressing, I'll do that in v6 today.
Regards.
Dave.
^ permalink raw reply
* Patch "MIPS: fix mem=X@Y commandline processing" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: marcin.nowakowski, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: fix mem=X@Y commandline processing
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-fix-mem-x-y-commandline-processing.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date: Wed, 23 Nov 2016 14:43:49 +0100
Subject: MIPS: fix mem=X@Y commandline processing
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
[ Upstream commit 73fbc1eba7ffa3bf0ad12486232a8a1edb4e4411 ]
When a memory offset is specified through the commandline, add the
memory in range PHYS_OFFSET:Y as reserved memory area.
Otherwise the bootmem allocator is initialised with low page equal to
min_low_pfn = PHYS_OFFSET, and in free_all_bootmem will process pages
starting from min_low_pfn instead of PFN(Y).
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14613/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/setup.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -589,6 +589,10 @@ static int __init early_parse_mem(char *
start = memparse(p + 1, &p);
add_memory_region(start, size, BOOT_MEM_RAM);
+
+ if (start && start > PHYS_OFFSET)
+ add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
+ BOOT_MEM_RESERVED);
return 0;
}
early_param("mem", early_parse_mem);
Patches currently in stable-queue which might be from marcin.nowakowski@imgtec.com are
queue-4.9/mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
queue-4.9/mips-fix-mem-x-y-commandline-processing.patch
queue-4.9/mips-kexec-do-not-reserve-invalid-crashkernel-memory-on-boot.patch
^ permalink raw reply
* Patch "MIPS: kexec: Do not reserve invalid crashkernel memory on boot" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: marcin.nowakowski, alexander.levin, gregkh, ralf; +Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: kexec: Do not reserve invalid crashkernel memory on boot
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-kexec-do-not-reserve-invalid-crashkernel-memory-on-boot.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Date: Wed, 23 Nov 2016 14:43:50 +0100
Subject: MIPS: kexec: Do not reserve invalid crashkernel memory on boot
From: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
[ Upstream commit a8f108d70c74d83574c157648383eb2e4285a190 ]
Do not reserve memory for the crashkernel if the commandline argument
points to a wrong location. This can happen if the location is specified
wrong or if the same commandline is reused when starting the crashkernel
- in the latter case the reserved memory would point to the location
from which the crashkernel is executing.
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14612/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/kernel/setup.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -668,6 +668,11 @@ static void __init mips_parse_crashkerne
if (ret != 0 || crash_size <= 0)
return;
+ if (!memory_region_available(crash_base, crash_size)) {
+ pr_warn("Invalid memory region reserved for crash kernel\n");
+ return;
+ }
+
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
}
Patches currently in stable-queue which might be from marcin.nowakowski@imgtec.com are
queue-4.9/mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
queue-4.9/mips-fix-mem-x-y-commandline-processing.patch
queue-4.9/mips-kexec-do-not-reserve-invalid-crashkernel-memory-on-boot.patch
^ permalink raw reply
* [PATCH] arm: dts: gr-peach: Reduce extal_clk resolution
From: Geert Uytterhoeven @ 2017-10-05 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171005074859.GN4037@w540>
Hi Jacopo,
On Thu, Oct 5, 2017 at 9:48 AM, jacopo mondi <jacopo@jmondi.org> wrote:
> On Wed, Oct 04, 2017 at 05:54:46PM +0200, Geert Uytterhoeven wrote:
>> On Wed, Oct 4, 2017 at 5:40 PM, Jacopo Mondi <jacopo+renesas@jmondi.org> wrote:
>> > The system clock described by extal_clk is reported to have a frequency
>> > of 13.333 Mhz and is correctly described by gr-peach device tree.
>> >
>> > However, when enabling a RIIC device the following error is reported by
>> > drivers/i2c/busses/i2c-riic.c
>> >
>> > "invalid parent clk (33332500). Must be 33325000Hz"
>> >
>> > As RIIC devices have a clock source obtained by dividing by 12 the
>> > system clock, the resulting value is not accepted by the driver
>> > (which clearly states not to support any frequency except the reported
>> > 33325000Hz one).
>> >
>> > Hence, reduce the system clock accuracy to a value which makes
>> > frequencies obtained through division accepted by RIIC driver.
>> >
>> > Please note that other r7s72100 boards, such as Genmai, report the same
>> > "reduced accuracy" frequency, even if their external clock sources are
>> > effectively 13.333Mhz as gr-peach one.
>> >
>> > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
>>
>> There's no need to do this, Chris already proposed a fix, cfr.
>> "[PATCH v2] i2c: riic: remove fixed clock restriction"
>> (https://www.spinics.net/lists/linux-renesas-soc/msg18573.html).
>
> Oh that's even better!
> Do you see any value in augmenting the frequency resolution in Genmai
> DTS then?
The Genmai documentation says EXTAL is 13.33 MHz (which matches
r7s72100-genmai.dts) everywhere, except in the schematics, where it says
13.3333 MHz. Sigh...
The difference is slightly larger than 100 ppm, so still insignificant, I think.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Patch "MIPS: IRQ Stack: Unwind IRQ stack onto task stack" has been added to the 4.9-stable tree
From: gregkh @ 2017-10-05 8:30 UTC (permalink / raw)
To: matt.redfearn, akpm, alexander.levin, cmetcalf, gregkh,
james.hogan, jason, marcin.nowakowski, mingo, paul.burton,
pbonzini, ralf, standby24x7
Cc: stable, stable-commits
This is a note to let you know that I've just added the patch titled
MIPS: IRQ Stack: Unwind IRQ stack onto task stack
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
>From foo@baz Thu Oct 5 10:28:31 CEST 2017
From: Matt Redfearn <matt.redfearn@imgtec.com>
Date: Tue, 21 Mar 2017 14:52:25 +0000
Subject: MIPS: IRQ Stack: Unwind IRQ stack onto task stack
From: Matt Redfearn <matt.redfearn@imgtec.com>
[ Upstream commit db8466c581cca1a08b505f1319c3ecd246f16fa8 ]
When the separate IRQ stack was introduced, stack unwinding only
proceeded as far as the top of the IRQ stack, leading to kernel
backtraces being less useful, lacking the trace of what was interrupted.
Fix this by providing a means for the kernel to unwind the IRQ stack
onto the interrupted task stack. The processor state is saved to the
kernel task stack on interrupt. The IRQ_STACK_START macro reserves an
unsigned long at the top of the IRQ stack where the interrupted task
stack pointer can be saved. After the active stack is switched to the
IRQ stack, save the interrupted tasks stack pointer to the reserved
location.
Fix the stack unwinding code to look for the frame being the top of the
IRQ stack and if so get the next frame from the saved location. The
existing test does not work with the separate stack since the ra is no
longer pointed at ret_from_{irq,exception}.
The test to stop unwinding the stack 32 bytes from the top of a stack
must be modified to allow unwinding to continue up to the location of
the saved task stack pointer when on the IRQ stack. The low / high marks
of the stack are set depending on whether the sp is on an irq stack or
not.
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: Masanari Iida <standby24x7@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jason A. Donenfeld <jason@zx2c4.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/15788/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/include/asm/irq.h | 15 ++++++++++
arch/mips/kernel/asm-offsets.c | 1
arch/mips/kernel/genex.S | 8 ++++-
arch/mips/kernel/process.c | 56 +++++++++++++++++++++++++++--------------
4 files changed, 60 insertions(+), 20 deletions(-)
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -18,9 +18,24 @@
#include <irq.h>
#define IRQ_STACK_SIZE THREAD_SIZE
+#define IRQ_STACK_START (IRQ_STACK_SIZE - sizeof(unsigned long))
extern void *irq_stack[NR_CPUS];
+/*
+ * The highest address on the IRQ stack contains a dummy frame put down in
+ * genex.S (handle_int & except_vec_vi_handler) which is structured as follows:
+ *
+ * top ------------
+ * | task sp | <- irq_stack[cpu] + IRQ_STACK_START
+ * ------------
+ * | | <- First frame of IRQ context
+ * ------------
+ *
+ * task sp holds a copy of the task stack pointer where the struct pt_regs
+ * from exception entry can be found.
+ */
+
static inline bool on_irq_stack(int cpu, unsigned long sp)
{
unsigned long low = (unsigned long)irq_stack[cpu];
--- a/arch/mips/kernel/asm-offsets.c
+++ b/arch/mips/kernel/asm-offsets.c
@@ -103,6 +103,7 @@ void output_thread_info_defines(void)
DEFINE(_THREAD_SIZE, THREAD_SIZE);
DEFINE(_THREAD_MASK, THREAD_MASK);
DEFINE(_IRQ_STACK_SIZE, IRQ_STACK_SIZE);
+ DEFINE(_IRQ_STACK_START, IRQ_STACK_START);
BLANK();
}
--- a/arch/mips/kernel/genex.S
+++ b/arch/mips/kernel/genex.S
@@ -215,9 +215,11 @@ NESTED(handle_int, PT_SIZE, sp)
beq t0, t1, 2f
/* Switch to IRQ stack */
- li t1, _IRQ_STACK_SIZE
+ li t1, _IRQ_STACK_START
PTR_ADD sp, t0, t1
+ /* Save task's sp on IRQ stack so that unwinding can follow it */
+ LONG_S s1, 0(sp)
2:
jal plat_irq_dispatch
@@ -325,9 +327,11 @@ NESTED(except_vec_vi_handler, 0, sp)
beq t0, t1, 2f
/* Switch to IRQ stack */
- li t1, _IRQ_STACK_SIZE
+ li t1, _IRQ_STACK_START
PTR_ADD sp, t0, t1
+ /* Save task's sp on IRQ stack so that unwinding can follow it */
+ LONG_S s1, 0(sp)
2:
jalr v0
--- a/arch/mips/kernel/process.c
+++ b/arch/mips/kernel/process.c
@@ -487,31 +487,52 @@ unsigned long notrace unwind_stack_by_ad
unsigned long pc,
unsigned long *ra)
{
+ unsigned long low, high, irq_stack_high;
struct mips_frame_info info;
unsigned long size, ofs;
+ struct pt_regs *regs;
int leaf;
- extern void ret_from_irq(void);
- extern void ret_from_exception(void);
if (!stack_page)
return 0;
/*
- * If we reached the bottom of interrupt context,
- * return saved pc in pt_regs.
+ * IRQ stacks start at IRQ_STACK_START
+ * task stacks at THREAD_SIZE - 32
*/
- if (pc == (unsigned long)ret_from_irq ||
- pc == (unsigned long)ret_from_exception) {
- struct pt_regs *regs;
- if (*sp >= stack_page &&
- *sp + sizeof(*regs) <= stack_page + THREAD_SIZE - 32) {
- regs = (struct pt_regs *)*sp;
- pc = regs->cp0_epc;
- if (!user_mode(regs) && __kernel_text_address(pc)) {
- *sp = regs->regs[29];
- *ra = regs->regs[31];
- return pc;
- }
+ low = stack_page;
+ if (!preemptible() && on_irq_stack(raw_smp_processor_id(), *sp)) {
+ high = stack_page + IRQ_STACK_START;
+ irq_stack_high = high;
+ } else {
+ high = stack_page + THREAD_SIZE - 32;
+ irq_stack_high = 0;
+ }
+
+ /*
+ * If we reached the top of the interrupt stack, start unwinding
+ * the interrupted task stack.
+ */
+ if (unlikely(*sp == irq_stack_high)) {
+ unsigned long task_sp = *(unsigned long *)*sp;
+
+ /*
+ * Check that the pointer saved in the IRQ stack head points to
+ * something within the stack of the current task
+ */
+ if (!object_is_on_stack((void *)task_sp))
+ return 0;
+
+ /*
+ * Follow pointer to tasks kernel stack frame where interrupted
+ * state was saved.
+ */
+ regs = (struct pt_regs *)task_sp;
+ pc = regs->cp0_epc;
+ if (!user_mode(regs) && __kernel_text_address(pc)) {
+ *sp = regs->regs[29];
+ *ra = regs->regs[31];
+ return pc;
}
return 0;
}
@@ -532,8 +553,7 @@ unsigned long notrace unwind_stack_by_ad
if (leaf < 0)
return 0;
- if (*sp < stack_page ||
- *sp + info.frame_size > stack_page + THREAD_SIZE - 32)
+ if (*sp < low || *sp + info.frame_size > high)
return 0;
if (leaf)
Patches currently in stable-queue which might be from matt.redfearn@imgtec.com are
queue-4.9/mips-irq-stack-unwind-irq-stack-onto-task-stack.patch
queue-4.9/mips-smp-cps-fix-retrieval-of-vpe-mask-on-big-endian-cpus.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.