[PATCH v3 4/7] libsas: add sas event wait-complete support

[Yijing Wang]

Introduce wait-complete for libsas sas event processing,
execute sas port create/destruct in sync.

Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_discover.c | 41 --
 drivers/scsi/libsas/sas_internal.h | 34 +++
 drivers/scsi/libsas/sas_port.c |  4 
 include/scsi/libsas.h  |  5 -
 4 files changed, 72 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..5d4a3a8 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -525,16 +525,43 @@ static void sas_revalidate_domain(struct work_struct 
*work)
mutex_unlock(&ha->disco_mutex);
 }
 
+static const work_func_t sas_event_fns[DISC_NUM_EVENTS] = {
+   [DISCE_DISCOVER_DOMAIN] = sas_discover_domain,
+   [DISCE_REVALIDATE_DOMAIN] = sas_revalidate_domain,
+   [DISCE_PROBE] = sas_probe_devices,
+   [DISCE_SUSPEND] = sas_suspend_devices,
+   [DISCE_RESUME] = sas_resume_devices,
+   [DISCE_DESTRUCT] = sas_destruct_devices,
+};
+
+/* a simple wrapper for sas discover event funtions */
+static void sas_discover_common_fn(struct work_struct *work)
+{
+   struct sas_discovery_event *ev = to_sas_discovery_event(work);
+   struct asd_sas_port *port = ev->port;
+
+   sas_event_fns[ev->type](work);
+   sas_port_put(port);
+}
+
+
 /* -- Events -- */
 
 static void sas_chain_work(struct sas_ha_struct *ha, struct sas_work *sw)
 {
+   int ret;
+   struct sas_discovery_event *ev = to_sas_discovery_event(&sw->work);
+   struct asd_sas_port *port = ev->port;
+
/* chained work is not subject to SA_HA_DRAINING or
 * SAS_HA_REGISTERED, because it is either submitted in the
 * workqueue, or known to be submitted from a context that is
 * not racing against draining
 */
-   scsi_queue_work(ha->core.shost, &sw->work);
+   sas_port_get(port);
+   ret = scsi_queue_work(ha->core.shost, &sw->work);
+   if (ret != 1)
+   sas_port_put(port);
 }
 
 static void sas_chain_event(int event, unsigned long *pending,
@@ -575,18 +602,10 @@ void sas_init_disc(struct sas_discovery *disc, struct 
asd_sas_port *port)
 {
int i;
 
-   static const work_func_t sas_event_fns[DISC_NUM_EVENTS] = {
-   [DISCE_DISCOVER_DOMAIN] = sas_discover_domain,
-   [DISCE_REVALIDATE_DOMAIN] = sas_revalidate_domain,
-   [DISCE_PROBE] = sas_probe_devices,
-   [DISCE_SUSPEND] = sas_suspend_devices,
-   [DISCE_RESUME] = sas_resume_devices,
-   [DISCE_DESTRUCT] = sas_destruct_devices,
-   };
-
disc->pending = 0;
for (i = 0; i < DISC_NUM_EVENTS; i++) {
-   INIT_SAS_WORK(&disc->disc_work[i].work, sas_event_fns[i]);
+   INIT_SAS_WORK(&disc->disc_work[i].work, sas_discover_common_fn);
disc->disc_work[i].port = port;
+   disc->disc_work[i].type = i;
}
 }
diff --git a/drivers/scsi/libsas/sas_internal.h 
b/drivers/scsi/libsas/sas_internal.h
index f03ce64..890b5d26 100644
--- a/drivers/scsi/libsas/sas_internal.h
+++ b/drivers/scsi/libsas/sas_internal.h
@@ -100,6 +100,40 @@ void sas_free_device(struct kref *kref);
 extern const work_func_t sas_phy_event_fns[PHY_NUM_EVENTS];
 extern const work_func_t sas_port_event_fns[PORT_NUM_EVENTS];
 
+static void sas_complete_event(struct kref *kref)
+{
+   struct asd_sas_port *port = container_of(kref, struct asd_sas_port, 
ref);
+
+   complete_all(&port->completion);
+}
+
+static inline void sas_port_put(struct asd_sas_port *port)
+{
+   if (port->is_sync)
+   kref_put(&port->ref, sas_complete_event);
+}
+
+static inline void sas_port_wait_init(struct asd_sas_port *port)
+{
+   init_completion(&port->completion);
+   kref_init(&port->ref);
+   port->is_sync = true;
+}
+
+static inline void sas_port_wait_completion(
+   struct asd_sas_port *port)
+{
+   sas_port_put(port);
+   wait_for_completion(&port->completion);
+   port->is_sync = false;
+}
+
+static inline void sas_port_get(struct asd_sas_port *port)
+{
+   if (port && port->is_sync)
+   kref_get(&port->ref);
+}
+
 #ifdef CONFIG_SCSI_SAS_HOST_SMP
 extern int sas_smp_host_handler(struct Scsi_Host *shost, struct request *req,
struct request *rsp);
diff --git a/drivers/scsi/libsas/sas_port.c b/drivers/scsi/libsas/sas_port.c
index 9326628..d589adb 100644
--- a/drivers/scsi/libsas/sas_port.c
+++ b/drivers/scsi/libsas/sas_port.c
@@ -191,7 +191,9 @@ static void sas_form_port(struct asd_sas_phy *phy)
if (si->dft->lldd_port_formed)
si->dft->lldd_port_formed(phy);
 
+   sas_port_wait_init(port);
   

[PATCH v3 1/7] libsas: Use static sas event pool to appease sas event lost

[Yijing Wang]

Now libsas hotplug work is static, every sas event type has its own
static work, LLDD driver queue the hotplug work into shost->work_q.
If LLDD driver burst post lots hotplug events to libsas, the hotplug
events may pending in the workqueue like

shost->work_q
new work[PORTE_BYTES_DMAED] --> |[PHYE_LOSS_OF_SIGNAL][PORTE_BYTES_DMAED] -> 
processing
|<---wait worker to process>|
In this case, a new PORTE_BYTES_DMAED event coming, libsas try to queue it
to shost->work_q, but this work is already pending, so it would be lost.
Finally, libsas delete the related sas port and sas devices, but LLDD driver
expect libsas add the sas port and devices(last sas event).

This patch and use static sas event work pool to appease this issue, since
it's static work pool, it won't make memory exhaust.

Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_event.c| 208 -
 drivers/scsi/libsas/sas_init.c |   6 --
 drivers/scsi/libsas/sas_internal.h |   3 +
 drivers/scsi/libsas/sas_phy.c  |  48 +++--
 drivers/scsi/libsas/sas_port.c |  18 ++--
 include/scsi/libsas.h  |  16 +--
 6 files changed, 216 insertions(+), 83 deletions(-)

diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index c0d0d97..a1370bd 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -27,13 +27,20 @@
 #include "sas_internal.h"
 #include "sas_dump.h"
 
+static DEFINE_SPINLOCK(sas_event_lock);
+
+static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
+  [HAE_RESET] = sas_hae_reset,
+};
+
 int sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw)
 {
int rc = 0;
 
if (!test_bit(SAS_HA_REGISTERED, &ha->state))
-   return 0;
+   return rc;
 
+   rc = 1;
if (test_bit(SAS_HA_DRAINING, &ha->state)) {
/* add it to the defer list, if not already pending */
if (list_empty(&sw->drain_node))
@@ -44,19 +51,15 @@ int sas_queue_work(struct sas_ha_struct *ha, struct 
sas_work *sw)
return rc;
 }
 
-static int sas_queue_event(int event, unsigned long *pending,
-   struct sas_work *work,
+static int sas_queue_event(int event, struct sas_work *work,
struct sas_ha_struct *ha)
 {
int rc = 0;
+   unsigned long flags;
 
-   if (!test_and_set_bit(event, pending)) {
-   unsigned long flags;
-
-   spin_lock_irqsave(&ha->lock, flags);
-   rc = sas_queue_work(ha, work);
-   spin_unlock_irqrestore(&ha->lock, flags);
-   }
+   spin_lock_irqsave(&ha->lock, flags);
+   rc = sas_queue_work(ha, work);
+   spin_unlock_irqrestore(&ha->lock, flags);
 
return rc;
 }
@@ -64,6 +67,8 @@ static int sas_queue_event(int event, unsigned long *pending,
 
 void __sas_drain_work(struct sas_ha_struct *ha)
 {
+   int ret;
+   unsigned long flags;
struct workqueue_struct *wq = ha->core.shost->work_q;
struct sas_work *sw, *_sw;
 
@@ -78,7 +83,12 @@ void __sas_drain_work(struct sas_ha_struct *ha)
clear_bit(SAS_HA_DRAINING, &ha->state);
list_for_each_entry_safe(sw, _sw, &ha->defer_q, drain_node) {
list_del_init(&sw->drain_node);
-   sas_queue_work(ha, sw);
+   ret = sas_queue_work(ha, sw);
+   if (ret != 1) {
+   spin_lock_irqsave(&sas_event_lock, flags);
+   sw->used = false;
+   spin_unlock_irqrestore(&sas_event_lock, flags);
+   }
}
spin_unlock_irq(&ha->lock);
 }
@@ -119,51 +129,197 @@ void sas_enable_revalidation(struct sas_ha_struct *ha)
if (!test_and_clear_bit(ev, &d->pending))
continue;
 
-   sas_queue_event(ev, &d->pending, &d->disc_work[ev].work, ha);
+   sas_queue_event(ev, &d->disc_work[ev].work, ha);
}
mutex_unlock(&ha->disco_mutex);
 }
 
+static void sas_free_ha_event(struct sas_ha_event *event)
+{
+   unsigned long flags;
+   spin_lock_irqsave(&sas_event_lock, flags);
+   event->work.used = false;
+   spin_unlock_irqrestore(&sas_event_lock, flags);
+}
+
+static void sas_free_port_event(struct asd_sas_event *event)
+{
+   unsigned long flags;
+   spin_lock_irqsave(&sas_event_lock, flags);
+   event->work.used = false;
+   spin_unlock_irqrestore(&sas_event_lock, flags);
+}
+
+static void sas_free_phy_event(struct asd_sas_event *event)
+{
+   unsigned long flags;
+   spin_lock_irqsave(&sas_event_lock, flags);
+   event->work.used = false;
+   spin_unlock_irqrestore(&sas_event_lock, flags);
+}
+
+static void sas_ha_event_worker(struct work_struct *work)
+{
+   struc

[PATCH v3 6/7] libsas: add wait-complete support to sync discovery event

[Yijing Wang]

Introduce a sync flag to tag discovery event whether need to
sync execute, per-event wait-complete ensure sync.

Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_discover.c |  8 ++--
 drivers/scsi/libsas/sas_expander.c | 12 +++-
 drivers/scsi/libsas/sas_internal.h | 27 +++
 include/scsi/libsas.h  |  2 ++
 4 files changed, 46 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index a25d648..d68f8dd 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -378,6 +378,7 @@ void sas_unregister_dev(struct asd_sas_port *port, struct 
domain_device *dev)
list_del_init(&dev->disco_list_node);
sas_rphy_free(dev->rphy);
sas_unregister_common_dev(port, dev);
+   sas_disc_cancel_sync(&port->disc.disc_work[DISCE_DESTRUCT]);
return;
}
 
@@ -541,6 +542,7 @@ static void sas_discover_common_fn(struct work_struct *work)
struct asd_sas_port *port = ev->port;
 
sas_event_fns[ev->type](work);
+   sas_disc_wakeup(ev);
sas_port_put(port);
 }
 
@@ -571,8 +573,10 @@ static void sas_chain_work(struct sas_ha_struct *ha, 
struct sas_work *sw)
else
ret = scsi_queue_work(ha->core.shost, &sw->work);
 
-   if (ret != 1)
+   if (ret != 1) {
sas_port_put(port);
+   sas_disc_cancel_sync(ev);
+   }
 }
 
 static void sas_chain_event(int event, unsigned long *pending,
@@ -592,9 +596,9 @@ int sas_discover_event(struct asd_sas_port *port, enum 
discover_event ev)
 {
struct sas_discovery *disc;
 
+   disc = &port->disc;
if (!port)
return 0;
-   disc = &port->disc;
 
BUG_ON(ev >= DISC_NUM_EVENTS);
 
diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 570b2cb..9d26c28 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -822,14 +822,18 @@ static struct domain_device *sas_ex_discover_end_dev(
 
list_add_tail(&child->disco_list_node, 
&parent->port->disco_list);
 
+   sas_disc_wait_init(child->port, DISCE_PROBE);
res = sas_discover_sata(child);
if (res) {
+   
sas_disc_cancel_sync(&child->port->disc.disc_work[DISCE_PROBE]);
SAS_DPRINTK("sas_discover_sata() for device %16llx at "
"%016llx:0x%x returned 0x%x\n",
SAS_ADDR(child->sas_addr),
SAS_ADDR(parent->sas_addr), phy_id, res);
goto out_list_del;
}
+   sas_disc_wait_completion(child->port, DISCE_PROBE);
+
} else
 #endif
  if (phy->attached_tproto & SAS_PROTOCOL_SSP) {
@@ -847,14 +851,17 @@ static struct domain_device *sas_ex_discover_end_dev(
 
list_add_tail(&child->disco_list_node, 
&parent->port->disco_list);
 
+   sas_disc_wait_init(child->port, DISCE_PROBE);
res = sas_discover_end_dev(child);
if (res) {
+   
sas_disc_cancel_sync(&child->port->disc.disc_work[DISCE_PROBE]);
SAS_DPRINTK("sas_discover_end_dev() for device %16llx "
"at %016llx:0x%x returned 0x%x\n",
SAS_ADDR(child->sas_addr),
SAS_ADDR(parent->sas_addr), phy_id, res);
goto out_list_del;
}
+   sas_disc_wait_completion(child->port, DISCE_PROBE);
} else {
SAS_DPRINTK("target proto 0x%x at %016llx:0x%x not handled\n",
phy->attached_tproto, SAS_ADDR(parent->sas_addr),
@@ -1890,8 +1897,11 @@ static void sas_unregister_devs_sas_addr(struct 
domain_device *parent,
if (child->dev_type == SAS_EDGE_EXPANDER_DEVICE 
||
child->dev_type == 
SAS_FANOUT_EXPANDER_DEVICE)
sas_unregister_ex_tree(parent->port, 
child);
-   else
+   else {
+   sas_disc_wait_init(parent->port, 
DISCE_DESTRUCT);
sas_unregister_dev(parent->port, child);
+   sas_disc_wait_completion(parent->port, 
DISCE_DESTRUCT);
+   }
found = child;
break;
}
diff --git a/drivers/scsi/libsas/sas_internal.h 
b/drivers/scsi/libsas/sas_internal.h
index 890b5d26..0

[PATCH v3 0/7] Enhance libsas hotplug feature

[Yijing Wang]

This patchset is based Johannes's patch
"scsi: sas: scsi_queue_work can fail, so make callers aware"

Now the libsas hotplug has some issues, Dan Williams report
a similar bug here before
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html

The issues we have found
1. if LLDD burst reports lots of phy-up/phy-down sas events, some events
   may lost because a same sas events is pending now, finally libsas topo
   may different the hardware.
2. receive a phy down sas event, libsas call sas_deform_port to remove
   devices, it would first delete the sas port, then put a destruction
   discovery event in a new work, and queue it at the tail of workqueue,
   once the sas port be deleted, its children device will be deleted too,
   when the destruction work start, it will found the target device has
   been removed, and report a sysfs warnning.
3. since a hotplug process will be devided into several works, if a phy up
   sas event insert into phydown works, like
   destruction work  ---> PORTE_BYTES_DMAED (sas_form_port) 
>PHYE_LOSS_OF_SIGNAL
   the hot remove flow would broken by PORTE_BYTES_DMAED event, it's not
   we expected, and issues would occur.

The first patch fix the sas events lost, and the second one introudce 
wait-complete
to fix the hotplug order issues.

v2->v3: some code improvements suggested by Johannes and John,
split v2 patch 2 into several small pathes.
v1->v2: some code improvements suggested by John Garry

Yijing Wang (7):
  libsas: Use static sas event pool to appease sas event lost
  libsas: remove unused port_gone_completion
  libsas: Use new workqueue to run sas event
  libsas: add sas event wait-complete support
  libsas: add a new workqueue to run probe/destruct discovery event
  libsas: add wait-complete support to sync discovery event
  libsas: release disco mutex during waiting in sas_ex_discover_end_dev

 drivers/scsi/libsas/sas_discover.c |  58 +++---
 drivers/scsi/libsas/sas_event.c| 212 -
 drivers/scsi/libsas/sas_expander.c |  22 +++-
 drivers/scsi/libsas/sas_init.c |  21 ++--
 drivers/scsi/libsas/sas_internal.h |  64 +++
 drivers/scsi/libsas/sas_phy.c  |  48 +++--
 drivers/scsi/libsas/sas_port.c |  22 ++--
 include/scsi/libsas.h  |  27 +++--
 8 files changed, 373 insertions(+), 101 deletions(-)

-- 
2.5.0

[PATCH v3 7/7] libsas: release disco mutex during waiting in sas_ex_discover_end_dev

[Yijing Wang]

Disco mutex was introudced to prevent domain rediscovery competing
with ata error handling(87c8331). If we have already hold the lock
in sas_revalidate_domain and sync executing probe, deadlock caused,
because, sas_probe_sata() also need hold disco_mutex. Since disco mutex
use to prevent revalidata domain happen during ata error handler,
it should be safe to release disco mutex when sync probe, because
no new revalidate domain event would be process until the sync return,
and the current sas revalidate domain finish.

Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_expander.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/scsi/libsas/sas_expander.c 
b/drivers/scsi/libsas/sas_expander.c
index 9d26c28..077024e 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -776,6 +776,7 @@ static struct domain_device *sas_ex_discover_end_dev(
struct ex_phy *phy = &parent_ex->ex_phy[phy_id];
struct domain_device *child = NULL;
struct sas_rphy *rphy;
+   bool prev_lock;
int res;
 
if (phy->attached_sata_host || phy->attached_sata_ps)
@@ -803,6 +804,7 @@ static struct domain_device *sas_ex_discover_end_dev(
sas_ex_get_linkrate(parent, child, phy);
sas_device_set_phy(child, phy->port);
 
+   prev_lock = mutex_is_locked(&child->port->ha->disco_mutex);
 #ifdef CONFIG_SCSI_SAS_ATA
if ((phy->attached_tproto & SAS_PROTOCOL_STP) || 
phy->attached_sata_dev) {
res = sas_get_ata_info(child, phy);
@@ -832,7 +834,11 @@ static struct domain_device *sas_ex_discover_end_dev(
SAS_ADDR(parent->sas_addr), phy_id, res);
goto out_list_del;
}
+   if (prev_lock)
+   mutex_unlock(&child->port->ha->disco_mutex);
sas_disc_wait_completion(child->port, DISCE_PROBE);
+   if (prev_lock)
+   mutex_lock(&child->port->ha->disco_mutex);
 
} else
 #endif
@@ -861,7 +867,11 @@ static struct domain_device *sas_ex_discover_end_dev(
SAS_ADDR(parent->sas_addr), phy_id, res);
goto out_list_del;
}
+   if (prev_lock)
+   mutex_unlock(&child->port->ha->disco_mutex);
sas_disc_wait_completion(child->port, DISCE_PROBE);
+   if (prev_lock)
+   mutex_lock(&child->port->ha->disco_mutex);
} else {
SAS_DPRINTK("target proto 0x%x at %016llx:0x%x not handled\n",
phy->attached_tproto, SAS_ADDR(parent->sas_addr),
-- 
2.5.0

[PATCH v3 5/7] libsas: add a new workqueue to run probe/destruct discovery event

[Yijing Wang]

Sometimes, we want sync libsas probe or destruct in sas discovery work,
like when libsas revalidate domain. We need to split probe and destruct
work from the scsi host workqueue.

Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_discover.c | 13 -
 drivers/scsi/libsas/sas_init.c |  8 
 include/scsi/libsas.h  |  1 +
 3 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 5d4a3a8..a25d648 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -559,7 +559,18 @@ static void sas_chain_work(struct sas_ha_struct *ha, 
struct sas_work *sw)
 * not racing against draining
 */
sas_port_get(port);
-   ret = scsi_queue_work(ha->core.shost, &sw->work);
+   /*
+* discovery event probe and destruct would be called in other
+* discovery event like discover domain and revalidate domain
+* events, in some cases, we need to sync execute probe and destruct
+* events, so run probe and destruct discover events except in a new
+* workqueue.
+*/
+   if (ev->type == DISCE_PROBE || ev->type == DISCE_DESTRUCT)
+   ret = queue_work(ha->disc_q, &sw->work);
+   else
+   ret = scsi_queue_work(ha->core.shost, &sw->work);
+
if (ret != 1)
sas_port_put(port);
 }
diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
index 2f3b736..df1d78b 100644
--- a/drivers/scsi/libsas/sas_init.c
+++ b/drivers/scsi/libsas/sas_init.c
@@ -152,6 +152,13 @@ int sas_register_ha(struct sas_ha_struct *sas_ha)
if (!sas_ha->event_q)
goto Undo_ports;
 
+   snprintf(name, 64, "%s_disc_q", dev_name(sas_ha->dev));
+   sas_ha->disc_q = create_singlethread_workqueue(name);
+   if(!sas_ha->disc_q) {
+   destroy_workqueue(sas_ha->event_q);
+   goto Undo_ports;
+   }
+
INIT_LIST_HEAD(&sas_ha->eh_done_q);
INIT_LIST_HEAD(&sas_ha->eh_ata_q);
 
@@ -187,6 +194,7 @@ int sas_unregister_ha(struct sas_ha_struct *sas_ha)
__sas_drain_work(sas_ha);
mutex_unlock(&sas_ha->drain_mutex);
destroy_workqueue(sas_ha->event_q);
+   destroy_workqueue(sas_ha->disc_q);
 
return 0;
 }
diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
index c2ef05e..4bcb9fe 100644
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -406,6 +406,7 @@ struct sas_ha_struct {
struct device *dev;   /* should be set */
struct module *lldd_module; /* should be set */
struct workqueue_struct *event_q;
+   struct workqueue_struct *disc_q;
 
u8 *sas_addr; /* must be set */
u8 hashed_sas_addr[HASHED_SAS_ADDR_SIZE];
-- 
2.5.0

[PATCH v3 2/7] libsas: remove unused port_gone_completion

[Yijing Wang]

No one uses the port_gone_completion in struct asd_sas_port,
clean it out.

Signed-off-by: Yijing Wang 
---
 include/scsi/libsas.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
index c41328d..628f48b 100644
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -263,8 +263,6 @@ struct sas_discovery {
 /* The port struct is Class:RW, driver:RO */
 struct asd_sas_port {
 /* private: */
-   struct completion port_gone_completion;
-
struct sas_discovery disc;
struct domain_device *port_dev;
spinlock_t dev_list_lock;
-- 
2.5.0

[PATCH v3 3/7] libsas: Use new workqueue to run sas event

[Yijing Wang]

Now all libsas works are queued to scsi host workqueue,
include sas event work post by LLDD and sas discovery
work, and a sas hotplug flow may be divided into several
works, e.g libsas receive a PORTE_BYTES_DMAED event,
now we process it as following steps:
sas_form_port  --- run in work in shot workq
sas_discover_domain  --- run in another work in shost workq
...
sas_probe_devices  --- run in new work in shost workq
We found during hot-add a device, libsas may need run several
works in same workqueue to add device in system, the process is
not atomic, it may interrupt by other sas event works, like
PHYE_LOSS_OF_SIGNAL. Finally, we would found lots unexpected
errors. This patch is preparation of execute libsas sas event
in sync.

Signed-off-by: Yijing Wang 
CC: John Garry 
CC: Johannes Thumshirn 
CC: Ewan Milne 
CC: Christoph Hellwig 
CC: Tomas Henzl 
CC: Dan Williams 
---
 drivers/scsi/libsas/sas_event.c | 4 ++--
 drivers/scsi/libsas/sas_init.c  | 7 +++
 include/scsi/libsas.h   | 1 +
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index a1370bd..a72a089 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -46,7 +46,7 @@ int sas_queue_work(struct sas_ha_struct *ha, struct sas_work 
*sw)
if (list_empty(&sw->drain_node))
list_add(&sw->drain_node, &ha->defer_q);
} else
-   rc = scsi_queue_work(ha->core.shost, &sw->work);
+   rc = queue_work(ha->event_q, &sw->work);
 
return rc;
 }
@@ -69,7 +69,7 @@ void __sas_drain_work(struct sas_ha_struct *ha)
 {
int ret;
unsigned long flags;
-   struct workqueue_struct *wq = ha->core.shost->work_q;
+   struct workqueue_struct *wq = ha->event_q;
struct sas_work *sw, *_sw;
 
set_bit(SAS_HA_DRAINING, &ha->state);
diff --git a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
index c227a8b..2f3b736 100644
--- a/drivers/scsi/libsas/sas_init.c
+++ b/drivers/scsi/libsas/sas_init.c
@@ -115,6 +115,7 @@ void sas_hae_reset(struct work_struct *work)
 
 int sas_register_ha(struct sas_ha_struct *sas_ha)
 {
+   char name[64];
int error = 0;
 
mutex_init(&sas_ha->disco_mutex);
@@ -146,6 +147,11 @@ int sas_register_ha(struct sas_ha_struct *sas_ha)
goto Undo_ports;
}
 
+   snprintf(name, 64, "%s_event_q", dev_name(sas_ha->dev));
+   sas_ha->event_q = create_singlethread_workqueue(name);
+   if (!sas_ha->event_q)
+   goto Undo_ports;
+
INIT_LIST_HEAD(&sas_ha->eh_done_q);
INIT_LIST_HEAD(&sas_ha->eh_ata_q);
 
@@ -180,6 +186,7 @@ int sas_unregister_ha(struct sas_ha_struct *sas_ha)
mutex_lock(&sas_ha->drain_mutex);
__sas_drain_work(sas_ha);
mutex_unlock(&sas_ha->drain_mutex);
+   destroy_workqueue(sas_ha->event_q);
 
return 0;
 }
diff --git a/include/scsi/libsas.h b/include/scsi/libsas.h
index 628f48b..a01ca42 100644
--- a/include/scsi/libsas.h
+++ b/include/scsi/libsas.h
@@ -402,6 +402,7 @@ struct sas_ha_struct {
char *sas_ha_name;
struct device *dev;   /* should be set */
struct module *lldd_module; /* should be set */
+   struct workqueue_struct *event_q;
 
u8 *sas_addr; /* must be set */
u8 hashed_sas_addr[HASHED_SAS_ADDR_SIZE];
-- 
2.5.0

Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

[Viresh Kumar]

On 05-07-17, 09:59, Juri Lelli wrote:
> To be able to treat utilization signals of different scheduling classes
> in different ways (e.g., CFS signal might be stale while DEADLINE signal
> is never stale by design) we need to split sugov_cpu::util signal in two:
> util_cfs and util_dl.
> 
> This patch does that by also changing sugov_get_util() parameter list.
> After this change, aggregation of the different signals has to be performed
> by sugov_get_util() users (so that they can decide what to do with the
> different signals).
> 
> Suggested-by: Rafael J. Wysocki 
> Signed-off-by: Juri Lelli 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Rafael J. Wysocki 
> Cc: Viresh Kumar 
> Cc: Luca Abeni 
> Cc: Claudio Scordino 
> ---
> Changes from RFCv0:
> 
>  - refactor aggregation of utilization in sugov_aggregate_util()
> ---
>  kernel/sched/cpufreq_schedutil.c | 28 
>  1 file changed, 16 insertions(+), 12 deletions(-)

Acked-by: Viresh Kumar 

-- 
viresh

RE: [PATCH 00/17] v3 net generic subsystem refcount conversions

[Reshetova, Elena]

> On Mon, Jul 03, 2017 at 02:28:56AM -0700, Eric Dumazet wrote:
> >On Fri, 2017-06-30 at 13:07 +0300, Elena Reshetova wrote:
> >> Changes in v3:
> >> Rebased on top of the net-next tree.
> >>
> >> Changes in v2:
> >> No changes in patches apart from rebases, but now by
> >> default refcount_t = atomic_t (*) and uses all atomic standard operations
> >> unless CONFIG_REFCOUNT_FULL is enabled. This is a compromise for the
> >> systems that are critical on performance (such as net) and cannot accept 
> >> even
> >> slight delay on the refcounter operations.
> >>
> >> This series, for core network subsystem components, replaces atomic_t
> reference
> >> counters with the new refcount_t type and API (see
> include/linux/refcount.h).
> >> By doing this we prevent intentional or accidental
> >> underflows or overflows that can led to use-after-free vulnerabilities.
> >> These patches contain only generic net pieces. Other changes will be sent
> separately.
> >>
> >> The patches are fully independent and can be cherry-picked separately.
> >> The big patches, such as conversions for sock structure, need a very 
> >> detailed
> >> look from maintainers: refcount managing is quite complex in them and while
> >> it seems that they would benefit from the change, extra checking is needed.
> >> The biggest corner issue is the fact that refcount_inc() does not increment
> >> from zero.
> >>
> >> If there are no objections to the patches, please merge them via respective
> trees.
> >>
> >> * The respective change is currently merged into -next as
> >>   "locking/refcount: Create unchecked atomic_t implementation".
> >>
> >> Elena Reshetova (17):
> >>   net: convert inet_peer.refcnt from atomic_t to refcount_t
> >>   net: convert neighbour.refcnt from atomic_t to refcount_t
> >>   net: convert neigh_params.refcnt from atomic_t to refcount_t
> >>   net: convert nf_bridge_info.use from atomic_t to refcount_t
> >>   net: convert sk_buff.users from atomic_t to refcount_t
> >>   net: convert sk_buff_fclones.fclone_ref from atomic_t to refcount_t
> >>   net: convert sock.sk_wmem_alloc from atomic_t to refcount_t
> >>   net: convert sock.sk_refcnt from atomic_t to refcount_t
> >>   net: convert ip_mc_list.refcnt from atomic_t to refcount_t
> >>   net: convert in_device.refcnt from atomic_t to refcount_t
> >>   net: convert netpoll_info.refcnt from atomic_t to refcount_t
> >>   net: convert unix_address.refcnt from atomic_t to refcount_t
> >>   net: convert fib_rule.refcnt from atomic_t to refcount_t
> >>   net: convert inet_frag_queue.refcnt from atomic_t to refcount_t
> >>   net: convert net.passive from atomic_t to refcount_t
> >>   net: convert netlbl_lsm_cache.refcount from atomic_t to refcount_t
> >>   net: convert packet_fanout.sk_ref from atomic_t to refcount_t
> >
> >
> >Can you take a look at this please ?
> >
> >[   64.601749] [ cut here ]
> >[   64.601757] WARNING: CPU: 0 PID: 6476 at lib/refcount.c:184
> refcount_sub_and_test+0x75/0xa0
> >[   64.601758] Modules linked in: w1_therm wire cdc_acm ehci_pci ehci_hcd
> mlx4_en ib_uverbs mlx4_ib ib_core mlx4_core
> >[   64.601769] CPU: 0 PID: 6476 Comm: ip Tainted: GW   
> >4.12.0-smp-DEV
> #274
> >[   64.601770] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.40.0
> 06/22/2016
> >[   64.601771] task: 8837bf482040 task.stack: 8837bdc08000
> >[   64.601773] RIP: 0010:refcount_sub_and_test+0x75/0xa0
> >[   64.601774] RSP: 0018:8837bdc0f5c0 EFLAGS: 00010286
> >[   64.601776] RAX: 0026 RBX: 0001 RCX:
> 
> >[   64.601777] RDX: 0026 RSI: 0096 RDI:
> ed06f7b81eae
> >[   64.601778] RBP: 8837bdc0f5d0 R08: 0004 R09:
> fbfff4a54c25
> >[   64.601779] R10: cbc500e5 R11: a52a6128 R12: 
> >881febcf6f24
> >[   64.601779] R13: 881fbf4eaf00 R14: 881febcf6f80 R15: 
> >8837d7a4ed00
> >[   64.601781] FS:  7ff5a2f6b700() GS:881fff80()
> knlGS:
> >[   64.601782] CS:  0010 DS:  ES:  CR0: 80050033
> >[   64.601783] CR2: 7ffcdc70d000 CR3: 001f9c91e000 CR4:
> 001406f0
> >[   64.601783] Call Trace:
> >[   64.601786]  refcount_dec_and_test+0x11/0x20
> >[   64.601790]  fib_nl_delrule+0xc39/0x1630
> [snip]
> 
> I'm seeing a similar one coming from sctp:
> 
> refcount_t: underflow; use-after-free.
> [ cut here ]
> WARNING: CPU: 3 PID: 15570 at lib/refcount.c:186
> refcount_sub_and_test.cold.13+0x18/0x21 lib/refcount.c:186
> Kernel panic - not syncing: panic_on_warn set ...
> 
> CPU: 3 PID: 15570 Comm: syz-executor0 Not tainted 4.12.0-next-20170706+ #186
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.1-1ubuntu1
> 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:16 [inline]
>  dump_stack+0x11d/0x1ef lib/dump_stack.c:52
>  panic+0x1bc/0x3ad kernel/panic.c:180
>  __warn.cold.6+0x2f/0x2f kernel/panic.c:541
>  report_bug+0x20d/0x2

Re: [PATCH] kernel: cpu: hotplug: constify attribute_group structures.

[Sebastian Andrzej Siewior]

On 2017-06-29 17:40:47 [+0530], Arvind Yadav wrote:
> attribute_groups are not supposed to change at runtime. All functions
> working with attribute_groups provided by  work with const
> attribute_group. So mark the non-const structs as const.
> 
> File size before:
>text  data bss dec hex filename
>   12582 15361  20   279636d3b kernel/cpu.o
> 
> File size After adding 'const':
>text  data bss dec hex filename
>   12710 15265  20   279956d5b kernel/cpu.o

While there does not seem to be anything wrong with it, why did the file
grow after the patch was applied?

> Signed-off-by: Arvind Yadav 

Sebastian

Re: [PATCH] drm: inhibit drm drivers register to uninitialized drm core

[Alexandru Moise]

On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote:
> On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote:
> > If the DRM core fails to init for whatever reason, ensure that
> > no driver ever calls drm_dev_register().
> > 
> > This is best done at drm_dev_init() as it covers drivers that call
> > drm_dev_alloc() as well as drivers that prefer to embed struct
> > drm_device into their own device struct and call drm_dev_init()
> > themselves.
> > 
> > In my case I had so many dynamic device majors used that the major
> > number for DRM (226) was stolen, causing DRM core init to fail after
> > failing to register a chrdev, and ultimately calling debugfs_remove()
> > on drm_debugfs_root in drm_core_exit().
> > 
> > After drm core failed to init, VGEM was still calling drm_dev_register(),
> > ultimately leading to drm_debugfs_init(), with drm_debugfs_root passed
> > as the root for the new debugfs dir at debugfs_create_dir().
> > 
> > This led to a kernel panic once we were either derefencing root->d_inode
> > while it was NULL or calling root->d_inode->i_op->lookup() while it was
> > NULL in debugfs at inode_lock() or lookup_*().
> > 
> > Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
> > ---
> >  drivers/gpu/drm/drm_drv.c | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 37b8ad3e30d8..2ed2d919beae 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -63,6 +63,15 @@ module_param_named(debug, drm_debug, int, 0600);
> >  static DEFINE_SPINLOCK(drm_minor_lock);
> >  static struct idr drm_minors_idr;
> >  
> > +/*
> > + * If the drm core fails to init for whatever reason,
> > + * we should prevent any drivers from registering with it.
> > + * It's best to check this at drm_dev_init(), as some drivers
> > + * prefer to embed struct drm_device into their own device
> > + * structure and call drm_dev_init() themselves.
> > + */
> > +static bool drm_core_init_complete = false;
> > +
> >  static struct dentry *drm_debugfs_root;
> >  
> >  #define DRM_PRINTK_FMT "[" DRM_NAME ":%s]%s %pV"
> > @@ -484,6 +493,11 @@ int drm_dev_init(struct drm_device *dev,
> >  {
> > int ret;
> >  
> > +   if (!drm_core_init_complete) {
> > +   DRM_ERROR("DRM core is not initialized\n");
> > +   return -ENODEV;
> > +   }
> > +
> > kref_init(&dev->ref);
> > dev->dev = parent;
> > dev->driver = driver;
> > @@ -966,6 +980,8 @@ static int __init drm_core_init(void)
> > if (ret < 0)
> > goto error;
> >  
> > +   drm_core_init_complete = true;
> > +
> > DRM_DEBUG("Initialized\n");
> > return 0;
> 
> Isn't the correct fix to pass down the error value, which iirc should
> make the kmod stuff unload the module again? Or does this not work'
> -Daniel

What if everything is built in?

../Alex

> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

[PATCH] clocksource/timer-of: checking for NULL instead of IS_ERR()

[Dan Carpenter]

of_io_request_and_map() doesn't return NULL, it returns error pointers.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/clocksource/timer-of.c b/drivers/clocksource/timer-of.c
index f6e7491c873c..f83d52e313d2 100644
--- a/drivers/clocksource/timer-of.c
+++ b/drivers/clocksource/timer-of.c
@@ -120,9 +120,9 @@ static __init int timer_base_init(struct device_node *np,
const char *name = of_base->name ? of_base->name : np->full_name;
 
of_base->base = of_io_request_and_map(np, of_base->index, name);
-   if (!of_base->base) {
+   if (IS_ERR(of_base->base)) {
pr_err("Failed to iomap (%s)\n", name);
-   return -ENXIO;
+   return PTR_ERR(of_base->base);
}
 
return 0;

Re: Problem with commit bf22ff45bed664aefb5c4e43029057a199b7070c

[Juergen Gross]

On 07/07/17 19:11, Thomas Gleixner wrote:
> On Fri, 7 Jul 2017, Thomas Gleixner wrote:
> 
>> On Fri, 7 Jul 2017, Juergen Gross wrote:
>>
>>> Commit bf22ff45bed664aefb5c4e43029057a199b7070c ("genirq: Avoid
>>> unnecessary low level irq function calls") breaks Xen guest
>>> save/restore handling.
>>>
>>> The main problem are the PV devices using Xen event channels as
>>> interrupt sources which are represented as an "irq chip" in the kernel.
>>> When saving the guest the event channels are masked internally. At
>>> restore time event channels are re-established and unmasked via
>>> irq_startup().
> 
> And how exactly gets irq_startup() invoked on those event channels?

[   30.791879] Call Trace:
[   30.791883]  ? irq_get_irq_data+0xe/0x20
[   30.791886]  enable_dynirq+0x23/0x30
[   30.791888]  unmask_irq.part.33+0x26/0x40
[   30.791890]  irq_enable+0x65/0x70
[   30.791891]  irq_startup+0x3c/0x110
[   30.791893]  __enable_irq+0x37/0x60
[   30.791895]  resume_irqs+0xbe/0xe0
[   30.791897]  irq_pm_syscore_resume+0x13/0x20
[   30.791900]  syscore_resume+0x50/0x1b0
[   30.791902]  xen_suspend+0x76/0x140

> 
>>> I have a patch repairing the issue, but I'm not sure if this way to do
>>> it would be accepted. I have exported mask_irq() and I'm doing the
>>> masking now through this function. Would the attached patch be
>>> acceptable? Or is there a better way to solve the problem?
>>
>> Without looking at the patch (too lazy to fiddle with attachments right
>> now), this is definitely wrong. I'll have a look later tonight.
> 
> Not that I'm surprised, but that patch is exactly what I expected. Export a
> random function, which helps to paper over the real problem and run away.
> These functions are internal for a reason and we worked hard on making
> people understand that fiddling with the internals of interrupts is a
> NONO. If there are special requirements for a good reason, then we create
> proper interfaces and infrastructure, if there is no good reason, then the
> problematic code needs to be fixed. There is no exception for XEN.

I'm absolutely on your side here. That was the reason I didn't send
the patch right away, but asked how to solve my issue in a way which
isn't "quick and dirty". The patch was just the easiest way to explain
what should be the result of the proper solution.

> Can you please explain how that save/restore stuff works and which
> functions are involved?

It is based on suspend/resume framework. The main work to be done
additionally is to disconnect from the pv-backends at save time and
connect to the pv-backends again at restore time.

The main function triggering all that is xen_suspend() (as seen in
above backtrace).


Juergen

Re: [PATCH] kernel: cpu: hotplug: constify attribute_group structures.

[Arvind Yadav]

Hi Sebastian,


On Monday 10 July 2017 12:44 PM, Sebastian Andrzej Siewior wrote:

On 2017-06-29 17:40:47 [+0530], Arvind Yadav wrote:

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work with const
attribute_group. So mark the non-const structs as const.

File size before:
text   data bss dec hex filename
   12582  15361  20   279636d3b kernel/cpu.o

File size After adding 'const':
text   data bss dec hex filename
   12710  15265  20   279956d5b kernel/cpu.o

While there does not seem to be anything wrong with it, why did the file
grow after the patch was applied?

Yes, You are right. I have added few more changes for some experiment.
Which is increasing size of file. Sorry for that, Correct comparison
is this.
File size before:
   text   databssdechexfilename
  12909  15361 20  28290   6e82kernel/cpu.o

File size After adding 'const':
   text   databssdechexfilename
  12973  15297 20  28290   6e82kernel/cpu.o

I will send updated patch.

Signed-off-by: Arvind Yadav 

Sebastian

Thanks
~arvind

Re: [PATCH] video: xilinxfb: constify fb_fix_screeninfo and fb_var_screeninfo structures

[Michal Simek]

On 8.7.2017 03:24, Gustavo A. R. Silva wrote:
> These structures are only used to copy into other structures,
> so declare them as const.
> 
> This issue was detected using Coccinelle and the following semantic patch:
> 
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct fb_fix_screeninfo i@p = { ... };
> 
> @ok@
> identifier r.i;
> expression e;
> position p;
> @@
> e = i@p
> 
> @bad@
> position p != {r.p,ok.p};
> identifier r.i;
> struct fb_fix_screeninfo e;
> @@
> e@i@p
> 
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> static
> +const
>  struct fb_fix_screeninfo i = { ... };
> 
> The semantic patch for fb_var_screeninfo is analogous.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/video/fbdev/xilinxfb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/fbdev/xilinxfb.c b/drivers/video/fbdev/xilinxfb.c
> index 17dc119..0bda18e 100644
> --- a/drivers/video/fbdev/xilinxfb.c
> +++ b/drivers/video/fbdev/xilinxfb.c
> @@ -110,14 +110,14 @@ static struct xilinxfb_platform_data 
> xilinx_fb_default_pdata = {
>  /*
>   * Here are the default fb_fix_screeninfo and fb_var_screeninfo structures
>   */
> -static struct fb_fix_screeninfo xilinx_fb_fix = {
> +static const struct fb_fix_screeninfo xilinx_fb_fix = {
>   .id =   "Xilinx",
>   .type = FB_TYPE_PACKED_PIXELS,
>   .visual =   FB_VISUAL_TRUECOLOR,
>   .accel =FB_ACCEL_NONE
>  };
>  
> -static struct fb_var_screeninfo xilinx_fb_var = {
> +static const struct fb_var_screeninfo xilinx_fb_var = {
>   .bits_per_pixel =   BITS_PER_PIXEL,
>  
>   .red =  { RED_SHIFT, 8, 0 },
> 

Acked-by: Michal Simek 

Thanks,
Michal

Re: [PATCH] usb: isp1760: compress return logic into one line

[Oliver Neukum]

Am Sonntag, den 09.07.2017, 21:00 -0500 schrieb  Gustavo A. R. Silva :
> Simplify return logic to avoid unnecessary variable assignment.
> 
> This issue was detected using Coccinelle and the following
> semantic patch:
> 

Hi,

I need to ask: Where is the improvement? The compiler does not bother
and for the human reader you do not do anything obvious and you
decreased grepability.

Regards
Oliver

Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

[Javier Martinez Canillas]

Hello Lee,

On Thu, Jun 15, 2017 at 8:49 PM, Javier Martinez Canillas
 wrote:
>
> This series add OF device ID tables to mfd I2C drivers whose devices are
> either used in Device Tree source files or are listed in binding docs as
> a compatible string.
>
> That's done because the plan is to change the I2C core to report proper OF
> modaliases instead of always reporting a MODALIAS=i2c: regardless if
> a device was registered via DT or using the legacy platform data mechanism.
>
> So these patches will make sure that mfd I2C drivers modules will continue
> to be autoloaded once the I2C core is changed to report proper OF modalias.
>
> Users didn't have a vendor prefix in the used compatible strings, but since
> there wasn't a DT binding document for these drivers, it can be said that
> were working for mere luck and so this series fixes the users and add a DT
> binding doc for the drivers.
>
> Most patches can be applied independently, with the exception of patches
> 2 to 4 that should be applied in the same tree to keep bisect-ability. I
> suggest these to go through the MFD subsystem tree.
>
> Best regards,
> Javier
>

Are you planning to pick this series? It has been in the list for
months and were resent many times...

Best regards,
Javier

Re: [PATCH v2 1/1] mux: mux-core: Add NULL check for dev->of_node

[Peter Rosin]

On 2017-07-09 09:35, Kuppuswamy, Sathyanarayanan wrote:
> Hi,
> 
> 
> On 7/9/2017 12:07 AM, Peter Rosin wrote:
>> On 2017-07-09 01:12, Kuppuswamy, Sathyanarayanan wrote:
>>> Hi Peter,
>>>
>>>
>>> On 7/8/2017 2:00 PM, Peter Rosin wrote:
 On 2017-07-07 23:46, sathyanarayanan.kuppusw...@linux.intel.com wrote:
> From: Kuppuswamy Sathyanarayanan 
> 
>
> If dev->of_node is NULL, then calling mux_control_get()
> function can lead to NULL pointer exception. So adding
> a NULL check for dev->of_node.
>
> Signed-off-by: Kuppuswamy Sathyanarayanan 
> 
 Do you have a driver that might call mux_control_get and not have any
 of_node?
>>> For non-device tree drivers, this case is valid. I hit this issue when I
>>> was working on Intel USB MUX driver.
If not, I don't see the point of this check.
>>> Since this is an API for other consumers, I think its better to have
>>> some sanity checks.
>>>
>>> If a non device tree driver call this API , I think its better to fail
>>> with some error no instead of creating null pointer exception.
>> Is it? When authoring a new driver, and you make some error like this, why
>> is a "nice" error better than a big fat fail? If you get a null deref,
>> you will presumably also get a call stack etc, which will help you find
>> where you made the error, w/o adding a bunch of traces to find out exactly
>> what you did wrong.
> In this case, I think the error can happen even if there is any 
> configuration mismatch in device tree blob. So its not only

No, it cannot happen for any of the existing consumers. And seeing crashes
if the DT blob is faulty isn't unexpected. I'm sure the ways to provoke a
crash in that situation are abundant.

> about API usage in driver. If you think that you need to fail the system 
> if the API is used without proper dt node configuration,
>   then we should use something like BUG or WARN_ON to explicitly mention 
> this dependency.  But I think its better to

But this is something that *cannot* happen unless you add some new code
somewhere else. Why check at all?

> leave this decision to the MUX consumers because there use cases where 
> MUX control can be optional

This is only future-proofing for consumers that does not exist, and does
nothing for the existing code. And the future where this is needed might
never happen.

Still skeptic...

Cheers,
peda

>>
>> So, I'm skeptic...
>>
>> Cheers,
>> peda
>>
 Cheers,
 peda

> ---
>drivers/mux/mux-core.c | 3 +++
>1 file changed, 3 insertions(+)
>
> Changes since v1:
>* Removed dummy new line.
>
> diff --git a/drivers/mux/mux-core.c b/drivers/mux/mux-core.c
> index 90b8995..924c983 100644
> --- a/drivers/mux/mux-core.c
> +++ b/drivers/mux/mux-core.c
> @@ -438,6 +438,9 @@ struct mux_control *mux_control_get(struct device 
> *dev, const char *mux_name)
>   int index = 0;
>   int ret;
>
> + if (!np)
> + return ERR_PTR(-ENODEV);
> +
>   if (mux_name) {
>   index = of_property_match_string(np, 
> "mux-control-names",
>mux_name);
>
> 

Re: [RFC PATCH v1 4/8] sched/cpufreq_schedutil: split utilization signals

[Joel Fernandes]

On Fri, Jul 7, 2017 at 3:59 AM, Juri Lelli  wrote:
[..]
>
>> If yes, then I don't think it was about having separate APIs, but just 
>> storing
>> util_cfs/dl separately.
>>
>> > -static void sugov_get_util(unsigned long *util, unsigned long *max)
>> > +static void sugov_get_util(struct sugov_cpu *sg_cpu)
>> >  {
>> > struct rq *rq = this_rq();
>> > -   unsigned long dl_util = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
>> > -   >> BW_SHIFT;
>> >
>> > -   *max = arch_scale_cpu_capacity(NULL, smp_processor_id());
>> > +   sg_cpu->max = arch_scale_cpu_capacity(NULL, smp_processor_id());
>> > +   sg_cpu->util_cfs = rq->cfs.avg.util_avg;
>> > +   sg_cpu->util_dl = (rq->dl.running_bw * SCHED_CAPACITY_SCALE)
>> > + >> BW_SHIFT;
>> > +}
>> >
>> > +static unsigned long sugov_aggregate_util(struct sugov_cpu *sg_cpu)
>>
>> As Joel already mentioned, I don't think we should create two separate 
>> routines
>> here.
>>
>
> Mmm, it makes retrieving of utilization in sugov_update_shared and
> aggregating values for the domain in sugov_next_freq_shared cleaner,
> IMHO.
>

I agree, thanks.

-Joel

4.13-rc0: stopped booting on Nokia N900

[Pavel Machek]

Hi!

First, I got segfault from make:

: 0: Can't open
scripts/Makefile.build:561: recipe for target
'drivers/iio/imu/st_lsm6dsx' failed
make[3]: *** [drivers/iio/imu/st_lsm6dsx] Segmentation fault (core
dumped)
scripts/Makefile.build:561: recipe for target 'drivers/iio/imu' failed
make[2]: *** [drivers/iio/imu] Error 2
scripts/Makefile.build:561: recipe for target 'drivers/iio' failed
make[1]: *** [drivers/iio] Error 2
make[1]: *** Waiting for unfinished jobs
Makefile:1008: recipe for target 'drivers' failed
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs
pavel@duo:/data/l/linux-n900$ ./mkit

Then compile worked, but it failed to boot. I've now cleaned caches
and am rebuilding to make sure it is not build machine that has
glitches.

No such luck :-(.

I tested linux-next relatively recently, and it worked ok.

af3c8d98508d37541d4bf57f13a984a7f73a328c is broken.
650fc87 worked ok.

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [RESEND PATCH v5 00/16] eeprom: at24: Add OF device ID table

[Javier Martinez Canillas]

Hello Wolfram,

On Thu, Jun 15, 2017 at 8:54 PM, Javier Martinez Canillas
 wrote:
>
> This series is a follow-up to patch [0] that added an OF device ID table
> to the at24 EEPROM driver. As you suggested [1], this version instead of
> adding entries for every used  tuple, only adds a single
> entry for each chip type using the "atmel" vendor as a generic fallback.
>
> The first patch documents in the DT binding what's the correct vendor to
> use and what are the ones that are being deprecated. The second one adds
> the OF device ID table for the at24 driver and the next patches use this
> vendor in the compatible string to each DTS that defines a compatible I2C
> EEPROM device node.
>
> Patches can be applied independently since the DTS changes without driver
> changes are no-op and the OF table won't be used without the DTS changes.
>
> [0]: https://lkml.org/lkml/2017/3/14/589
> [1]: https://lkml.org/lkml/2017/3/15/99
>

Are you planning to pick this series? It has been in the list for
months and were resent many times...

Best regards,
Javier

[PATCH] mm, vmscan: do not loop on too_many_isolated for ever

[Michal Hocko]

From: Michal Hocko 

Tetsuo Handa has reported [1][2][3]that direct reclaimers might get stuck
in too_many_isolated loop basically for ever because the last few pages
on the LRU lists are isolated by the kswapd which is stuck on fs locks
when doing the pageout or slab reclaim. This in turn means that there is
nobody to actually trigger the oom killer and the system is basically
unusable.

too_many_isolated has been introduced by 35cd78156c49 ("vmscan: throttle
direct reclaim when too many pages are isolated already") to prevent
from pre-mature oom killer invocations because back then no reclaim
progress could indeed trigger the OOM killer too early. But since the
oom detection rework 0a0337e0d1d1 ("mm, oom: rework oom detection")
the allocation/reclaim retry loop considers all the reclaimable pages
and throttles the allocation at that layer so we can loosen the direct
reclaim throttling.

Make shrink_inactive_list loop over too_many_isolated bounded and returns
immediately when the situation hasn't resolved after the first sleep.
Replace congestion_wait by a simple schedule_timeout_interruptible because
we are not really waiting on the IO congestion in this path.

Please note that this patch can theoretically cause the OOM killer to
trigger earlier while there are many pages isolated for the reclaim
which makes progress only very slowly. This would be obvious from the oom
report as the number of isolated pages are printed there. If we ever hit
this should_reclaim_retry should consider those numbers in the evaluation
in one way or another.

[1] 
http://lkml.kernel.org/r/201602092349.acg81273.osvtmjqhlof...@i-love.sakura.ne.jp
[2] 
http://lkml.kernel.org/r/201702212335.djb30777.jofmhsftvlq...@i-love.sakura.ne.jp
[3] 
http://lkml.kernel.org/r/201706300914.ceh95859.fmqolvfhjft...@i-love.sakura.ne.jp

Acked-by: Mel Gorman 
Tested-by: Tetsuo Handa 
Signed-off-by: Michal Hocko 
---
Hi,
I am resubmitting this patch previously sent here
http://lkml.kernel.org/r/20170307133057.26182-1-mho...@kernel.org.

Johannes and Rik had some concerns that this could lead to premature
OOM kills. I agree with them that we need a better throttling
mechanism. Until now we didn't give the issue described above a high
priority because it usually required a really insane workload to
trigger. But it seems that the issue can be reproduced also without
having an insane number of competing threads [3].

Moreover, the issue also triggers very often while testing heavy memory
pressure and so prevents further development of hardening of that area
(http://lkml.kernel.org/r/201707061948.icj18763.tvfoqfohmjf...@i-love.sakura.ne.jp).
Tetsuo hasn't seen any negative effect of this patch in his oom stress
tests so I think we should go with this simple patch for now and think
about something more robust long term.

That being said I suggest merging this (after spending the full release
cycle in linux-next) for the time being until we come up with a more
clever solution.

 mm/vmscan.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index c15b2e4c47ca..4ae069060ae5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1713,9 +1713,15 @@ shrink_inactive_list(unsigned long nr_to_scan, struct 
lruvec *lruvec,
int file = is_file_lru(lru);
struct pglist_data *pgdat = lruvec_pgdat(lruvec);
struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat;
+   bool stalled = false;
 
while (unlikely(too_many_isolated(pgdat, file, sc))) {
-   congestion_wait(BLK_RW_ASYNC, HZ/10);
+   if (stalled)
+   return 0;
+
+   /* wait a bit for the reclaimer. */
+   schedule_timeout_interruptible(HZ/10);
+   stalled = true;
 
/* We are about to die and free our memory. Return now. */
if (fatal_signal_pending(current))
-- 
2.11.0

[PATCH] net: usb: qmi_wwan: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  16831 464   0   17295438f drivers/net/usb/qmi_wwan.o

File size After adding 'const':
   textdata bss dec hex filename
  16895 400   0   17295438f drivers/net/usb/qmi_wwan.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/qmi_wwan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 5894e3c..b2ddd5c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -434,7 +434,7 @@ static ssize_t del_mux_store(struct device *d,  struct 
device_attribute *attr, c
NULL,
 };
 
-static struct attribute_group qmi_wwan_sysfs_attr_group = {
+static const struct attribute_group qmi_wwan_sysfs_attr_group = {
.name = "qmi",
.attrs = qmi_wwan_sysfs_attrs,
 };
-- 
1.9.1

Re: [PATCH v4 4/4] x86/boot/KASLR: Restrict kernel to be randomized in mirror regions

[Baoquan He]

Hi Kees,

Do you think the patch as below is OK to you? 

Thanks!

>From 1cec45dc65090f6d17bf3499b8904efc1822082e Mon Sep 17 00:00:00 2001
From: Baoquan He 
Date: Fri, 7 Jul 2017 17:25:41 +0800
Subject: [PATCH v5 4/4] x86/boot/KASLR: Restrict kernel to be randomized in 
mirror
 regions

Kernel text may be located in non-mirror regions (movable zone) when both
address range mirroring feature and KASLR are enabled.

The address range mirroring feature arranges such mirror region into
normal zone and other region into movable zone in order to locate
kernel code and data in mirror region. The physical memory region
whose descriptors in EFI memory map has EFI_MEMORY_MORE_RELIABLE
attribute (bit: 16) are mirrored.

If efi is detected, iterate efi memory map and pick the mirror region to
process for adding candidate of randomization slot. If efi is disabled
or no mirror region found, still process e820 memory map.

Signed-off-by: Baoquan He 
---
v4->v5:
  Change the process_efi_entries() to return bool value to indicate if a
  mirror region is found and has been processed to add slots.

  Move process_efi_entries() into #ifdef CONFIG_EFI section, and also
  make another dummy process_efi_entries() to return false behind #else.

  These are done according to Kees's suggestion.
  
 arch/x86/boot/compressed/kaslr.c | 68 ++--
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 99c7194f7ea6..9059b571eca1 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -37,7 +37,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 /* Macros used by the included decompressor code below. */
 #define STATIC
@@ -558,6 +560,65 @@ static void process_mem_region(struct mem_vector *entry,
}
 }
 
+#ifdef CONFIG_EFI
+/*
+ * Returns true if mirror region found (and must have been processed
+ * for slots adding)
+ */
+static bool process_efi_entries(unsigned long minimum,
+   unsigned long image_size)
+{
+   struct efi_info *e = &boot_params->efi_info;
+   bool efi_mirror_found = false;
+   struct mem_vector region;
+   efi_memory_desc_t *md;
+   unsigned long pmap;
+   char *signature;
+   u32 nr_desc;
+   int i;
+
+   signature = (char *)&boot_params->efi_info.efi_loader_signature;
+   if (strncmp(signature, EFI32_LOADER_SIGNATURE, 4) &&
+   strncmp(signature, EFI64_LOADER_SIGNATURE, 4))
+   return false;
+
+#ifdef CONFIG_X86_32
+   /* Can't handle data above 4GB at this time */
+   if (e->efi_memmap_hi) {
+   warn("Memory map is above 4GB, EFI should be disabled.\n");
+   return false;
+   }
+   pmap =  e->efi_memmap;
+#else
+   pmap = (e->efi_memmap | ((__u64)e->efi_memmap_hi << 32));
+#endif
+
+   nr_desc = e->efi_memmap_size / e->efi_memdesc_size;
+   for (i = 0; i < nr_desc; i++) {
+   md = (efi_memory_desc_t *)(pmap + (i * e->efi_memdesc_size));
+   if (md->attribute & EFI_MEMORY_MORE_RELIABLE) {
+   region.start = md->phys_addr;
+   region.size = md->num_pages << EFI_PAGE_SHIFT;
+   process_mem_region(®ion, minimum, image_size);
+   efi_mirror_found = true;
+
+   if (slot_area_index == MAX_SLOT_AREA) {
+   debug_putstr("Aborted efi scan (slot_areas 
full)!\n");
+   break;
+   }
+   }
+   }
+
+   return efi_mirror_found;
+}
+#else
+static inline bool process_efi_entries(unsigned long minimum,
+  unsigned long image_size)
+{
+   return false;
+}
+#endif
+
 static void process_e820_entries(unsigned long minimum,
 unsigned long image_size)
 {
@@ -586,13 +647,16 @@ static unsigned long find_random_phys_addr(unsigned long 
minimum,
 {
/* Check if we had too many memmaps. */
if (memmap_too_large) {
-   debug_putstr("Aborted e820 scan (more than 4 memmap= args)!\n");
+   debug_putstr("Aborted memory entries scan (more than 4 memmap= 
args)!\n");
return 0;
}
 
/* Make sure minimum is aligned. */
minimum = ALIGN(minimum, CONFIG_PHYSICAL_ALIGN);
 
+   if(process_efi_entries(minimum, image_size))
+   return slots_fetch_random();
+
process_e820_entries(minimum, image_size);
return slots_fetch_random();
 }
@@ -652,7 +716,7 @@ void choose_random_location(unsigned long input,
 */
min_addr = min(*output, 512UL << 20);
 
-   /* Walk e820 and find a random address. */
+   /* Walk available memory entries to find a random address. */
random_addr = find_random_phys_addr(min_addr, output_size);
if (!

[PATCH] net: cdc_ncm: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  13275 928   1   14204377c drivers/net/usb/cdc_ncm.o

File size After adding 'const':
   textdata bss dec hex filename
  13339 864   1   14204377c drivers/net/usb/cdc_ncm.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/usb/cdc_ncm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index d103a1d..b401ba9 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -367,7 +367,7 @@ static DEVICE_ATTR(name, S_IRUGO, cdc_ncm_show_##name, NULL)
NULL,
 };
 
-static struct attribute_group cdc_ncm_sysfs_attr_group = {
+static const struct attribute_group cdc_ncm_sysfs_attr_group = {
.name = "cdc_ncm",
.attrs = cdc_ncm_sysfs_attrs,
 };
-- 
1.9.1

Re: [PATCH/RFC] dma-mapping: Provide dummy set_dma_ops() for NO_DMA=y

[Arnd Bergmann]

On Sun, Jul 9, 2017 at 9:33 PM, Geert Uytterhoeven  wrote:
> Adding a dummy for set_dma_ops() allows to compile (sub)drivers that
> don't actually use the DMA API, but propagate DMA ops configuration to a
> second driver that may or may not use the DMA API.  Of course the second
> driver does have to depend on HAS_DMA if it uses the DMA API.
>
> An example is commit 5567e989198b5a8d ("fsl/fman: propagate dma_ops").
>
> This allows to revert commit 85688d9adf685572 ("fsl/fman: add dependency
> on HAS_DMA").
>
> Signed-off-by: Geert Uytterhoeven 

I can't think of any correct use case for this new helper. IMO a device
driver should never set the dma_map_ops for any device, and we should
instead for the fman driver correctly.

   Arnd

[PATCH 0/2] ARM64: dts: meson-gx: Enable CEC

[Neil Armstrong]

This patchset enables :
 - Support for the AO domain CEC 32k clock
 - AO CEC Controller linked with the HDMI controller all HDMI supported boards

Neil Armstrong (2):
  ARM64: dts: meson-gx: Add PWR and CRT/RTC nodes and adresses
  ARM64: dts: meson-gx: Add AO CEC nodes

 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |  7 +++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi   | 17 -
 arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts  |  7 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi|  7 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi |  6 ++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts|  8 +++-
 .../boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts|  7 +++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts|  7 +++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  |  6 ++
 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |  7 +++
 10 files changed, 77 insertions(+), 2 deletions(-)

-- 
1.9.1

[PATCH 2/2] ARM64: dts: meson-gx: Add AO CEC nodes

[Neil Armstrong]

This patch adds the AO CEC node in all the HDMI enabled boards DTS.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 7 +++
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi   | 6 ++
 arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts  | 7 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi| 7 +++
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 6 ++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts| 8 +++-
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts | 7 +++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts| 7 +++
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi  | 6 ++
 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 7 +++
 10 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index dc478d0..c89010e 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -121,6 +121,13 @@
};
 };
 
+&cec_AO {
+   status = "okay";
+   pinctrl-0 = <&ao_cec_pins>;
+   pinctrl-names = "default";
+   hdmi-phandle = <&hdmi_tx>;
+};
+
 &cvbs_vdac_port {
cvbs_vdac_out: endpoint {
remote-endpoint = <&cvbs_connector_in>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 91a57d4..de73060 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -383,6 +383,12 @@
amlogic,pwr-ctrl = <&pwr_AO>;
};
 
+   cec_AO: cec@100 {
+   compatible = "amlogic,meson-gx-ao-cec";
+   reg = <0x0 0x00100 0x0 0x14>;
+   interrupts = ;
+   };
+
uart_AO: serial@4c0 {
compatible = "amlogic,meson-uart";
reg = <0x0 0x004c0 0x0 0x14>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index a1078b3..9c59c3c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -171,6 +171,13 @@
};
 };
 
+&cec_AO {
+   status = "okay";
+   pinctrl-0 = <&ao_cec_pins>;
+   pinctrl-names = "default";
+   hdmi-phandle = <&hdmi_tx>;
+};
+
 ðmac {
status = "okay";
pinctrl-0 = <ð_rmii_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index d904deb..6a2d984 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -148,6 +148,13 @@
};
 };
 
+&cec_AO {
+   status = "okay";
+   pinctrl-0 = <&ao_cec_pins>;
+   pinctrl-names = "default";
+   hdmi-phandle = <&hdmi_tx>;
+};
+
 &cvbs_vdac_port {
cvbs_vdac_out: endpoint {
remote-endpoint = <&cvbs_connector_in>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 17d3efd..7f14136 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -307,6 +307,12 @@
};
 };
 
+
+&cec_AO {
+   clocks = <&clkc_AO CLKID_AO_CEC_32K>;
+   clock-names = "core";
+};
+
 ðmac {
clocks = <&clkc CLKID_ETH>,
 <&clkc CLKID_FCLK_DIV2>,
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
index 3e0c023..6827f23 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dts
@@ -97,6 +97,13 @@
};
 };
 
+&cec_AO {
+   status = "okay";
+   pinctrl-0 = <&ao_cec_pins>;
+   pinctrl-names = "default";
+   hdmi-phandle = <&hdmi_tx>;
+};
+
 /* P230 has exclusive choice between internal or external PHY */
 ðmac {
pinctrl-0 = <ð_pins>;
@@ -124,7 +131,6 @@
};
 };
 
-
 &hdmi_tx {
status = "okay";
pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
index 6633a5d..4c2ac76 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
@@ -140,6 +140,13 @@
};
 };
 
+&cec_AO {
+   status = "okay";
+   pinctrl-0 = <&ao_cec_pins>;
+   pinctrl-names = "default";
+   hdmi-phandle = <&hdmi_tx>;
+};
+
 &cvbs_vdac_port {
cvbs_vdac_out: endpoint {
remote-endpo

[PATCH 1/2] ARM64: dts: meson-gx: Add PWR and CRT/RTC nodes and adresses

[Neil Armstrong]

The AO 32KHz generation registers are split among multiple registers :
 - The CRT Control
 - The RTC Clock Control
 - The AO Domain PWR Control

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 35b8c88..91a57d4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -367,11 +367,20 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc810 0x0 0x10>;
 
+   pwr_AO: power-control@00c {
+   compatible = "amlogic,gx-pwr-ctrl", "syscon";
+   reg = <0x0 0xc 0x0 0x8>;
+   };
+
clkc_AO: clock-controller@040 {
compatible = "amlogic,gx-aoclkc", 
"amlogic,gxbb-aoclkc";
-   reg = <0x0 0x00040 0x0 0x4>;
+   reg = <0x0 0x00040 0x0 0x4>,
+ <0x0 0x00068 0x0 0x4>,
+ <0x0 0x00094 0x0 0x8>;
+   reg-names = "aoclk", "aocrt", "aortc";
#clock-cells = <1>;
#reset-cells = <1>;
+   amlogic,pwr-ctrl = <&pwr_AO>;
};
 
uart_AO: serial@4c0 {
-- 
1.9.1

[PATCH v2 6/8] exec: Consolidate dumpability logic

[Kees Cook]

Since it's already valid to set dumpability in the early part of
setup_new_exec(), we can consolidate the logic into a single place.
The BINPRM_FLAGS_ENFORCE_NONDUMP is set during would_dump() calls
before setup_new_exec(), so its test is safe to move as well.

Signed-off-by: Kees Cook 
---
 fs/exec.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index d7bda5b60e7b..eeb8323977d1 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1346,10 +1346,12 @@ void setup_new_exec(struct linux_binprm * bprm)
 
current->sas_ss_sp = current->sas_ss_size = 0;
 
-   if (!bprm->secureexec)
-   set_dumpable(current->mm, SUID_DUMP_USER);
-   else
+   /* Figure out dumpability. */
+   if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP ||
+   bprm->secureexec)
set_dumpable(current->mm, suid_dumpable);
+   else
+   set_dumpable(current->mm, SUID_DUMP_USER);
 
arch_setup_new_exec();
perf_event_exec();
@@ -1363,9 +1365,6 @@ void setup_new_exec(struct linux_binprm * bprm)
 
if (bprm->secureexec) {
current->pdeath_signal = 0;
-   } else {
-   if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)
-   set_dumpable(current->mm, suid_dumpable);
}
 
/* An exec changes our domain. We are no longer part of the thread
-- 
2.7.4

[PATCH v2 8/8] exec: Use sane stack rlimit under secureexec

[Kees Cook]

For a secureexec, before memory layout selection has happened, reset the
stack rlimit to something sane to avoid the caller having control over
the resulting layouts.

$ ulimit -s
8192
$ ulimit -s unlimited
$ /bin/sh -c 'ulimit -s'
unlimited
$ sudo /bin/sh -c 'ulimit -s'
8192

Signed-off-by: Kees Cook 
---
 fs/exec.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/fs/exec.c b/fs/exec.c
index e0186db02f90..1e3463854a16 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1343,6 +1343,16 @@ void setup_new_exec(struct linux_binprm * bprm)
 
/* Make sure parent cannot signal privileged process. */
current->pdeath_signal = 0;
+
+   /*
+* For secureexec, reset the stack limit to sane default to
+* avoid bad behavior from the prior rlimits. This has to
+* happen before arch_pick_mmap_layout(), which examines
+* RLIMIT_STACK, but after the point of no return to avoid
+* needing to clean up the change on failure.
+*/
+   if (current->signal->rlim[RLIMIT_STACK].rlim_cur > _STK_LIM)
+   current->signal->rlim[RLIMIT_STACK].rlim_cur = _STK_LIM;
}
 
arch_pick_mmap_layout(current->mm);
-- 
2.7.4

[PATCH v2 0/8] exec: Use sane stack rlimit under secureexec

[Kees Cook]

As discussed with Linus and Andy, we need to reset the stack rlimit
before we do memory layouts when execing a privilege-gaining (e.g.
setuid) program. This moves security_bprm_secureexec() earlier (with
required changes), and then lowers the stack limit when appropriate.

As a side-effect, dumpability and pdeath_signal clearing is expanded
to cover LSM definitions of secureexec (and Smack can drop its special
handler for pdeath_signal clearing).

I'd appreciate some extra eyes on this to make sure this isn't
broken in some special way. I couldn't find anything that _depended_
on security_bprm_secureexec() being called late.

Thanks!

-Kees

v2:
- fix missed current_security() uses in LSMs.
- research/consolidate dumpability setting logic
- research/consolidate pdeath_signal clearing logic
- split up logical steps a little more for easier review (and bisection)
- fix some old broken comments

[PATCH v2 2/8] exec: Move security_bprm_secureexec() earlier

[Kees Cook]

There are several places where exec needs to know if a privilege-gain has
happened. These should be using the results of security_bprm_secureexec()
but it is getting (needlessly) called very late.

Instead, move this earlier in the exec code, to the start of the point
of no return in setup_new_exec(). Here, the new creds have already
been calculated (and stored in bprm->cred), which is normally what
security_bprm_secureexec() wants to examine. Since it's moved earlier,
LSMs hooking bprm_secureexec() need to be adjusted to use the creds in
bprm:

$ git grep LSM_HOOK_INIT.*bprm_secureexec
apparmor/lsm.c:LSM_HOOK_INIT(bprm_secureexec, apparmor_bprm_secureexec),
commoncap.c:   LSM_HOOK_INIT(bprm_secureexec, cap_bprm_secureexec),
selinux/hooks.c:   LSM_HOOK_INIT(bprm_secureexec, selinux_bprm_secureexec),
smack/smack_lsm.c: LSM_HOOK_INIT(bprm_secureexec, smack_bprm_secureexec),

AppArmor does not access creds in apparmor_bprm_secureexec.

Capabilities needed to be adjusted to use bprm creds.

SELinux needed to be adjusted to use bprm creds for the security structure.

Smack needed to be adjusted to use bprm creds for the security structure.

The result of the bprm_secureexec() hook is saved in a new bprm field
"secureexec" so it can be queried later (just AT_SECURE currently).

Signed-off-by: Kees Cook 
---
 fs/binfmt_elf.c| 2 +-
 fs/binfmt_elf_fdpic.c  | 2 +-
 fs/exec.c  | 5 +
 include/linux/binfmts.h| 3 ++-
 include/linux/lsm_hooks.h  | 3 ++-
 security/commoncap.c   | 4 +---
 security/selinux/hooks.c   | 2 +-
 security/smack/smack_lsm.c | 2 +-
 8 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 5075fd5c62c8..7f6ec4dac13d 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -254,7 +254,7 @@ create_elf_tables(struct linux_binprm *bprm, struct elfhdr 
*exec,
NEW_AUX_ENT(AT_EUID, from_kuid_munged(cred->user_ns, cred->euid));
NEW_AUX_ENT(AT_GID, from_kgid_munged(cred->user_ns, cred->gid));
NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
-   NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
+   NEW_AUX_ENT(AT_SECURE, bprm->secureexec);
NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
 #ifdef ELF_HWCAP2
NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index cf93a4fad012..5aa9199dfb13 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -650,7 +650,7 @@ static int create_elf_fdpic_tables(struct linux_binprm 
*bprm,
NEW_AUX_ENT(AT_EUID,(elf_addr_t) from_kuid_munged(cred->user_ns, 
cred->euid));
NEW_AUX_ENT(AT_GID, (elf_addr_t) from_kgid_munged(cred->user_ns, 
cred->gid));
NEW_AUX_ENT(AT_EGID,(elf_addr_t) from_kgid_munged(cred->user_ns, 
cred->egid));
-   NEW_AUX_ENT(AT_SECURE,  security_bprm_secureexec(bprm));
+   NEW_AUX_ENT(AT_SECURE,  bprm->secureexec);
NEW_AUX_ENT(AT_EXECFN,  bprm->exec);
 
 #ifdef ARCH_DLINFO
diff --git a/fs/exec.c b/fs/exec.c
index 7842ae661e34..b92e37fb53aa 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1337,6 +1337,11 @@ EXPORT_SYMBOL(would_dump);
 
 void setup_new_exec(struct linux_binprm * bprm)
 {
+   if (security_bprm_secureexec(bprm)) {
+   /* Record for AT_SECURE. */
+   bprm->secureexec = 1;
+   }
+
arch_pick_mmap_layout(current->mm);
 
current->sas_ss_sp = current->sas_ss_size = 0;
diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
index 05488da3aee9..1afaa303cad0 100644
--- a/include/linux/binfmts.h
+++ b/include/linux/binfmts.h
@@ -27,9 +27,10 @@ struct linux_binprm {
unsigned int
cred_prepared:1,/* true if creds already prepared (multiple
 * preps happen for interpreters) */
-   cap_effective:1;/* true if has elevated effective capabilities,
+   cap_effective:1,/* true if has elevated effective capabilities,
 * false if not; except for init which inherits
 * its parent's caps anyway */
+   secureexec:1;   /* true when gaining privileges */
 #ifdef __alpha__
unsigned int taso:1;
 #endif
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e66017..d1bd24fb4a33 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -72,7 +72,8 @@
  * Return a boolean value (0 or 1) indicating whether a "secure exec"
  * is required.  The flag is passed in the auxiliary table
  * on the initial stack to the ELF interpreter to indicate whether libc
- * should enable secure mode.
+ * should enable secure mode. Called before bprm_committing_creds(),
+ * so pending credentials are in @bprm->cred.
  * @bprm contains the linux_binprm structure.
  *
  * Security hooks for filesystem operations.
diff --git a/security/commonc

[PATCH v2 7/8] exec: Consolidate pdeath_signal clearing

[Kees Cook]

Instead of an additional secureexec check for pdeath_signal, just move it
up into the initial secureexec test. Neither perf nor arch code touches
pdeath_signal, so the relocation shouldn't change anything.

Signed-off-by: Kees Cook 
---
 fs/exec.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index eeb8323977d1..e0186db02f90 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1340,6 +1340,9 @@ void setup_new_exec(struct linux_binprm * bprm)
if (security_bprm_secureexec(bprm)) {
/* Record for AT_SECURE. */
bprm->secureexec = 1;
+
+   /* Make sure parent cannot signal privileged process. */
+   current->pdeath_signal = 0;
}
 
arch_pick_mmap_layout(current->mm);
@@ -1363,10 +1366,6 @@ void setup_new_exec(struct linux_binprm * bprm)
 */
current->mm->task_size = TASK_SIZE;
 
-   if (bprm->secureexec) {
-   current->pdeath_signal = 0;
-   }
-
/* An exec changes our domain. We are no longer part of the thread
   group */
current->self_exec_id++;
-- 
2.7.4

[PATCH v2 5/8] smack: Remove redundant pdeath_signal clearing

[Kees Cook]

This removes the redundant pdeath_signal clearing in Smack: the check in
smack_bprm_committing_creds() matches the check in smack_bprm_secureexec(),
and since secureexec is now being checked for clearing pdeath_signal, this
is redundant to the common exec code.

Signed-off-by: Kees Cook 
---
 security/smack/smack_lsm.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 13cf9e66d5fe..4b10b782aecc 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -954,20 +954,6 @@ static int smack_bprm_set_creds(struct linux_binprm *bprm)
 }
 
 /**
- * smack_bprm_committing_creds - Prepare to install the new credentials
- * from bprm.
- *
- * @bprm: binprm for exec
- */
-static void smack_bprm_committing_creds(struct linux_binprm *bprm)
-{
-   struct task_smack *bsp = bprm->cred->security;
-
-   if (bsp->smk_task != bsp->smk_forked)
-   current->pdeath_signal = 0;
-}
-
-/**
  * smack_bprm_secureexec - Return the decision to use secureexec.
  * @bprm: binprm for exec
  *
@@ -4645,7 +4631,6 @@ static struct security_hook_list smack_hooks[] 
__lsm_ro_after_init = {
LSM_HOOK_INIT(sb_parse_opts_str, smack_parse_opts_str),
 
LSM_HOOK_INIT(bprm_set_creds, smack_bprm_set_creds),
-   LSM_HOOK_INIT(bprm_committing_creds, smack_bprm_committing_creds),
LSM_HOOK_INIT(bprm_secureexec, smack_bprm_secureexec),
 
LSM_HOOK_INIT(inode_alloc_security, smack_inode_alloc_security),
-- 
2.7.4

Re: [kernel-hardening] [PATCH 00/11] S.A.R.A. a new stacked LSM

[Salvatore Mesoraca]

2017-07-09 21:35 GMT+02:00 Mickaël Salaün :
> Hi,
>
> I think it make sense to merge the W^X features with the TPE/shebang LSM
> [1].
>
> Regards,
>  Mickaël
>
> [1]
> https://lkml.kernel.org/r/d9aca46b-97c6-4faf-b559-484feb4aa...@digikod.net

Hi,
Can you elaborate why it would be an advantage to have those features merged?
They seem quite unrelated.
Also, they work in rather different ways in respect to how they are configured.
I'm not sure what would be a reasonable way to merge them.
Thank you for your comment,

Salvatore

[PATCH v2 1/8] exec: Correct comments about "point of no return"

[Kees Cook]

In commit 221af7f87b97 ("Split 'flush_old_exec' into two functions"),
the comment about the point of no return should have stayed in
flush_old_exec() since it refers to "bprm->mm = NULL;" line, but prior
changes in commits c89681ed7d0e ("remove steal_locks()"), and
fd8328be874f ("sanitize handling of shared descriptor tables in failing
execve()") made it look like it meant the current->sas_ss_sp line instead.

The comment is referring to the fact that once bprm->mm is NULL, all
failures from a binfmt load_binary hook (e.g. load_elf_binary), will
get SEGV raised against current. Move this comment and expand the
explanation a bit, putting it above the assignment this time.

This also removes an erroneous commet about when credentials are being
installed. That has its own dedicated function, install_exec_creds(),
which carries a similar (and correct) comment, so remove the bogus comment
where installation is not actually happening.

Signed-off-by: Kees Cook 
---
 fs/exec.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 904199086490..7842ae661e34 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1285,7 +1285,14 @@ int flush_old_exec(struct linux_binprm * bprm)
if (retval)
goto out;
 
-   bprm->mm = NULL;/* We're using it now */
+   /*
+* After clearing bprm->mm (to mark that current is using the
+* prepared mm now), we are at the point of no return. If
+* anything from here on returns an error, the check in
+* search_binary_handler() will kill current (since the mm has
+* been replaced).
+*/
+   bprm->mm = NULL;
 
set_fs(USER_DS);
current->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD |
@@ -1332,7 +1339,6 @@ void setup_new_exec(struct linux_binprm * bprm)
 {
arch_pick_mmap_layout(current->mm);
 
-   /* This is the point of no return */
current->sas_ss_sp = current->sas_ss_size = 0;
 
if (uid_eq(current_euid(), current_uid()) && gid_eq(current_egid(), 
current_gid()))
@@ -1350,7 +1356,6 @@ void setup_new_exec(struct linux_binprm * bprm)
 */
current->mm->task_size = TASK_SIZE;
 
-   /* install the new credentials */
if (!uid_eq(bprm->cred->uid, current_euid()) ||
!gid_eq(bprm->cred->gid, current_egid())) {
current->pdeath_signal = 0;
-- 
2.7.4

[PATCH v2 4/8] exec: Use secureexec for clearing pdeath_signal

[Kees Cook]

Like dumpability, clearing pdeath_signal happens both in setup_new_exec()
and later in commit_creds(). The test in setup_new_exec() is different
from all other privilege comparisons, though: it is checking the new cred
(bprm) uid vs the old cred (current) euid. This appears to be a bug,
introduced by commit a6f76f23d297 ("CRED: Make execve() take advantage of
copy-on-write credentials"):

-   if (bprm->e_uid != current_euid() ||
-   bprm->e_gid != current_egid()) {
-   set_dumpable(current->mm, suid_dumpable);
+   /* install the new credentials */
+   if (bprm->cred->uid != current_euid() ||
+   bprm->cred->gid != current_egid()) {

It was bprm euid vs current euid (and egids), but the effective got
dropped. Nothing in the exec flow changes bprm->cred->uid (nor gid).
The call traces are:

prepare_bprm_creds()
prepare_exec_creds()
prepare_creds()
memcpy(new_creds, old_creds, ...)
security_prepare_creds() (unimplemented by commoncap)
...
prepare_binprm()
bprm_fill_uid()
resets euid/egid to current euid/egid
sets euid/egid on bprm based on set*id file bits
security_bprm_set_creds()
cap_bprm_set_creds()
handle all caps-based manipulations

so this test is effectively a test of current_uid() vs current_euid(),
which is wrong, just like the prior dumpability tests were wrong.

The commit log says "Clear pdeath_signal and set dumpable on
certain circumstances that may not be covered by commit_creds()." This
may be meaning the earlier old euid vs new euid (and egid) test that
got changed.

Luckily, as with dumpability, this is all masked by commit_creds()
which performs old/new euid and egid tests and clears pdeath_signal.

And again, like dumpability, we should include LSM secureexec logic for
pdeath_signal clearing. For example, Smack goes out of its way to clear
pdeath_signal when it finds a secureexec condition.

Signed-off-by: Kees Cook 
---
 fs/exec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index 3e519d4f0bd3..d7bda5b60e7b 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1361,8 +1361,7 @@ void setup_new_exec(struct linux_binprm * bprm)
 */
current->mm->task_size = TASK_SIZE;
 
-   if (!uid_eq(bprm->cred->uid, current_euid()) ||
-   !gid_eq(bprm->cred->gid, current_egid())) {
+   if (bprm->secureexec) {
current->pdeath_signal = 0;
} else {
if (bprm->interp_flags & BINPRM_FLAGS_ENFORCE_NONDUMP)
-- 
2.7.4

[PATCH v2 3/8] exec: Use secureexec for setting dumpability

[Kees Cook]

The examination of "current" to decide dumpability is wrong. This was a
check of and euid/uid (or egid/gid) mismatch in the existing process,
not the newly created one. This appears to stretch back into even the
"history.git" tree. Luckily, dumpability is later set in commit_creds().
In earlier kernel versions before creds existed, similar checks also
existed late in the exec flow, covering up the mistake as far back as I
could find.

The commit_creds() check examines differences of euid, uid, egid, gid,
and capabilities between the old and new creds. It would look like
the setup_new_exec() dumpability test could be entirely removed, but
strictly speaking, the secureexec test covers a different set of tests
than what commit_creds() checks for. So, fix this test to use secureexec,
which includes the same logical check (euid != uid || egid != gid),
but checks bprm->cred, not current->cred.

One would wonder if we need a security_commit_creds() LSM hook and to
move the existing checks in commit_creds() into commoncaps.c, which
would allow expanding the logic to all LSMs. Currently this doesn't
seem needed, though.

Signed-off-by: Kees Cook 
---
 fs/exec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/exec.c b/fs/exec.c
index b92e37fb53aa..3e519d4f0bd3 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1346,7 +1346,7 @@ void setup_new_exec(struct linux_binprm * bprm)
 
current->sas_ss_sp = current->sas_ss_size = 0;
 
-   if (uid_eq(current_euid(), current_uid()) && gid_eq(current_egid(), 
current_gid()))
+   if (!bprm->secureexec)
set_dumpable(current->mm, SUID_DUMP_USER);
else
set_dumpable(current->mm, suid_dumpable);
-- 
2.7.4

[PATCH v2 1/2] platform: Add Amlogic Meson AO CEC Controller driver

[Neil Armstrong]

The Amlogic SoC embeds a standalone CEC controller, this patch adds a driver
for such controller.
The controller does not need HPD to be active, and could support up to max
5 logical addresses, but only 1 is handled since the Suspend firmware can
make use of this unique logical address to wake up the device.

The Suspend firmware configuration will be added in an other patchset.

Signed-off-by: Neil Armstrong 
---
 drivers/media/platform/Kconfig|  11 +
 drivers/media/platform/Makefile   |   2 +
 drivers/media/platform/meson/Makefile |   1 +
 drivers/media/platform/meson/ao-cec.c | 781 ++
 4 files changed, 795 insertions(+)
 create mode 100644 drivers/media/platform/meson/Makefile
 create mode 100644 drivers/media/platform/meson/ao-cec.c

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd5..1e67381 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -536,6 +536,17 @@ menuconfig CEC_PLATFORM_DRIVERS
 
 if CEC_PLATFORM_DRIVERS
 
+config VIDEO_MESON_AO_CEC
+   tristate "Amlogic Meson AO CEC driver"
+   depends on ARCH_MESON || COMPILE_TEST
+   select CEC_CORE
+   select CEC_NOTIFIER
+   ---help---
+ This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
+ generic CEC framework interface.
+ CEC bus is present in the HDMI connector and enables communication
+ between compatible devices.
+
 config VIDEO_SAMSUNG_S5P_CEC
tristate "Samsung S5P CEC driver"
depends on PLAT_S5P || ARCH_EXYNOS || COMPILE_TEST
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc7..a52d7b6 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -86,3 +86,5 @@ obj-$(CONFIG_VIDEO_MEDIATEK_MDP)  += mtk-mdp/
 obj-$(CONFIG_VIDEO_MEDIATEK_JPEG)  += mtk-jpeg/
 
 obj-$(CONFIG_VIDEO_QCOM_VENUS) += qcom/venus/
+
+obj-y  += meson/
diff --git a/drivers/media/platform/meson/Makefile 
b/drivers/media/platform/meson/Makefile
new file mode 100644
index 000..597beb8
--- /dev/null
+++ b/drivers/media/platform/meson/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_MESON_AO_CEC)   += ao-cec.o
diff --git a/drivers/media/platform/meson/ao-cec.c 
b/drivers/media/platform/meson/ao-cec.c
new file mode 100644
index 000..cdc1f61
--- /dev/null
+++ b/drivers/media/platform/meson/ao-cec.c
@@ -0,0 +1,781 @@
+/*
+ * Driver for Amlogic Meson AO CEC Controller
+ *
+ * Copyright (C) 2015 Amlogic, Inc. All rights reserved
+ * Copyright (C) 2017 BayLibre, SAS
+ * Author: Neil Armstrong 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* CEC Registers */
+
+/*
+ * [2:1] cntl_clk
+ *  - 0 = Disable clk (Power-off mode)
+ *  - 1 = Enable gated clock (Normal mode)
+ *  - 2 = Enable free-run clk (Debug mode)
+ */
+#define CEC_GEN_CNTL_REG   0x00
+
+#define CEC_GEN_CNTL_RESET BIT(0)
+#define CEC_GEN_CNTL_CLK_DISABLE   0
+#define CEC_GEN_CNTL_CLK_ENABLE1
+#define CEC_GEN_CNTL_CLK_ENABLE_DBG2
+#define CEC_GEN_CNTL_CLK_CTRL_MASK GENMASK(2, 1)
+
+/*
+ * [7:0] cec_reg_addr
+ * [15:8] cec_reg_wrdata
+ * [16] cec_reg_wr
+ *  - 0 = Read
+ *  - 1 = Write
+ * [23] bus free
+ * [31:24] cec_reg_rddata
+ */
+#define CEC_RW_REG 0x04
+
+#define CEC_RW_ADDRGENMASK(7, 0)
+#define CEC_RW_WR_DATA GENMASK(15, 8)
+#define CEC_RW_WRITE_ENBIT(16)
+#define CEC_RW_BUS_BUSYBIT(23)
+#define CEC_RW_RD_DATA GENMASK(31, 24)
+
+/*
+ * [1] tx intr
+ * [2] rx intr
+ */
+#define CEC_INTR_MASKN_REG 0x08
+#define CEC_INTR_CLR_REG   0x0c
+#define CEC_INTR_STAT_REG  0x10
+
+#define CEC_INTR_TXBIT(1)
+#define CEC_INTR_RXBIT(2)
+
+/* CEC Commands */
+
+#define CEC_TX_MSG_0_HEADER0x00
+#define CEC_TX_MSG_1_OPCODE0x01
+#define CEC_TX_MSG_2_OP1   0x02
+#define CEC_TX_MSG_3_OP2   0x03
+#define CEC_TX_MSG_4_OP3   0x04
+#define CEC_TX_MSG_5_OP4   0x05
+#define CEC_TX_MSG_6_OP5   0x06
+#define CEC_TX_MSG_7_OP6   0x07
+#define CEC_TX_MSG_8_OP7   0x08
+#define CEC_TX_MSG_9_OP8   0x09
+#define CEC_TX_MSG_A_OP9   0x0A
+#define CEC_TX_MSG_B_OP10  0x0B
+#define CEC_TX_MSG_C_OP11  0x0C
+#define CEC_TX_MSG_D_OP12  0x0D
+#define CEC_TX_MSG_E_OP13  0x0E
+#define CEC_TX_MSG_F_OP14  0x0F
+#define CEC_TX_MSG_LENGTH  0x10
+#define CEC_TX_MSG_CMD 0x11
+#define CEC_TX_WRITE_BUF   0x12
+#defi

[PATCH] net: can: at91_can: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
   6164 304   064681944 drivers/net/can/at91_can.o

File size After adding 'const':
   textdata bss dec hex filename
   6228 240   064681944 drivers/net/can/at91_can.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/can/at91_can.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/at91_can.c b/drivers/net/can/at91_can.c
index 0e0df0b..f37ce0e 100644
--- a/drivers/net/can/at91_can.c
+++ b/drivers/net/can/at91_can.c
@@ -1232,7 +1232,7 @@ static DEVICE_ATTR(mb0_id, S_IWUSR | S_IRUGO,
NULL,
 };
 
-static struct attribute_group at91_sysfs_attr_group = {
+static const struct attribute_group at91_sysfs_attr_group = {
.attrs = at91_sysfs_attrs,
 };
 
-- 
1.9.1

[PATCH v2 2/2] dt-bindings: media: Add Amlogic Meson AO-CEC bindings

[Neil Armstrong]

The Amlogic SoCs embeds a standalone CEC Controller, this patch adds this
device bindings.

Acked-by: Rob Herring 
Signed-off-by: Neil Armstrong 
---
 .../devicetree/bindings/media/meson-ao-cec.txt | 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/meson-ao-cec.txt

diff --git a/Documentation/devicetree/bindings/media/meson-ao-cec.txt 
b/Documentation/devicetree/bindings/media/meson-ao-cec.txt
new file mode 100644
index 000..8671bdb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/meson-ao-cec.txt
@@ -0,0 +1,28 @@
+* Amlogic Meson AO-CEC driver
+
+The Amlogic Meson AO-CEC module is present is Amlogic SoCs and its purpose is
+to handle communication between HDMI connected devices over the CEC bus.
+
+Required properties:
+  - compatible : value should be following
+   "amlogic,meson-gx-ao-cec"
+
+  - reg : Physical base address of the IP registers and length of memory
+ mapped region.
+
+  - interrupts : AO-CEC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to AO-CEC clock.
+  - clock-names : from common clock binding: must contain "core",
+ corresponding to entry in the clocks property.
+  - hdmi-phandle: phandle to the HDMI controller
+
+Example:
+
+cec_AO: cec@100 {
+   compatible = "amlogic,meson-gx-ao-cec";
+   reg = <0x0 0x00100 0x0 0x14>;
+   interrupts = ;
+   clocks = <&clkc_AO CLKID_AO_CEC_32K>;
+   clock-names = "core";
+   hdmi-phandle = <&hdmi_tx>;
+};
-- 
1.9.1

[PATCH v2 0/2] media: Add Amlogic Meson AO CEC Controller support

[Neil Armstrong]

The Amlogic SoC embeds a standalone CEC controller, this patch adds a driver
for such controller.
The controller does not need HPD to be active, and could support up to max
5 logical addresses, but only 1 is handled since the Suspend firmware can
make use of this unique logical address to wake up the device.

The Suspend firmware configuration will be added in an other patchset.

Changes since v1 at [1] :
 - add timeout to wait busy, with error return
 - handle busy error in all read/write operations
 - add CEC_CAP_PASSTHROUGH
 - add bindings ack

[1] 
https://lkml.kernel.org/r/1499336870-24118-1-git-send-email-narmstr...@baylibre.com

Neil Armstrong (2):
  platform: Add Amlogic Meson AO CEC Controller driver
  dt-bindings: media: Add Amlogic Meson AO-CEC bindings

 .../devicetree/bindings/media/meson-ao-cec.txt |  28 +
 drivers/media/platform/Kconfig |  11 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/meson/Makefile  |   1 +
 drivers/media/platform/meson/ao-cec.c  | 781 +
 5 files changed, 823 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/meson-ao-cec.txt
 create mode 100644 drivers/media/platform/meson/Makefile
 create mode 100644 drivers/media/platform/meson/ao-cec.c

-- 
1.9.1

[PATCH] net: can: janz-ican3: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

File size before:
   textdata bss dec hex filename
  11800 368   0   121682f88 drivers/net/can/janz-ican3.o

File size After adding 'const':
   textdata bss dec hex filename
  11864 304   0   121682f88 drivers/net/can/janz-ican3.o

Signed-off-by: Arvind Yadav 
---
 drivers/net/can/janz-ican3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/janz-ican3.c b/drivers/net/can/janz-ican3.c
index 2ba1a81..12a53c8 100644
--- a/drivers/net/can/janz-ican3.c
+++ b/drivers/net/can/janz-ican3.c
@@ -1875,7 +1875,7 @@ static DEVICE_ATTR(termination, S_IWUSR | S_IRUGO, 
ican3_sysfs_show_term,
NULL,
 };
 
-static struct attribute_group ican3_sysfs_attr_group = {
+static const struct attribute_group ican3_sysfs_attr_group = {
.attrs = ican3_sysfs_attrs,
 };
 
-- 
1.9.1

Re: [PATCH 1/2] netdevice: add netdev_pub helper function

[David Miller]

From: "Jason A. Donenfeld" 
Date: Mon, 10 Jul 2017 05:19:58 +0200

> Being able to utilize this makes code a lot simpler and cleaner. It's
> easier in many cases for drivers to pass around their private data
> structure, while occationally needing to dip into net_device, rather
> than the other way around, which results in tons of calls to netdev_priv
> in the top of every single function, which makes everything confusing
> and less clear. Additionally, this enables a "correct" way of doing such
> a thing, instead of having drivers attempt to reinvent the wheel and
> screw it up.
> 
> Signed-off-by: Jason A. Donenfeld 

I disagree.  Assuming one can go from the driver private to the netdev
object trivially is a worse assumption than the other way around, and
locks us into the current implementation of how the netdev and driver
private memory is allocated.

If you want to style your driver such that the private is passed
around instead of the netdev, put a pointer back to the netdev object
in your private data structure.

Which is exactly what the ioc3-eth driver ought to be doing.

Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

[Lee Jones]

On Mon, 10 Jul 2017, Javier Martinez Canillas wrote:

> Hello Lee,
> 
> On Thu, Jun 15, 2017 at 8:49 PM, Javier Martinez Canillas
>  wrote:
> >
> > This series add OF device ID tables to mfd I2C drivers whose devices are
> > either used in Device Tree source files or are listed in binding docs as
> > a compatible string.
> >
> > That's done because the plan is to change the I2C core to report proper OF
> > modaliases instead of always reporting a MODALIAS=i2c: regardless if
> > a device was registered via DT or using the legacy platform data mechanism.
> >
> > So these patches will make sure that mfd I2C drivers modules will continue
> > to be autoloaded once the I2C core is changed to report proper OF modalias.
> >
> > Users didn't have a vendor prefix in the used compatible strings, but since
> > there wasn't a DT binding document for these drivers, it can be said that
> > were working for mere luck and so this series fixes the users and add a DT
> > binding doc for the drivers.
> >
> > Most patches can be applied independently, with the exception of patches
> > 2 to 4 that should be applied in the same tree to keep bisect-ability. I
> > suggest these to go through the MFD subsystem tree.
> >
> > Best regards,
> > Javier
> >
> 
> Are you planning to pick this series? It has been in the list for
> months and were resent many times...

I think you exaggerate a little.  Your last Ack (from Linus) was only
collected in v6, which has only been resent once with that Ack
applied. =:)

We are currently only half way through the merge-window.  This patch
will be hoovered up during the early -rcs.  Please be patient around
the time of the merge-window, since Maintainers are either usually
very busy with pull-requests, or taking a 2 minute breather before
the chaos starts over.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [RESEND PATCH v6 6/8] dt-bindings: mfd: Add TI tps6105x chip bindings

[Lee Jones]

On Thu, 15 Jun 2017, Javier Martinez Canillas wrote:

> There are Device Tree source files defining a device node for the
> tps61050/61052 I2C chip but there isn't a binding document for it.
> 
> Signed-off-by: Javier Martinez Canillas 
> Acked-by: Rob Herring 
> Acked-by: Tony Lindgren 
> 
> ---
> 
> Changes in v6: None
> Changes in v5:
> - Add Rob Herring's Acked-by tag.
> - Add Acked-by: Tony Lindgren 's Acked-by tag.
> 
> Changes in v4:
> - Use "dt-bindings: mfd:" prefix in subject line (Rob Herring).
> - Add information about what functions the device serve (Lee Jones).
> 
> Changes in v3: None
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/mfd/tps6105x.txt | 17 +
>  1 file changed, 17 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/tps6105x.txt

For my own reference:
  Acked-for-MFD-by: Lee Jones 

> diff --git a/Documentation/devicetree/bindings/mfd/tps6105x.txt 
> b/Documentation/devicetree/bindings/mfd/tps6105x.txt
> new file mode 100644
> index ..93602c7a19c8
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/tps6105x.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for TI TPS61050/61052 Boost Converters
> +
> +The TP61050/TPS61052 is a high-power "white LED driver". The
> +device provides LED, GPIO and regulator functionalities.
> +
> +Required properties:
> +- compatible:"ti,tps61050" or "ti,tps61052"
> +- reg:   Specifies the I2C slave address
> +
> +Example:
> +
> +i2c0 {
> + tps61052@33 {
> + compatible = "ti,tps61052";
> + reg = <0x33>;
> + };
> +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v3] xen/balloon: don't online new memory initially

[Juergen Gross]

When setting up the Xenstore watch for the memory target size the new
watch will fire at once. Don't try to reach the configured target size
by onlining new memory in this case, as the current memory size will
be smaller in almost all cases due to e.g. BIOS reserved pages.

Onlining new memory will lead to more problems e.g. undesired conflicts
with NVMe devices meant to be operated as block devices.

Instead remember the difference between target size and current size
when the watch fires for the first time and apply it to any further
size changes, too.

In order to avoid races between balloon.c and xen-balloon.c init calls
do the xen-balloon.c initialization from balloon.c.

Signed-off-by: Juergen Gross 
---
 drivers/xen/balloon.c |  3 +++
 drivers/xen/xen-balloon.c | 22 --
 include/xen/balloon.h |  8 
 3 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 50dcb68d8070..ab609255a0f3 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -780,6 +780,9 @@ static int __init balloon_init(void)
}
 #endif
 
+   /* Init the xen-balloon driver. */
+   xen_balloon_init();
+
return 0;
 }
 subsys_initcall(balloon_init);
diff --git a/drivers/xen/xen-balloon.c b/drivers/xen/xen-balloon.c
index e7715cb62eef..e89136ab851e 100644
--- a/drivers/xen/xen-balloon.c
+++ b/drivers/xen/xen-balloon.c
@@ -59,6 +59,8 @@ static void watch_target(struct xenbus_watch *watch,
 {
unsigned long long new_target;
int err;
+   static bool watch_fired;
+   static long target_diff;
 
err = xenbus_scanf(XBT_NIL, "memory", "target", "%llu", &new_target);
if (err != 1) {
@@ -69,7 +71,14 @@ static void watch_target(struct xenbus_watch *watch,
/* The given memory/target value is in KiB, so it needs converting to
 * pages. PAGE_SHIFT converts bytes to pages, hence PAGE_SHIFT - 10.
 */
-   balloon_set_new_target(new_target >> (PAGE_SHIFT - 10));
+   new_target >>= PAGE_SHIFT - 10;
+   if (watch_fired) {
+   balloon_set_new_target(new_target - target_diff);
+   return;
+   }
+
+   watch_fired = true;
+   target_diff = new_target - balloon_stats.target_pages;
 }
 static struct xenbus_watch target_watch = {
.node = "memory/target",
@@ -94,22 +103,15 @@ static struct notifier_block xenstore_notifier = {
.notifier_call = balloon_init_watcher,
 };
 
-static int __init balloon_init(void)
+void xen_balloon_init(void)
 {
-   if (!xen_domain())
-   return -ENODEV;
-
-   pr_info("Initialising balloon driver\n");
-
register_balloon(&balloon_dev);
 
register_xen_selfballooning(&balloon_dev);
 
register_xenstore_notifier(&xenstore_notifier);
-
-   return 0;
 }
-subsys_initcall(balloon_init);
+EXPORT_SYMBOL_GPL(xen_balloon_init);
 
 #define BALLOON_SHOW(name, format, args...)\
static ssize_t show_##name(struct device *dev,  \
diff --git a/include/xen/balloon.h b/include/xen/balloon.h
index d1767dfb0d95..8906361bb50c 100644
--- a/include/xen/balloon.h
+++ b/include/xen/balloon.h
@@ -35,3 +35,11 @@ static inline int register_xen_selfballooning(struct device 
*dev)
return -ENOSYS;
 }
 #endif
+
+#ifdef CONFIG_XEN_BALLOON
+void xen_balloon_init(void);
+#else
+static inline void xen_balloon_init(void)
+{
+}
+#endif
-- 
2.12.3

Re: 4.13-rc0: stopped booting on Nokia N900

[Pavel Machek]

On Mon 2017-07-10 09:46:10, Pavel Machek wrote:
> Hi!
> 
> First, I got segfault from make:
> 
> : 0: Can't open
> scripts/Makefile.build:561: recipe for target
> 'drivers/iio/imu/st_lsm6dsx' failed
> make[3]: *** [drivers/iio/imu/st_lsm6dsx] Segmentation fault (core
> dumped)
> scripts/Makefile.build:561: recipe for target 'drivers/iio/imu' failed
> make[2]: *** [drivers/iio/imu] Error 2
> scripts/Makefile.build:561: recipe for target 'drivers/iio' failed
> make[1]: *** [drivers/iio] Error 2
> make[1]: *** Waiting for unfinished jobs
> Makefile:1008: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
> make: *** Waiting for unfinished jobs
> pavel@duo:/data/l/linux-n900$ ./mkit
> 
> Then compile worked, but it failed to boot. I've now cleaned caches
> and am rebuilding to make sure it is not build machine that has
> glitches.
> 
> No such luck :-(.
> 
> I tested linux-next relatively recently, and it worked ok.

> af3c8d98508d37541d4bf57f13a984a7f73a328c is broken.
> 650fc87 worked ok.

2b97620 is broken.

commit a51166ce71844ffbb8f78d63647b44dd69e46cf1
Add linux-next specific files for 20170628

was ok.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v6 1/7] perf/core: Define the common branch type classification

[Jin, Yao]

On 7/10/2017 2:05 PM, Michael Ellerman wrote:

Hi Jin Yao,

Sorry I haven't commented until now, but it got lost in the flood of
patches.


Never mind, it's no problem. :)


Just a few nit-picks below ...
Jin Yao  writes:


It is often useful to know the branch types while analyzing branch
data. For example, a call is very different from a conditional branch.

Currently we have to look it up in binary while the binary may later
not be available and even the binary is available but user has to take
some time. It is very useful for user to check it directly in perf
report.

Perf already has support for disassembling the branch instruction
to get the x86 branch type.

To keep consistent on kernel and userspace and make the classification
more common, the patch adds the common branch type classification
in perf_event.h.

Most of the code and doc uses "branch" but then a few these are called
"jump". Can we just stick with "branch"?


PERF_BR_NONE  : unknown
PERF_BR_JCC   : conditional jump
PERF_BR_JMP   : jump
PERF_BR_IND_JMP   : indirect jump

eg:

PERF_BR_COND: conditional branch
PERF_BR_UNCOND  : unconditional branch
PERF_BR_IND : indirect branch


Call and jump are all branches. If we want to figure out which one is 
jump and which one is call, we need the detail branch type definitions.


For example,  if we only say "PERF_BR_IND", we could not know if it's an 
indirect jump or indirect call.

PERF_BR_CALL  : call
PERF_BR_IND_CALL  : indirect call
PERF_BR_RET   : return
PERF_BR_SYSCALL   : syscall
PERF_BR_SYSRET: syscall return
PERF_BR_IRQ   : hw interrupt/trap/fault
PERF_BR_INT   : sw interrupt

I'm not sure what that means, I'm guessing on x86 it means someone
executed "int" ?


PERF_BR_IRQ is for hw interrupt and PERF_BR_INT is for sw interrupt.

PERF_BR_CALL/PERF_BR_IND_CALL and PERF_BR_RET are for function call 
(direct call and indirect call) and return.


PERF_BR_SYSCALL/PERF_BR_SYSRET are for syscall and syscall return.


Is that sufficiently useful to use up a bit? I think we only have 3
free?


Do you means 3 bits? Each bit stands for one branch type? I guess what 
you mean is:


PERF_BR_COND: conditional branch
PERF_BR_UNCOND  : unconditional branch
PERF_BR_IND : indirect branch

But 3 branch types are not enough for us.


PERF_BR_IRET  : return from interrupt
PERF_BR_FAR_BRANCH: not generic far branch type

What is a "not generic far branch" ?

I don't know what that would mean on powerpc for example.


It's reserved for future using I think.



I think the only thing we have on powerpc that's commonly used and that
isn't covered above is branches that decrement a loop counter and then
branch based on the result.

It might be nice if we could separate those out from other conditional
branches. Whether it's worth using a bit for I'm not sure. Do other
arches have something similar?

Those branches do tend to be "backward conditional", so that may be
sufficient. But backward conditional also includes if bodies that have
been moved out of line and then branch back to the main body of the
function.

cheers


Sorry, I'm not familiar with powerpc arch. Or could you add the branch 
type which powerpc needs?


For backward conditional and forward conditional, we compute them in 
userspace according to the from/to addresses.


Thanks
Jin Yao

Re: [linux-sunxi] [PATCH v5 1/6] clk: sunxi-ng: div: Add support for fixed post-divider

[Olliver Schinagl]

Hey Plaes,

On 04-07-17 22:04, Priit Laes wrote:

SATA clock on sun4i/sun7i is of type (parent) / M / 6 where
6 is fixed post-divider.

Signed-off-by: Priit Laes 
---
 drivers/clk/sunxi-ng/ccu_div.c | 18 --
 drivers/clk/sunxi-ng/ccu_div.h |  3 ++-
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index c0e5c10..054b12a 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -21,6 +21,9 @@ static unsigned long ccu_div_round_rate(struct 
ccu_mux_internal *mux,
 {
struct ccu_div *cd = data;

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   rate /= cd->fixed_post_div;
+
return divider_round_rate_parent(&cd->common.hw, parent,
 rate, parent_rate,
 cd->div.table, cd->div.width,
@@ -62,8 +65,13 @@ static unsigned long ccu_div_recalc_rate(struct clk_hw *hw,
parent_rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
  parent_rate);

-   return divider_recalc_rate(hw, parent_rate, val, cd->div.table,
-  cd->div.flags);
+   val = divider_recalc_rate(hw, parent_rate, val, cd->div.table,
+ cd->div.flags);
+
+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   val /= cd->fixed_post_div;
+
+   return val;
 }

 static int ccu_div_determine_rate(struct clk_hw *hw,
@@ -71,6 +79,9 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
 {
struct ccu_div *cd = hw_to_ccu_div(hw);

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   req->rate *= cd->fixed_post_div;
+
return ccu_mux_helper_determine_rate(&cd->common, &cd->mux,
 req, ccu_div_round_rate, cd);
 }
@@ -89,6 +100,9 @@ static int ccu_div_set_rate(struct clk_hw *hw, unsigned long 
rate,
val = divider_get_val(rate, parent_rate, cd->div.table, cd->div.width,
  cd->div.flags);

+   if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+   val /= cd->fixed_post_div;
+
spin_lock_irqsave(cd->common.lock, flags);

reg = readl(cd->common.base + cd->common.reg);
diff --git a/drivers/clk/sunxi-ng/ccu_div.h b/drivers/clk/sunxi-ng/ccu_div.h
index 08d0744..f3a5028 100644
--- a/drivers/clk/sunxi-ng/ccu_div.h
+++ b/drivers/clk/sunxi-ng/ccu_div.h
@@ -86,9 +86,10 @@ struct ccu_div_internal {
 struct ccu_div {
u32 enable;

-   struct ccu_div_internal div;
+   struct ccu_div_internal div;
struct ccu_mux_internal mux;
struct ccu_common   common;
+   unsigned intfixed_post_div;
 };

 #define SUNXI_CCU_DIV_TABLE_WITH_GATE(_struct, _name, _parent, _reg,   \

[PATCH] Staging:ks7010:ks_wlan_net.c: unneeded type casting removed

[AndyS]

removed undesired type casting. Warning was raised by checkpatch.pl
This patch is for eudyptula challenge

Signed-off-by: AndyS 
---
 drivers/staging/ks7010/ks_wlan_net.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/ks7010/ks_wlan_net.c 
b/drivers/staging/ks7010/ks_wlan_net.c
index 8aa12e813bd7..e176876665df 100644
--- a/drivers/staging/ks7010/ks_wlan_net.c
+++ b/drivers/staging/ks7010/ks_wlan_net.c
@@ -208,7 +208,7 @@ static int ks_wlan_set_freq(struct net_device *dev,
/* for SLEEP MODE */
/* If setting by frequency, convert to a channel */
if ((fwrq->e == 1) &&
-   (fwrq->m >= (int)2.412e8) && (fwrq->m <= (int)2.487e8)) {
+   (fwrq->m >= 2.412e8) && (fwrq->m <= 2.487e8)) {
int f = fwrq->m / 10;
int c = 0;
 
-- 
2.13.0

Re: [PATCH 4/5] mm/memcontrol: allow to uncharge page without using page->lru field

[Michal Hocko]

On Wed 05-07-17 10:35:29, Jerome Glisse wrote:
> On Tue, Jul 04, 2017 at 02:51:13PM +0200, Michal Hocko wrote:
> > On Mon 03-07-17 17:14:14, Jérôme Glisse wrote:
> > > HMM pages (private or public device pages) are ZONE_DEVICE page and
> > > thus you can not use page->lru fields of those pages. This patch
> > > re-arrange the uncharge to allow single page to be uncharge without
> > > modifying the lru field of the struct page.
> > > 
> > > There is no change to memcontrol logic, it is the same as it was
> > > before this patch.
> > 
> > What is the memcg semantic of the memory? Why is it even charged? AFAIR
> > this is not a reclaimable memory. If yes how are we going to deal with
> > memory limits? What should happen if go OOM? Does killing an process
> > actually help to release that memory? Isn't it pinned by a device?
> > 
> > For the patch itself. It is quite ugly but I haven't spotted anything
> > obviously wrong with it. It is the memcg semantic with this class of
> > memory which makes me worried.
> 
> So i am facing 3 choices. First one not account device memory at all.
> Second one is account device memory like any other memory inside a
> process. Third one is account device memory as something entirely new.
> 
> I pick the second one for two reasons. First because when migrating
> back from device memory it means that migration can not fail because
> of memory cgroup limit, this simplify an already complex migration
> code. Second because i assume that device memory usage is a transient
> state ie once device is done with its computation the most likely
> outcome is memory is migrated back. From this assumption it means
> that you do not want to allow a process to overuse regular memory
> while it is using un-accounted device memory. It sounds safer to
> account device memory and to keep the process within its memcg
> boundary.
> 
> Admittedly here i am making an assumption and i can be wrong. Thing
> is we do not have enough real data of how this will be use and how
> much of an impact device memory will have. That is why for now i
> would rather restrict myself to either not account it or account it
> as usual.
> 
> If you prefer not accounting it until we have more experience on how
> it is use and how it impacts memory resource management i am fine with
> that too. It will make the migration code slightly more complex.

I can see why you want to do this but the semantic _has_ to be clear.
And as such make sure that the exiting task will simply unpin and
invalidate all the device memory (assuming this memory is not shared
which I am not sure is even possible).
-- 
Michal Hocko
SUSE Labs

Re: [patch 1/3] tty: resolve tty contention between kernel and user space

[Okash Khawaja]

On Sun, Jul 09, 2017 at 06:04:17PM +0300, Andy Shevchenko wrote:
> On Sun, Jul 9, 2017 at 2:41 PM, Okash Khawaja  wrote:
> 
> > +struct tty_struct *tty_kopen(dev_t device)
> > +{
> > +   struct tty_struct *tty;
> > +   struct tty_driver *driver = NULL;
> > +   int index = -1;
> > +
> > +   mutex_lock(&tty_mutex);
> > +   driver = tty_lookup_driver(device, NULL, &index);
> > +   if (IS_ERR(driver)) {
> 
> > +   mutex_unlock(&tty_mutex);
> > +   return ERR_CAST(driver);
> 
> Hmm... perhaps
> 
> tty = ERR_CAST(driver);
> goto out_unlock;
> 
> See below for further details.
> 
Sorry missed this one out. Since tty_lookup_driver has failed, we don't
need to down the refcount on driver. So we can return here, without
going to out_unlock.

Thanks,
Okash

Re: [PATCHSET for-4.13] cgroup: implement cgroup2 thread mode, v2

[Peter Zijlstra]

On Fri, Jun 30, 2017 at 09:23:24AM -0400, Tejun Heo wrote:
> On Tue, Jun 27, 2017 at 09:01:43AM +0200, Peter Zijlstra wrote:
> > On Mon, Jun 12, 2017 at 05:27:53PM -0400, Tejun Heo wrote:

> > IIRC the problem with the 'threaded' marker is that it doesn't clearly
> > capture what a resource domain is.
> > 
> > That is, assuming that a thread root is always a resource domain, we get
> > the following problem:
> > 
> > If we set 'threaded' on the root group in order to create a thread
> > (sub)group. If we then want to create another domain group, we'd have to
> > clear 'threaded' on that.
> > 
> > R (t=1)
> >/ \
> > (t=1) T   D (t=0)
> > 
> > So far so good. However, now we want to create another thread group
> > under our domain group D, so we have to set its 'threaded' marker again:
> > 
> > R (t=1)
> >/ \
> > (t=1) T   D (t=1)
> >  /
> > T (t=1)
> > 
> > And we can no longer identify D as a resource domain. If OTOH we mark
> > 'domain' we get:
> > 
> > R (d=1)
> >/ \
> > (d=0) T   D (d=1)
> >  /
> > T (d=0)
> > 
> > Which clearly identifies the domains and the thread only groups.
> 
> So, the difference between the two interfaces is that the one I
> proposed is marking the thread root which makes all its descendants
> threaded while the above is marking each individual cgroup as being
> whether a resource domain or threaded.

You start by marking the thread root, but then continue to mark all
'threaded' (including root). This then leads to the problem described
above where you cannot (easily) (re)discover what the actual root is.

My proposal differs in that we retain a clear difference between
resource domain / root and threaded (sub)trees.

> > Your objections to doing this were representing the resource controllers
> > in the intermediate thread-only groups like:
> > 
> >R
> > \
> >  T  -- what to do with eg. memcg here?
> >   \
> >D
> > \
> >  T
> 
> And that's a perfectly valid point and as you pointed out the downside
> of marking each node separately is that the interface would allow
> configurations which aren't supported (at least for now) and that
> there's just more to configure - the user has to set the mode on each
> node after creation which is just the natural cost of being able to
> express more.

I'm not sure my proposal results in _more_ configuration per-se. Yes
there are some differences, but they go both ways, with the threaded tag
its easier to create multiple threaded subgroups, but with the domain
tag its easier to create multiple domain subgroups.

And I think the bias for the domain tag -- easier to create more domains
-- is the right one. The whole threaded thing is fairly special purpose.

In any case; I'm fine with initially not supporting domains nested under
thread groups -- although I do think there's valid use-cases for doing
so.

> > I suggested having all resource controllers represented with a soft-link
> > back into the (thread-root) resource domain. But you were not convinced
> > and worried people were going to be confused.
> 
> There's more to it than just confusion because resource interface
> files belong to the parent cgroup rather than the cgroup which hosts
> the files.  This becomes clear when thinking about which files a
> container should be granted write access to when delegating a cgroup
> subtree to it.  I'm sure we can get around it some way but we need to
> be careful here.

I would suggest having all the back-links be RO. That way you can never
grant write permission, can never actually change things that don't make
'sense', but get a really good clue where you need to go.

> > By having both in nice units, its both conceptually clear that they're
> > the same kind of weight and easier to match weights.

> But, it doesn't have to be this or that.  We can easily support both
> units by simply allowing, say, "-5n" to be written to cpu.weight file
> and interpret that as the nice value and exposing the closest nice
> value in the cpu.stat file.
> 
> Does that sound workable?

Not sure; reading the value would become somewhat awkward I suppose. But
maybe we can simply do two files, whichever is written to last takes
precedence. And when a !nice weight is written, the nice file returns
-EINVAL or something.

Not particularly pretty though...

Re: [PATCH] ptrace: Add compat PTRACE_{G,S}ETSIGMASK handlers

[Yury Norov]

On Thu, Jun 29, 2017 at 05:26:37PM +0100, James Morse wrote:
> compat_ptrace_request() lacks handlers for PTRACE_{G,S}ETSIGMASK,
> instead using those in ptrace_request(). The compat variant should
> read a compat_sigset_t from userspace instead of ptrace_request()s
> sigset_t.
> 
> While compat_sigset_t is the same size as sigset_t, it is defined as
> 2xu32, instead of a single u64. On a big-endian CPU this means that
> compat_sigset_t is passed to user-space using middle-endianness,
> where the least-significant u32 is written most significant byte
> first.
> 
> If ptrace_request()s code is used userspace will read the most
> significant u32 where it expected the least significant.
> 
> Instead of duplicating ptrace_request()s code as a special case in
> the arch code, handle it here.
 
Hi James,

I tested arm64/ilp32 on top of, and everything is fine.

Yury

Acked-by: Yury Norov 

> CC: Yury Norov 
> CC: Andrey Vagin 
> Reported-by: Zhou Chengming 
> Signed-off-by: James Morse 
> Fixes: 29000caecbe87 ("ptrace: add ability to get/set signal-blocked mask")
> ---
> LTP test case here:
> https://lists.linux.it/pipermail/ltp/2017-June/004932.html
> 
>  kernel/ptrace.c | 52 
>  1 file changed, 40 insertions(+), 12 deletions(-)
> 
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index 8d2c10714530..a5bebb6713e8 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -843,6 +843,22 @@ static int ptrace_regset(struct task_struct *task, int 
> req, unsigned int type,
>  EXPORT_SYMBOL_GPL(task_user_regset_view);
>  #endif
>  
> +static int ptrace_setsigmask(struct task_struct *child, sigset_t *new_set)
> +{
> + sigdelsetmask(new_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
> +
> + /*
> +  * Every thread does recalc_sigpending() after resume, so
> +  * retarget_shared_pending() and recalc_sigpending() are not
> +  * called here.
> +  */
> + spin_lock_irq(&child->sighand->siglock);
> + child->blocked = *new_set;
> + spin_unlock_irq(&child->sighand->siglock);
> +
> + return 0;
> +}
> +
>  int ptrace_request(struct task_struct *child, long request,
>  unsigned long addr, unsigned long data)
>  {
> @@ -914,18 +930,7 @@ int ptrace_request(struct task_struct *child, long 
> request,
>   break;
>   }
>  
> - sigdelsetmask(&new_set, sigmask(SIGKILL)|sigmask(SIGSTOP));
> -
> - /*
> -  * Every thread does recalc_sigpending() after resume, so
> -  * retarget_shared_pending() and recalc_sigpending() are not
> -  * called here.
> -  */
> - spin_lock_irq(&child->sighand->siglock);
> - child->blocked = new_set;
> - spin_unlock_irq(&child->sighand->siglock);
> -
> - ret = 0;
> + ret = ptrace_setsigmask(child, &new_set);
>   break;
>   }
>  
> @@ -1149,7 +1154,9 @@ int compat_ptrace_request(struct task_struct *child, 
> compat_long_t request,
> compat_ulong_t addr, compat_ulong_t data)
>  {
>   compat_ulong_t __user *datap = compat_ptr(data);
> + compat_sigset_t set32;
>   compat_ulong_t word;
> + sigset_t new_set;
>   siginfo_t siginfo;
>   int ret;
>  
> @@ -1189,6 +1196,27 @@ int compat_ptrace_request(struct task_struct *child, 
> compat_long_t request,
>   else
>   ret = ptrace_setsiginfo(child, &siginfo);
>   break;
> + case PTRACE_GETSIGMASK:
> + if (addr != sizeof(compat_sigset_t))
> + return -EINVAL;
> +
> + sigset_to_compat(&set32, &child->blocked);
> +
> + if (copy_to_user(datap, &set32, sizeof(set32)))
> + return -EFAULT;
> +
> + ret = 0;
> + break;
> + case PTRACE_SETSIGMASK:
> + if (addr != sizeof(compat_sigset_t))
> + return -EINVAL;
> +
> + if (copy_from_user(&set32, datap, sizeof(compat_sigset_t)))
> + return -EFAULT;
> +
> + sigset_from_compat(&new_set, &set32);
> + ret = ptrace_setsigmask(child, &new_set);
> + break;
>  #ifdef CONFIG_HAVE_ARCH_TRACEHOOK
>   case PTRACE_GETREGSET:
>   case PTRACE_SETREGSET:
> -- 
> 2.11.0

Re: [RESEND PATCH v6 0/8] mfd: Add OF device table to I2C drivers that are missing it

[Javier Martinez Canillas]

On Mon, Jul 10, 2017 at 10:07 AM, Lee Jones  wrote:
> On Mon, 10 Jul 2017, Javier Martinez Canillas wrote:
>
>> Hello Lee,
>>
>> On Thu, Jun 15, 2017 at 8:49 PM, Javier Martinez Canillas
>>  wrote:
>> >
>> > This series add OF device ID tables to mfd I2C drivers whose devices are
>> > either used in Device Tree source files or are listed in binding docs as
>> > a compatible string.
>> >
>> > That's done because the plan is to change the I2C core to report proper OF
>> > modaliases instead of always reporting a MODALIAS=i2c: regardless if
>> > a device was registered via DT or using the legacy platform data mechanism.
>> >
>> > So these patches will make sure that mfd I2C drivers modules will continue
>> > to be autoloaded once the I2C core is changed to report proper OF modalias.
>> >
>> > Users didn't have a vendor prefix in the used compatible strings, but since
>> > there wasn't a DT binding document for these drivers, it can be said that
>> > were working for mere luck and so this series fixes the users and add a DT
>> > binding doc for the drivers.
>> >
>> > Most patches can be applied independently, with the exception of patches
>> > 2 to 4 that should be applied in the same tree to keep bisect-ability. I
>> > suggest these to go through the MFD subsystem tree.
>> >
>> > Best regards,
>> > Javier
>> >
>>
>> Are you planning to pick this series? It has been in the list for
>> months and were resent many times...
>
> I think you exaggerate a little.  Your last Ack (from Linus) was only
> collected in v6, which has only been resent once with that Ack
> applied. =:)
>

You are right, sorry for the impatience.

> We are currently only half way through the merge-window.  This patch
> will be hoovered up during the early -rcs.  Please be patient around
> the time of the merge-window, since Maintainers are either usually
> very busy with pull-requests, or taking a 2 minute breather before
> the chaos starts over.
>

Great, I just was worried that it could fell through the cracks.
Thanks for your answer.

Best regards,
Javier

[PATCH v2] MIPS: Fix minimum alignment requirement of IRQ stack

[Matt Redfearn]

Commit db8466c581cc ("MIPS: IRQ Stack: Unwind IRQ stack onto task
stack") erroneously set the initial stack pointer of the IRQ stack to a
value with a 4 byte alignment. The MIPS32 ABI requires that the minimum
stack alignment is 8 byte, and the MIPS64 ABIs(n32/n64) require 16 byte
minimum alignment. Fix IRQ_STACK_START such that it leaves space for the
dummy stack frame (containing interrupted task kernel stack pointer)
while also meeting minimum alignment requirements.

Fixes: db8466c581cc ("MIPS: IRQ Stack: Unwind IRQ stack onto task stack")
Reported-by: Darius Ivanauskas 
Signed-off-by: Matt Redfearn 
---

Changes in v2:
Don't include asm/asm.h since the definitions in it lead to breakage
when it pollutes the C namespace (thanks kbuild test robot!)

 arch/mips/include/asm/irq.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/include/asm/irq.h b/arch/mips/include/asm/irq.h
index ddd1c918103b..c5d351786416 100644
--- a/arch/mips/include/asm/irq.h
+++ b/arch/mips/include/asm/irq.h
@@ -18,7 +18,7 @@
 #include 
 
 #define IRQ_STACK_SIZE THREAD_SIZE
-#define IRQ_STACK_START(IRQ_STACK_SIZE - 
sizeof(unsigned long))
+#define IRQ_STACK_START(IRQ_STACK_SIZE - 16)
 
 extern void *irq_stack[NR_CPUS];
 
-- 
2.7.4

Re: [PATCH 1/4] kasan: support alloca() poisoning

[Dmitry Vyukov]

On Fri, Jul 7, 2017 at 12:01 AM, Greg Hackmann  wrote:
> clang's AddressSanitizer implementation adds redzones on either side of
> alloca()ed buffers.  These redzones are 32-byte aligned and at least 32
> bytes long.
>
> __asan_alloca_poison() is passed the size and address of the allocated
> buffer, *excluding* the redzones on either side.  The left redzone will
> always be to the immediate left of this buffer; but AddressSanitizer may
> need to add padding between the end of the buffer and the right redzone.
> If there are any 8-byte chunks inside this padding, we should poison
> those too.
>
> __asan_allocas_unpoison() is just passed the top and bottom of the
> dynamic stack area, so unpoisoning is simpler.
>
> Signed-off-by: Greg Hackmann 
> ---
>  lib/test_kasan.c  | 22 ++
>  mm/kasan/kasan.c  | 26 ++
>  mm/kasan/kasan.h  |  8 
>  mm/kasan/report.c |  3 +++
>  4 files changed, 59 insertions(+)
>
> diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> index a25c9763fce1..f774fcafb696 100644
> --- a/lib/test_kasan.c
> +++ b/lib/test_kasan.c
> @@ -473,6 +473,26 @@ static noinline void __init use_after_scope_test(void)
> p[1023] = 1;
>  }
>
> +static noinline void __init kasan_alloca_oob_left(void)
> +{
> +   volatile int i = 10;
> +   char alloca_array[i];
> +   char *p = alloca_array - 1;
> +
> +   pr_info("out-of-bounds to left on alloca\n");
> +   *(volatile char *)p;
> +}
> +
> +static noinline void __init kasan_alloca_oob_right(void)
> +{
> +   volatile int i = 10;
> +   char alloca_array[i];
> +   char *p = alloca_array + round_up(i, 8);
> +
> +   pr_info("out-of-bounds to right on alloca\n");
> +   *(volatile char *)p;
> +}
> +
>  static int __init kmalloc_tests_init(void)
>  {
> /*
> @@ -503,6 +523,8 @@ static int __init kmalloc_tests_init(void)
> memcg_accounted_kmem_cache();
> kasan_stack_oob();
> kasan_global_oob();
> +   kasan_alloca_oob_left();
> +   kasan_alloca_oob_right();
> ksize_unpoisons_memory();
> copy_user_test();
> use_after_scope_test();
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index c81549d5c833..892b626f564b 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -802,6 +802,32 @@ void __asan_unpoison_stack_memory(const void *addr, 
> size_t size)
>  }
>  EXPORT_SYMBOL(__asan_unpoison_stack_memory);
>
> +/* Emitted by compiler to poison alloca()ed objects. */
> +void __asan_alloca_poison(unsigned long addr, size_t size)
> +{
> +   size_t rounded_up_size = round_up(size, KASAN_SHADOW_SCALE_SIZE);
> +   size_t padding_size = round_up(size, KASAN_ALLOCA_REDZONE_SIZE) -
> +   round_up(size, KASAN_SHADOW_SCALE_SIZE);

Perhaps s/round_up(size, KASAN_SHADOW_SCALE_SIZE)/rounded_up_size/
because we already calculated that.

> +
> +   const void *left_redzone = (const void *)(addr -
> +   KASAN_ALLOCA_REDZONE_SIZE);
> +   const void *right_redzone = (const void *)(addr + rounded_up_size);

Please check that size is rounded to KASAN_ALLOCA_REDZONE_SIZE. That's
the expectation, right? That can change is clang silently.

> +   kasan_poison_shadow(left_redzone, KASAN_ALLOCA_REDZONE_SIZE,
> +   KASAN_ALLOCA_LEFT);
> +   kasan_poison_shadow(right_redzone,
> +   padding_size + KASAN_ALLOCA_REDZONE_SIZE,
> +   KASAN_ALLOCA_RIGHT);

We also need to poison the unaligned part at the end of the object
from size to rounded_up_size. You can see how we do it for heap
objects.

> +}
> +EXPORT_SYMBOL(__asan_alloca_poison);
> +/* Emitted by compiler to unpoison alloca()ed areas when the stack unwinds. 
> */
> +void __asan_allocas_unpoison(const void *stack_top, const void *stack_bottom)
> +{
> +   kasan_unpoison_shadow(stack_top, stack_bottom - stack_top);
> +}
> +EXPORT_SYMBOL(__asan_allocas_unpoison);
> +
>  #ifdef CONFIG_MEMORY_HOTPLUG
>  static int kasan_mem_notifier(struct notifier_block *nb,
> unsigned long action, void *data)
> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
> index 1229298cce64..b857dc70d6a2 100644
> --- a/mm/kasan/kasan.h
> +++ b/mm/kasan/kasan.h
> @@ -23,6 +23,14 @@
>  #define KASAN_STACK_PARTIAL 0xF4
>  #define KASAN_USE_AFTER_SCOPE   0xF8
>
> +/*
> + * alloca redzone shadow values
> + */
> +#define KASAN_ALLOCA_LEFT  0xCA
> +#define KASAN_ALLOCA_RIGHT 0xCB
> +
> +#define KASAN_ALLOCA_REDZONE_SIZE  32
> +
>  /* Don't break randconfig/all*config builds */
>  #ifndef KASAN_ABI_VERSION
>  #define KASAN_ABI_VERSION 1
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index beee0e980e2d..c6a5b7ab9e3a 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -101,6 +101,9 @@ static const char *get_shadow_bug_type(struct 
> kasan_access_info *info)
> break;
> case KASAN_USE_AFTER_SCOPE:
> bug_ty

Re: [RFC][PATCH] exec: Use init rlimits for setuid exec

[Michal Hocko]

On Thu 06-07-17 12:12:55, Kees Cook wrote:
> On Thu, Jul 6, 2017 at 10:52 AM, Linus Torvalds
>  wrote:
> > On Thu, Jul 6, 2017 at 10:29 AM, Kees Cook  wrote:
> >>>
> >>>  (a) minimal: just use our existing default stack (and stack _only_)
> >>> limit value for suid binaries that actually get extra permissions: {
> >>> _STK_LIM, RLIM_INFINITY }.
> >>
> >> This would look a lot like the existing patch; it'd just not copy the
> >> init process rlimits.
> >
> > Can't we just do the final rlimit setting so late in execve that we
> > don't need that whole "saved_rlimit" thing?
> 
> The stack rlimit defines the mmap layout too:
> 
> do_execveat_common() ->
> exec_binprm() ->
> search_binary_handler() ->
> fmt->load_binary (load_elf_binary()) ->
> setup_new_exec() ->
> arch_pick_mmap_layout() ->
> mmap_is_legacy() ->
> rlimit(RLIMIT_STACK) == RLIM_INFINITY

FWIW this is gone in tip tree. See
lkml.kernel.org/r/20170614082218.12450-1-mho...@kernel.org

-- 
Michal Hocko
SUSE Labs

[PATCH] ftrace: hide cached module code for !CONFIG_MODULES

[Arnd Bergmann]

When modules are disabled, we get a harmless build warning:

kernel/trace/ftrace.c:4051:13: error: 'process_cached_mods' defined but not 
used [-Werror=unused-function]

This adds the same #ifdef around the new code that exists around
its caller.

Fixes: d7fbf8df7ca0 ("ftrace: Implement cached modules tracing on module load")
Signed-off-by: Arnd Bergmann 
---
 kernel/trace/ftrace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 2953d558bbee..4706f0ed193e 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -3978,6 +3978,7 @@ static int
 ftrace_set_regex(struct ftrace_ops *ops, unsigned char *buf, int len,
 int reset, int enable);
 
+#ifdef CONFIG_MODULES
 static void process_mod_list(struct list_head *head, struct ftrace_ops *ops,
 char *mod, bool enable)
 {
@@ -4068,6 +4069,7 @@ static void process_cached_mods(const char *mod_name)
 
kfree(mod);
 }
+#endif
 
 /*
  * We register the module command as a template to show others how
-- 
2.9.0

Re: [GIT PULL] scheduler changes for v4.13

[Ingo Molnar]

* Florian Fainelli  wrote:

> On 07/03/2017 01:39 AM, Ingo Molnar wrote:
> > Linus,
> > 
> > Please pull the latest sched-core-for-linus git tree from:
> > 
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > sched-core-for-linus
> > 
> ># HEAD: 72298e5c92c50edd8cb7cfda4519483ce65fa166 sched/cputime: Refactor 
> > the cputime_adjust() code
> > 
> > The main changes in this cycle were:
> > 
> >  - Add the SYSTEM_SCHEDULING bootup state to move various scheduler debug 
> > checks 
> >earlier into the bootup. This turns silent and sporadically deadly bugs 
> > into
> >nice, deterministic splats. Fix some of the splats that triggered.
> >(Thomas Gleixner)
> > 
> >  - A round of restructuring and refactoring of the load-balancing and 
> > topology 
> >code (Peter Zijlstra)
> > 
> >  - Another round of consolidating ~20 of incremental scheduler code 
> > history: this 
> >time in terms of wait-queue nomenclature. (I didn't get much feedback on 
> > these 
> >renaming patches, and we can still easily change any names I might have 
> >misplaced, so if anyone hates a new name, please holler and I'll fix it.)
> >(Ingo Molnar)
> 
> This commit ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f ("sched/wait:
> Rename wait_queue_t => wait_queue_entry_t") ends up renaming the
> autofs_packet_missing, autofs_packet_expire_multi and autofs_v5_packet
> member previously named wait_queue_entry to wait_queue_entry_token. Was
> it intentional to force an user space build breakage when building
> against v4.13-rc headers for autofs headers?

Nope - mind sending a tested patch?

Thanks,

Ingo

Re: [linux-sunxi] Re: [PATCH 1/2] pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver

[Maxime Ripard]

On Fri, Jul 07, 2017 at 07:21:19AM +0800, icen...@aosc.io wrote:
> 在 2017-07-07 04:46，Maxime Ripard 写道：
> > Hi,
> > 
> > On Thu, Jul 06, 2017 at 10:28:21PM +0800, Icenowy Zheng wrote:
> > > The PH16 pin has a function with mux id 0x5, which is the DET pin of
> > > the
> > > "sim" (smart card reader) IP block.
> > > 
> > > This function is missing both in the old A10 and A20 drivers, so it's
> > > not found during the merge of these two drivers.
> > > 
> > > Add it to the driver. As we now merged A20 pinctrl driver to the A10
> > > one, we need to only fix the A10 driver now.
> > > 
> > > Signed-off-by: Icenowy Zheng 
> > 
> > I'm not sure what you mean there. It's not mentionned in the A10
> > datasheet, and neither in the A20. Where did you get that info from?
> 
> It's mentioned in all newest datasheets: "A10 Datasheet V1.70.pdf" and
> "A20 Datasheet V1.41 20131230.pdf".

Mentionning that in the commit log would be great.

Where did you find those?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] autofs: Revert wait_queue_t => wait_queue_entry_t rename

[Ingo Molnar]

* Florian Fainelli  wrote:

> This reverts commit ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f "("sched/wait:
> Rename wait_queue_t => wait_queue_entry_t") as far as the autofs user API
> structures are concerned since that would break user space build against such
> kernel headers.
> 
> Fixes: ac6424b981bc ("sched/wait: Rename wait_queue_t => wait_queue_entry_t")
> Signed-off-by: Florian Fainelli 

Acked-by: Ingo Molnar 

Thanks,

Ingo

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Peter Zijlstra]

On Mon, Jul 10, 2017 at 09:38:30AM +0800, Aubrey Li wrote:
> We measured 3%~5% improvemnt in disk IO workload, and 8%~20% improvement in
> network workload. 

Argh, what a mess :/

So how much of the gain is simply due to skipping NOHZ? Mike used to
carry a patch that would throttle NOHZ. And that is a _far_ smaller and
simpler patch to do.

Re: [PATCH 2/4] kasan: added functions for unpoisoning stack variables

[Dmitry Vyukov]

On Fri, Jul 7, 2017 at 12:01 AM, Greg Hackmann  wrote:
> From: Alexander Potapenko 
>
> As a code-size optimization, LLVM builds since r279383 may
> bulk-manipulate the shadow region when (un)poisoning large memory
> blocks.  This requires new callbacks that simply do an uninstrumented
> memset().
>
> This fixes linking the Clang-built kernel when using KASAN.
>
> Signed-off-by: Alexander Potapenko 
> [ghackm...@google.com: fix memset() parameters, and tweak
>  commit message to describe new callbacks]
> Signed-off-by: Greg Hackmann 
> ---
>  mm/kasan/kasan.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
> index 892b626f564b..89911e5c69f9 100644
> --- a/mm/kasan/kasan.c
> +++ b/mm/kasan/kasan.c
> @@ -828,6 +828,21 @@ void __asan_allocas_unpoison(const void *stack_top, 
> const void *stack_bottom)
>  }
>  EXPORT_SYMBOL(__asan_allocas_unpoison);
>
> +/* Emitted by the compiler to [un]poison local variables. */
> +#define DEFINE_ASAN_SET_SHADOW(byte) \
> +   void __asan_set_shadow_##byte(const void *addr, size_t size)\
> +   {   \
> +   __memset((void *)addr, 0x##byte, size); \
> +   }   \
> +   EXPORT_SYMBOL(__asan_set_shadow_##byte)
> +
> +DEFINE_ASAN_SET_SHADOW(00);
> +DEFINE_ASAN_SET_SHADOW(f1);
> +DEFINE_ASAN_SET_SHADOW(f2);
> +DEFINE_ASAN_SET_SHADOW(f3);
> +DEFINE_ASAN_SET_SHADOW(f5);
> +DEFINE_ASAN_SET_SHADOW(f8);
> +
>  #ifdef CONFIG_MEMORY_HOTPLUG
>  static int kasan_mem_notifier(struct notifier_block *nb,
> unsigned long action, void *data)

Reviewed-by: Dmitry Vyukov 

Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

[Eric W. Biederman]

"Reshetova, Elena"  writes:

2>> Elena Reshetova  writes:
>> 
>> > refcount_t type and corresponding API should be
>> > used instead of atomic_t when the variable is used as
>> > a reference counter. This allows to avoid accidental
>> > refcounter overflows that might lead to use-after-free
>> > situations.
>> 
>> In this patch you can see all of the uses of the count.
>> What accidental refcount overflows are possible?
>
> Even if one can guarantee and prove that in the current implementation
> there are no overflows possible, we can't say that for
> sure for any future implementation. Bugs might always happen
> unfortunately, but if we convert the refcounter to a safer
> type we can be sure that overflows are not possible. 
>
> Does it make sense to you?

Not for code that is likely to remain unchanged for a decade no.

This looks like a large set of unautomated changes without any real
thought put into it.  That almost always results in a typo somewhere
that breaks things.

So there is no benefit to the code, and a non-zero chance that there
will be a typo breaking the code.

All to harden the code for an unlikely future when the code is
updated with a full test cycle and people paying attention.

Introduce a bug now to avoid a bug in the future.  That seems like a
very poor engineering trade off.

Eric

Re: [PATCH v2 00/28] kbuild: complete UAPI de-coupling and cleanup scripts/Makefile.headersinst

[Sam Ravnborg]

Hi Masahiro.

On Mon, Jul 10, 2017 at 03:32:32AM +0900, Masahiro Yamada wrote:
> In v4.12-rc1, we had a big progress for headers_install.
> All (and only) headers under UAPI directories are exported.
> However, asm-generic wrappers are still exceptions because
> most of arch/*/include/asm/Kbuild include "generic-y" for
> exported headers.  As a result, many of generic-wrappers to be
> exported are generated outside UAPI directories.
> 
> To finish de-coupling UAPI, "generic-y" for exported headers
> should be moved to arch/*/include/uapi/asm/Kbuild.
> 
> With those cleanups, the logic of headers_install will become
> even simpler.  UAPI will be completely self-contained.
> 
> This series is based on:
> commit 19bf2e0ef18ec8a7284ecc83459a2664cb885cd5
> 
> Changes for v2:
>   - rebase on the latest in the mainline in order to avoid merge conflicts

Series looks good.

In several of your patches assignments are moved to the arch
specific uapi file, but the same assignment are already present in
include/uapi/asm-generic/Kbuild.asm so the assignment is redundant.

For example:
$ARCH uapi Kbuild:
generic-y += errno.h

uapi/asm-generic Kbuild:
mandatory-y += errno.h

As this patch-set is touching all arch files this
could be a good opportunity to clean this up too.

But maybe mandatory-y and generic-y do something different,
and both are needed. In wich cases all is good.

Sam

Re: [PATCH 3/4] kasan: support LLVM-style asan parameters

[Dmitry Vyukov]

On Fri, Jul 7, 2017 at 12:01 AM, Greg Hackmann  wrote:
> Use cc-option to figure out whether the compiler's sanitizer uses
> LLVM-style parameters ("-mllvm -asan-foo=bar") or GCC-style parameters
> ("--param asan-foo=bar").
>
> Signed-off-by: Greg Hackmann 
> ---
>  scripts/Makefile.kasan | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.kasan b/scripts/Makefile.kasan
> index 9576775a86f6..b66ae4b4546b 100644
> --- a/scripts/Makefile.kasan
> +++ b/scripts/Makefile.kasan
> @@ -9,11 +9,19 @@ KASAN_SHADOW_OFFSET ?= $(CONFIG_KASAN_SHADOW_OFFSET)
>
>  CFLAGS_KASAN_MINIMAL := -fsanitize=kernel-address
>
> -CFLAGS_KASAN := $(call cc-option, -fsanitize=kernel-address \
> +CFLAGS_KASAN_GCC := $(call cc-option, -fsanitize=kernel-address \
> -fasan-shadow-offset=$(KASAN_SHADOW_OFFSET) \
> --param asan-stack=1 --param asan-globals=1 \
> --param 
> asan-instrumentation-with-call-threshold=$(call_threshold))
>
> +CFLAGS_KASAN_LLVM := $(call cc-option, -fsanitize=kernel-address \
> +   -mllvm -asan-mapping-offset=$(KASAN_SHADOW_OFFSET) \
> +   -mllvm -asan-stack=1 -mllvm -asan-globals=1 \
> +   -mllvm -asan-use-after-scope=1 \
> +   -mllvm 
> -asan-instrumentation-with-call-threshold=$(call_threshold))
> +
> +CFLAGS_KASAN := $(CFLAGS_KASAN_GCC) $(CFLAGS_KASAN_LLVM)
> +
>  ifeq ($(call cc-option, $(CFLAGS_KASAN_MINIMAL) -Werror),)
> ifneq ($(CONFIG_COMPILE_TEST),y)
>  $(warning Cannot use CONFIG_KASAN: \

Reviewed-by: Dmitry Vyukov 

Re: [PATCH 4/4] kasan: add compiler support for clang

[Dmitry Vyukov]

On Fri, Jul 7, 2017 at 12:01 AM, Greg Hackmann  wrote:
> For now we can hard-code ASAN ABI level 5, since historical clang builds
> can't build the kernel anyway.  We also need to emulate gcc's
> __SANITIZE_ADDRESS__ flag, or memset() calls won't be instrumented.
>
> Signed-off-by: Greg Hackmann 
> ---
>  include/linux/compiler-clang.h | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> index d614c5ea1b5e..8153f793b22a 100644
> --- a/include/linux/compiler-clang.h
> +++ b/include/linux/compiler-clang.h
> @@ -23,3 +23,13 @@
>   */
>  #undef inline
>  #define inline inline __attribute__((unused)) notrace
> +
> +/* all clang versions usable with the kernel support KASAN ABI version 5
> + */
> +#define KASAN_ABI_VERSION 5
> +
> +/* emulate gcc's __SANITIZE_ADDRESS__ flag
> + */
> +#if __has_feature(address_sanitizer)
> +#define __SANITIZE_ADDRESS__
> +#endif


Reviewed-by: Dmitry Vyukov 

[PATCH] [media] platform: video-mux: fix Kconfig dependency

[Arnd Bergmann]

When CONFIG_V4L2 is built as a loadable module, the new video mux driver
fails to link as built-in code:

drivers/media/platform/video-mux.o: In function `video_mux_remove':
video-mux.c:(.text+0x24): undefined reference to `v4l2_async_unregister_subdev'
drivers/media/platform/video-mux.o: In function `video_mux_probe':
video-mux.c:(.text+0x800): undefined reference to `v4l2_subdev_init'
video-mux.c:(.text+0xa10): undefined reference to `v4l2_async_register_subdev'

This makes it use the same Kconfig dependency as all the other users of
the VIDEO_V4L2_SUBDEV_API symbol.

Fixes: 68803ad4522f ("[media] platform: add video-multiplexer subdevice driver")
Cc: Sascha Hauer 
Cc: Philipp Zabel 
Signed-off-by: Arnd Bergmann 
---
Cc: Russell King 
Cc: Steve Longerbeam 
Cc: Sakari Ailus 
Cc: Pavel Machek 
---
 drivers/media/platform/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index fb1fa0b82077..20179eb8f31e 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -76,7 +76,7 @@ config VIDEO_M32R_AR_M64278
 
 config VIDEO_MUX
tristate "Video Multiplexer"
-   depends on OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+   depends on VIDEO_V4L2 && OF && VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
select REGMAP
help
  This driver provides support for N:1 video bus multiplexers.
-- 
2.9.0

Re: [PATCH 4/4] thermal: Add Tegra BPMP thermal sensor driver

[Mikko Perttunen]

On 01.07.2017 05:53, Eduardo Valentin wrote:

Hey Mikko,

Sorry for the late answer,


Likewise,



On Fri, Jun 16, 2017 at 02:28:25PM +0300, Mikko Perttunen wrote:

On Tegra186, the BPMP (Boot and Power Management Processor) exposes an
interface to thermal sensors on the system-on-chip. This driver
implements access to the interface. It supports reading the
temperature, setting trip points and receiving notification of a
tripped trip point.

Signed-off-by: Mikko Perttunen 
---
 drivers/thermal/Makefile |   2 +-
 drivers/thermal/tegra/Kconfig|   7 +
 drivers/thermal/tegra/Makefile   |   3 +-
 drivers/thermal/tegra/bpmp-thermal.c | 253 +++
 4 files changed, 263 insertions(+), 2 deletions(-)
 create mode 100644 drivers/thermal/tegra/bpmp-thermal.c

diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 094d7039981c..c03dccdba7b8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -54,7 +54,7 @@ obj-$(CONFIG_INTEL_BXT_PMIC_THERMAL) += 
intel_bxt_pmic_thermal.o
 obj-$(CONFIG_INTEL_PCH_THERMAL)+= intel_pch_thermal.o
 obj-$(CONFIG_ST_THERMAL)   += st/
 obj-$(CONFIG_QCOM_TSENS)   += qcom/
-obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra/
+obj-y  += tegra/
 obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
 obj-$(CONFIG_MTK_THERMAL)  += mtk_thermal.o
 obj-$(CONFIG_GENERIC_ADC_THERMAL)  += thermal-generic-adc.o
diff --git a/drivers/thermal/tegra/Kconfig b/drivers/thermal/tegra/Kconfig
index cec586ec7e4b..36e4b03bb98b 100644
--- a/drivers/thermal/tegra/Kconfig
+++ b/drivers/thermal/tegra/Kconfig
@@ -10,4 +10,11 @@ config TEGRA_SOCTHERM
  zones to manage temperatures. This option is also required for the
  emergency thermal reset (thermtrip) feature to function.

+config TEGRA_BPMP_THERMAL
+   tristate "Tegra BPMP thermal sensing"
+   depends on TEGRA_BPMP


Can you add COMPILE_TEST support here?


Sure.




+   help
+Enable this option for support for sensing system temperature of NVIDIA
+Tegra systems-on-chip with the BPMP coprocessor (Tegra186).
+
 endmenu
diff --git a/drivers/thermal/tegra/Makefile b/drivers/thermal/tegra/Makefile
index 1ce1af2cf0f5..757abcd1feaf 100644
--- a/drivers/thermal/tegra/Makefile
+++ b/drivers/thermal/tegra/Makefile
@@ -1,4 +1,5 @@
-obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra-soctherm.o
+obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra-soctherm.o
+obj-$(CONFIG_TEGRA_BPMP_THERMAL)   += bpmp-thermal.o

 tegra-soctherm-y   := soctherm.o soctherm-fuse.o
 tegra-soctherm-$(CONFIG_ARCH_TEGRA_124_SOC)+= tegra124-soctherm.o
diff --git a/drivers/thermal/tegra/bpmp-thermal.c 
b/drivers/thermal/tegra/bpmp-thermal.c
new file mode 100644
index ..3465a201d1ac
--- /dev/null
+++ b/drivers/thermal/tegra/bpmp-thermal.c
@@ -0,0 +1,253 @@
+/*
+ * Copyright (c) 2015-2017, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Author:
+ * Mikko Perttunen 
+ * Aapo Vienamo
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct tegra_bpmp_thermal_zone {
+   struct tegra_bpmp_thermal *tegra;
+   struct thermal_zone_device *tzd;
+   struct work_struct tz_device_update_work;
+   unsigned int idx;
+};
+
+struct tegra_bpmp_thermal {
+   struct device *dev;
+   struct tegra_bpmp *bpmp;
+   unsigned int num_zones;
+   struct tegra_bpmp_thermal_zone *zones;
+};
+
+static int tegra_bpmp_thermal_get_temp(void *data, int *out_temp)
+{
+   struct tegra_bpmp_thermal_zone *zone = data;
+   struct mrq_thermal_host_to_bpmp_request req;
+   union mrq_thermal_bpmp_to_host_response reply;
+   struct tegra_bpmp_message msg;
+   int err;
+
+   memset(&req, 0, sizeof(req));
+   req.type = CMD_THERMAL_GET_TEMP;
+   req.get_temp.zone = zone->idx;
+
+   memset(&msg, 0, sizeof(msg));
+   msg.mrq = MRQ_THERMAL;
+   msg.tx.data = &req;
+   msg.tx.size = sizeof(req);
+   msg.rx.data = &reply;
+   msg.rx.size = sizeof(reply);
+
+   err = tegra_bpmp_transfer(zone->tegra->bpmp, &msg);
+   if (err)
+   return err;
+
+   *out_temp = reply.get_temp.temp;
+
+   return 0;
+}
+
+static int tegra_bpmp_thermal_set_trips(void *data, int low, int high)
+{
+   struct tegra_bpmp_thermal_zone *zone = data;
+   struct mrq_thermal_host_to_bpmp_request req;
+   struct tegra_bpmp_message msg;
+
+   memset(

[PATCH] ata: fix gemini Kconfig dependencies

[Arnd Bergmann]

We cannot build the new ftide010 code without also building the faraday
sata bridge driver:

drivers/ata/pata_ftide010.o: In function `pata_ftide010_probe':
pata_ftide010.c:(.text+0x2b8): undefined reference to `gemini_sata_bridge_get'
pata_ftide010.c:(.text+0x32c): undefined reference to `gemini_sata_get_muxmode'
pata_ftide010.c:(.text+0x358): undefined reference to 
`gemini_sata_bridge_enabled'
drivers/ata/pata_ftide010.o: In function `pata_ftide010_gemini_port_stop':
pata_ftide010.c:(.text+0x520): undefined reference to `gemini_sata_stop_bridge'
drivers/ata/pata_ftide010.o: In function `pata_ftide010_gemini_port_start':
pata_ftide010.c:(.text+0x5bc): undefined reference to `gemini_sata_start_bridge'

This adjusts the Kconfig dependencies accordingly.

Fixes: be4e456ed3a5 ("ata: Add driver for Faraday Technology FTIDE010")
Signed-off-by: Arnd Bergmann 
---
 drivers/ata/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 948fc86980a1..363fc5330c21 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -215,7 +215,7 @@ config SATA_FSL
 
 config SATA_GEMINI
tristate "Gemini SATA bridge support"
-   depends on PATA_FTIDE010
+   depends on ARCH_GEMINI || COMPILE_TEST
default ARCH_GEMINI
help
  This enabled support for the FTIDE010 to SATA bridge
@@ -613,7 +613,7 @@ config PATA_FTIDE010
tristate "Faraday Technology FTIDE010 PATA support"
depends on OF
depends on ARM
-   default ARCH_GEMINI
+   depends on SATA_GEMINI
help
  This option enables support for the Faraday FTIDE010
  PATA controller found in the Cortina Gemini SoCs.
-- 
2.9.0

Re: [PATCH] autofs: Revert wait_queue_t => wait_queue_entry_t rename

[kbuild test robot]

Hi Florian,

[auto build test ERROR on linus/master]
[cannot apply to v4.12]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Florian-Fainelli/autofs-Revert-wait_queue_t-wait_queue_entry_t-rename/20170710-140256
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs/autofs4/waitq.c: In function 'autofs4_notify_daemon':
>> fs/autofs4/waitq.c:123:5: error: 'struct autofs_packet_missing' has no 
>> member named 'wait_queue_entry_token'; did you mean 'wait_queue_token'?
  mp->wait_queue_entry_token = wq->wait_queue_entry_token;
^~
>> fs/autofs4/waitq.c:136:5: error: 'struct autofs_packet_expire_multi' has no 
>> member named 'wait_queue_entry_token'; did you mean 'wait_queue_token'?
  ep->wait_queue_entry_token = wq->wait_queue_entry_token;
^~
>> fs/autofs4/waitq.c:156:9: error: 'struct autofs_v5_packet' has no member 
>> named 'wait_queue_entry_token'; did you mean 'wait_queue_token'?
  packet->wait_queue_entry_token = wq->wait_queue_entry_token;
^~

vim +123 fs/autofs4/waitq.c


:: The code at line 123 was first introduced by commit
:: ac6424b981bce1c4bc55675c6ce11bfe1bbfa64f sched/wait: Rename wait_queue_t 
=> wait_queue_entry_t

:: TO: Ingo Molnar 
:: CC: Ingo Molnar 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 1/8] exec: Correct comments about "point of no return"

[Eric W. Biederman]

But you miss it.

The "point of no return" is the call to de_thread.  Or aguably anything in
flush_old_exec.  Once anything in the current task is modified you can't
return an error.

It very much does not have anything to do with brpm.It has
everything to do with current.


> diff --git a/fs/exec.c b/fs/exec.c
> index 904199086490..7842ae661e34 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1285,7 +1285,14 @@ int flush_old_exec(struct linux_binprm * bprm)
>   if (retval)
>   goto out;
>  
> - bprm->mm = NULL;/* We're using it now */
> + /*
> +  * After clearing bprm->mm (to mark that current is using the
> +  * prepared mm now), we are at the point of no return. If
> +  * anything from here on returns an error, the check in
> +  * search_binary_handler() will kill current (since the mm has
> +  * been replaced).
> +  */
> + bprm->mm = NULL;
>  
>   set_fs(USER_DS);
>   current->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD |

Eric

Re: [PATCH 1/3 v2] KVM: vmx: Enable VMFUNCs

[David Hildenbrand]

>  /*
>   * The exit handlers return 1 if the exit was handled fully and guest 
> execution
>   * may resume.  Otherwise they set the kvm_run parameter to indicate what 
> needs
> @@ -7790,6 +7806,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct 
> kvm_vcpu *vcpu) = {
>   [EXIT_REASON_XSAVES]  = handle_xsaves,
>   [EXIT_REASON_XRSTORS] = handle_xrstors,
>   [EXIT_REASON_PML_FULL]= handle_pml_full,
> + [EXIT_REASON_VMFUNC]  = handle_vmfunc,
>   [EXIT_REASON_PREEMPTION_TIMER]= handle_preemption_timer,
>  };
>  
> @@ -8111,6 +8128,9 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu 
> *vcpu)
>   case EXIT_REASON_PML_FULL:
>   /* We emulate PML support to L1. */
>   return false;
> + case EXIT_REASON_VMFUNC:
> + /* VM functions are emulated through L2->L0 vmexits. */
> + return false;

This would fit better into the second patch.

>   default:
>   return true;
>   }
> 


Looks good to me.

-- 

Thanks,

David

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

[Ganapatrao Kulkarni]

Hi Marc,

On Mon, Jul 3, 2017 at 8:23 PM, Marc Zyngier  wrote:
> Hi Shanker,
>
> On 03/07/17 15:24, Shanker Donthineni wrote:
>> Hi Marc,
>>
>> On 06/30/2017 03:51 AM, Marc Zyngier wrote:
>>> On 30/06/17 04:01, Ganapatrao Kulkarni wrote:
 On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni
  wrote:
> Hi Shanker,
>
> On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni
>  wrote:
>> The NUMA node information is visible to ITS driver but not being used
>> other than handling errata. This patch allocates the memory for ITS
>> tables from the corresponding NUMA node using the appropriate NUMA
>> aware functions.

 IMHO, the description would have been more constructive?

 "All ITS tables are mapped by default to NODE 0 memory.
 Adding changes to allocate memory from respective NUMA NODES of ITS 
 devices.
 This will optimize tables access and avoids unnecessary inter-node 
 traffic."
>>>
>>> But more importantly, I'd like to see figures showing the actual benefit
>>> of this per-node allocation. Given that both of you guys have access to
>>> such platforms, please show me the numbers!
>>>
>>
>> I'll share the actual results which shows the improvement whenever
>> available on our next chips. Current version of Qualcomm qdf2400 doesn't
>> support multi socket configuration to capture results and share with you.
>>
>> Do you see any other issues with this patch apart from the performance
>> improvements. I strongly believe this brings the noticeable improvement
>> in numbers on systems where it has multi node memory/CPU configuration.
>
> I agree that it *could* show an improvement, but it very much depends on
> how often the ITS misses in its caches. For this kind of patches, I want
> to see two things:
>
> 1) It brings a measurable benefit on NUMA platforms

Did some measurement of interrupt response time for LPIs and we don't
see any major
improvement due to caching of Tables. However, we have seen
improvements of around 5%.
IMO, we should merge this patch to have NUMA aware allocations and to
avoid unwanted inter-node transactions.

Tested-by: Ganapatrao Kulkarni 

> 2) it doesn't adversely impact non-NUMA systems
AFAIK, no impact on non-NUMA and on single node NUMA systems.

>
> I can deal with (2), but I have no way of evaluating (1), mostly for the
> lack of an infrastructure exercising multiple ITSs at the same time.
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...

thanks
Ganapat

[PATCH] drivers/staging/wilc1000: fix sparse warning: right shift by bigger than source value

[Rui Teng]

This patch sets memory to zero directly to avoid unnecessary shift and
bitwise operations on bool type, which can fix a sparse warning and also
improve performance.

Signed-off-by: Rui Teng 
---
 drivers/staging/wilc1000/host_interface.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 2568dfc15181..036c5c19a016 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -2416,10 +2416,9 @@ static void Handle_SetMulticastFilter(struct wilc_vif 
*vif,
goto ERRORHANDLER;
 
pu8CurrByte = wid.val;
-   *pu8CurrByte++ = (strHostIfSetMulti->enabled & 0xFF);
-   *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 8) & 0xFF);
-   *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 16) & 0xFF);
-   *pu8CurrByte++ = ((strHostIfSetMulti->enabled >> 24) & 0xFF);
+   memset(pu8CurrByte, 0, 4);
+   *pu8CurrByte = (strHostIfSetMulti->enabled & 0xFF);
+   pu8CurrByte += 4;
 
*pu8CurrByte++ = (strHostIfSetMulti->cnt & 0xFF);
*pu8CurrByte++ = ((strHostIfSetMulti->cnt >> 8) & 0xFF);
-- 
2.11.0

Re: [PATCH v2 2/8] exec: Move security_bprm_secureexec() earlier

[Eric W. Biederman]

Kees Cook  writes:

> There are several places where exec needs to know if a privilege-gain has
> happened. These should be using the results of security_bprm_secureexec()
> but it is getting (needlessly) called very late.

It is hard to tell at a glance but I believe this introduces a
regression.

cap_bprm_set_creds is currently called before cap_bprm_secureexec and
it has a number of cases such as no_new_privs and ptrace that can result
in some of the precomputed credential changes not happening.

Without accounting for that I believe your cap_bprm_securexec now
returns a postive value too early.

> Instead, move this earlier in the exec code, to the start of the point
> of no return in setup_new_exec(). Here, the new creds have already
> been calculated (and stored in bprm->cred), which is normally what
> security_bprm_secureexec() wants to examine. Since it's moved earlier,
> LSMs hooking bprm_secureexec() need to be adjusted to use the creds in
> bprm:
>
> $ git grep LSM_HOOK_INIT.*bprm_secureexec
> apparmor/lsm.c:LSM_HOOK_INIT(bprm_secureexec, apparmor_bprm_secureexec),
> commoncap.c:   LSM_HOOK_INIT(bprm_secureexec, cap_bprm_secureexec),
> selinux/hooks.c:   LSM_HOOK_INIT(bprm_secureexec, selinux_bprm_secureexec),
> smack/smack_lsm.c: LSM_HOOK_INIT(bprm_secureexec, smack_bprm_secureexec),
>
> AppArmor does not access creds in apparmor_bprm_secureexec.
>
> Capabilities needed to be adjusted to use bprm creds.
>
> SELinux needed to be adjusted to use bprm creds for the security structure.
>
> Smack needed to be adjusted to use bprm creds for the security structure.
>
> The result of the bprm_secureexec() hook is saved in a new bprm field
> "secureexec" so it can be queried later (just AT_SECURE currently).
>
> Signed-off-by: Kees Cook 
> ---
>  fs/binfmt_elf.c| 2 +-
>  fs/binfmt_elf_fdpic.c  | 2 +-
>  fs/exec.c  | 5 +
>  include/linux/binfmts.h| 3 ++-
>  include/linux/lsm_hooks.h  | 3 ++-
>  security/commoncap.c   | 4 +---
>  security/selinux/hooks.c   | 2 +-
>  security/smack/smack_lsm.c | 2 +-
>  8 files changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
> index 5075fd5c62c8..7f6ec4dac13d 100644
> --- a/fs/binfmt_elf.c
> +++ b/fs/binfmt_elf.c
> @@ -254,7 +254,7 @@ create_elf_tables(struct linux_binprm *bprm, struct 
> elfhdr *exec,
>   NEW_AUX_ENT(AT_EUID, from_kuid_munged(cred->user_ns, cred->euid));
>   NEW_AUX_ENT(AT_GID, from_kgid_munged(cred->user_ns, cred->gid));
>   NEW_AUX_ENT(AT_EGID, from_kgid_munged(cred->user_ns, cred->egid));
> - NEW_AUX_ENT(AT_SECURE, security_bprm_secureexec(bprm));
> + NEW_AUX_ENT(AT_SECURE, bprm->secureexec);
>   NEW_AUX_ENT(AT_RANDOM, (elf_addr_t)(unsigned long)u_rand_bytes);
>  #ifdef ELF_HWCAP2
>   NEW_AUX_ENT(AT_HWCAP2, ELF_HWCAP2);
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index cf93a4fad012..5aa9199dfb13 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -650,7 +650,7 @@ static int create_elf_fdpic_tables(struct linux_binprm 
> *bprm,
>   NEW_AUX_ENT(AT_EUID,(elf_addr_t) from_kuid_munged(cred->user_ns, 
> cred->euid));
>   NEW_AUX_ENT(AT_GID, (elf_addr_t) from_kgid_munged(cred->user_ns, 
> cred->gid));
>   NEW_AUX_ENT(AT_EGID,(elf_addr_t) from_kgid_munged(cred->user_ns, 
> cred->egid));
> - NEW_AUX_ENT(AT_SECURE,  security_bprm_secureexec(bprm));
> + NEW_AUX_ENT(AT_SECURE,  bprm->secureexec);
>   NEW_AUX_ENT(AT_EXECFN,  bprm->exec);
>  
>  #ifdef ARCH_DLINFO
> diff --git a/fs/exec.c b/fs/exec.c
> index 7842ae661e34..b92e37fb53aa 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1337,6 +1337,11 @@ EXPORT_SYMBOL(would_dump);
>  
>  void setup_new_exec(struct linux_binprm * bprm)
>  {
> + if (security_bprm_secureexec(bprm)) {
> + /* Record for AT_SECURE. */
> + bprm->secureexec = 1;
> + }
> +
>   arch_pick_mmap_layout(current->mm);
>  
>   current->sas_ss_sp = current->sas_ss_size = 0;
> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
> index 05488da3aee9..1afaa303cad0 100644
> --- a/include/linux/binfmts.h
> +++ b/include/linux/binfmts.h
> @@ -27,9 +27,10 @@ struct linux_binprm {
>   unsigned int
>   cred_prepared:1,/* true if creds already prepared (multiple
>* preps happen for interpreters) */
> - cap_effective:1;/* true if has elevated effective capabilities,
> + cap_effective:1,/* true if has elevated effective capabilities,
>* false if not; except for init which inherits
>* its parent's caps anyway */
> + secureexec:1;   /* true when gaining privileges */
>  #ifdef __alpha__
>   unsigned int taso:1;
>  #endif
> diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
> index 080f34e66017..d1bd24fb4a33 100644
> --- a/include/linux/lsm_hooks.h
> +++ b

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

[Marc Zyngier]

On 10/07/17 09:48, Ganapatrao Kulkarni wrote:
> Hi Marc,
> 
> On Mon, Jul 3, 2017 at 8:23 PM, Marc Zyngier  wrote:
>> Hi Shanker,
>>
>> On 03/07/17 15:24, Shanker Donthineni wrote:
>>> Hi Marc,
>>>
>>> On 06/30/2017 03:51 AM, Marc Zyngier wrote:
 On 30/06/17 04:01, Ganapatrao Kulkarni wrote:
> On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni
>  wrote:
>> Hi Shanker,
>>
>> On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni
>>  wrote:
>>> The NUMA node information is visible to ITS driver but not being used
>>> other than handling errata. This patch allocates the memory for ITS
>>> tables from the corresponding NUMA node using the appropriate NUMA
>>> aware functions.
>
> IMHO, the description would have been more constructive?
>
> "All ITS tables are mapped by default to NODE 0 memory.
> Adding changes to allocate memory from respective NUMA NODES of ITS 
> devices.
> This will optimize tables access and avoids unnecessary inter-node 
> traffic."

 But more importantly, I'd like to see figures showing the actual benefit
 of this per-node allocation. Given that both of you guys have access to
 such platforms, please show me the numbers!

>>>
>>> I'll share the actual results which shows the improvement whenever
>>> available on our next chips. Current version of Qualcomm qdf2400 doesn't
>>> support multi socket configuration to capture results and share with you.
>>>
>>> Do you see any other issues with this patch apart from the performance
>>> improvements. I strongly believe this brings the noticeable improvement
>>> in numbers on systems where it has multi node memory/CPU configuration.
>>
>> I agree that it *could* show an improvement, but it very much depends on
>> how often the ITS misses in its caches. For this kind of patches, I want
>> to see two things:
>>
>> 1) It brings a measurable benefit on NUMA platforms
> 
> Did some measurement of interrupt response time for LPIs and we don't
> see any major
> improvement due to caching of Tables. However, we have seen
> improvements of around 5%.

An improvement of what exactly?

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

[Ganapatrao Kulkarni]

On Mon, Jul 10, 2017 at 2:36 PM, Marc Zyngier  wrote:
> On 10/07/17 09:48, Ganapatrao Kulkarni wrote:
>> Hi Marc,
>>
>> On Mon, Jul 3, 2017 at 8:23 PM, Marc Zyngier  wrote:
>>> Hi Shanker,
>>>
>>> On 03/07/17 15:24, Shanker Donthineni wrote:
 Hi Marc,

 On 06/30/2017 03:51 AM, Marc Zyngier wrote:
> On 30/06/17 04:01, Ganapatrao Kulkarni wrote:
>> On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni
>>  wrote:
>>> Hi Shanker,
>>>
>>> On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni
>>>  wrote:
 The NUMA node information is visible to ITS driver but not being used
 other than handling errata. This patch allocates the memory for ITS
 tables from the corresponding NUMA node using the appropriate NUMA
 aware functions.
>>
>> IMHO, the description would have been more constructive?
>>
>> "All ITS tables are mapped by default to NODE 0 memory.
>> Adding changes to allocate memory from respective NUMA NODES of ITS 
>> devices.
>> This will optimize tables access and avoids unnecessary inter-node 
>> traffic."
>
> But more importantly, I'd like to see figures showing the actual benefit
> of this per-node allocation. Given that both of you guys have access to
> such platforms, please show me the numbers!
>

 I'll share the actual results which shows the improvement whenever
 available on our next chips. Current version of Qualcomm qdf2400 doesn't
 support multi socket configuration to capture results and share with you.

 Do you see any other issues with this patch apart from the performance
 improvements. I strongly believe this brings the noticeable improvement
 in numbers on systems where it has multi node memory/CPU configuration.
>>>
>>> I agree that it *could* show an improvement, but it very much depends on
>>> how often the ITS misses in its caches. For this kind of patches, I want
>>> to see two things:
>>>
>>> 1) It brings a measurable benefit on NUMA platforms
>>
>> Did some measurement of interrupt response time for LPIs and we don't
>> see any major
>> improvement due to caching of Tables. However, we have seen
>> improvements of around 5%.
>
> An improvement of what exactly?

interrupt response time.
>
> M.
> --
> Jazz is not dead. It just smells funny...

thanks
Ganapat

Re: [PATCH v2 00/28] kbuild: complete UAPI de-coupling and cleanup scripts/Makefile.headersinst

[Masahiro Yamada]

Hi Sam,


2017-07-10 17:42 GMT+09:00 Sam Ravnborg :
> Hi Masahiro.
>
> On Mon, Jul 10, 2017 at 03:32:32AM +0900, Masahiro Yamada wrote:
>> In v4.12-rc1, we had a big progress for headers_install.
>> All (and only) headers under UAPI directories are exported.
>> However, asm-generic wrappers are still exceptions because
>> most of arch/*/include/asm/Kbuild include "generic-y" for
>> exported headers.  As a result, many of generic-wrappers to be
>> exported are generated outside UAPI directories.
>>
>> To finish de-coupling UAPI, "generic-y" for exported headers
>> should be moved to arch/*/include/uapi/asm/Kbuild.
>>
>> With those cleanups, the logic of headers_install will become
>> even simpler.  UAPI will be completely self-contained.
>>
>> This series is based on:
>> commit 19bf2e0ef18ec8a7284ecc83459a2664cb885cd5
>>
>> Changes for v2:
>>   - rebase on the latest in the mainline in order to avoid merge conflicts
>
> Series looks good.
>
> In several of your patches assignments are moved to the arch
> specific uapi file, but the same assignment are already present in
> include/uapi/asm-generic/Kbuild.asm so the assignment is redundant.
>
> For example:
> $ARCH uapi Kbuild:
> generic-y += errno.h
>
> uapi/asm-generic Kbuild:
> mandatory-y += errno.h
>
> As this patch-set is touching all arch files this
> could be a good opportunity to clean this up too.
>
> But maybe mandatory-y and generic-y do something different,
> and both are needed. In wich cases all is good.
>

Thanks for your review, and you have a good point.

If neither arch-own header implementation is found
nor generic-y is specified, the build system can automatically generate
generic wrappers for "mandatory" headers.

I also considered of it, but I wanted to take my time.

I simply moved generic-y without introducing any logical change
in order to make this series less controversial.

One point of forcing explicit generic-y might be,
to give arch maintainers an opportunity to judge
if falling back to asm-generic one works or not.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] ARM: dts: at91: sama5d2: fix EBI/NAND controllers declaration

[Nicolas Ferre]

On 07/07/2017 at 15:33, Ludovic Desroches wrote:
> Fix HSMC interrupt ID, PMECC registers and EBI ones.
> 
> Signed-off-by: Ludovic Desroches 

We need the "Fixes" tags (even if it's for 4.13).
We need to take it  for 4.13-final.

Fixes: d9c41bf30cf8 ("ARM: dts: at91: Declare EBI/NAND controllers")
Acked-by: Nicolas Ferre 

Thanks, regards,

> ---
>  arch/arm/boot/dts/sama5d2.dtsi | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index cc06da394366..4fcd5bb219e3 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -303,7 +303,7 @@
>   #size-cells = <1>;
>   atmel,smc = <&hsmc>;
>   reg = <0x1000 0x1000
> -0x4000 0x3000>;
> +0x6000 0x3000>;
>   ranges = <0x0 0x0 0x1000 0x1000
> 0x1 0x0 0x6000 0x1000
> 0x2 0x0 0x7000 0x1000
> @@ -1050,16 +1050,16 @@
>   hsmc: hsmc@f8014000 {
>   compatible = "atmel,sama5d3-smc", "syscon", 
> "simple-mfd";
>   reg = <0xf8014000 0x1000>;
> - interrupts = <5 IRQ_TYPE_LEVEL_HIGH 6>;
> + interrupts = <17 IRQ_TYPE_LEVEL_HIGH 6>;
>   clocks = <&hsmc_clk>;
>   #address-cells = <1>;
>   #size-cells = <1>;
>   ranges;
>  
> - pmecc: ecc-engine@c070 {
> + pmecc: ecc-engine@f8014070 {
>   compatible = "atmel,sama5d2-pmecc";
> - reg = <0xc070 0x490>,
> -   <0xc500 0x100>;
> + reg = <0xf8014070 0x490>,
> +   <0xf8014500 0x100>;
>   };
>   };
>  
> 


-- 
Nicolas Ferre

Re: [PATCH 1/4] arm64: tegra: Add BPMP thermal sensor to Tegra186

[Mikko Perttunen]

On 01.07.2017 02:56, Eduardo Valentin wrote:

On Fri, Jun 16, 2017 at 02:28:22PM +0300, Mikko Perttunen wrote:

This adds the thermal sensor device provided by the BPMP, and the
relevant thermal sensors to the Tegra186 device tree.

Signed-off-by: Mikko Perttunen 
---
 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 48 
 1 file changed, 48 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 5e62e68ac053..5c19ea74da24 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 

 / {
compatible = "nvidia,tegra186";
@@ -444,6 +445,53 @@
#size-cells = <0>;
status = "disabled";
};
+
+   bpmp_thermal: thermal {
+   compatible = "nvidia,tegra186-bpmp-thermal";
+   #thermal-sensor-cells = <1>;
+   };
+   };
+
+   thermal-zones {
+   a57 {
+   polling-delay = <0>;
+   polling-delay-passive = <1000>;
+
+   thermal-sensors =
+   <&bpmp_thermal TEGRA186_BPMP_THERMAL_ZONE_CPU>;
+   };
+
+   denver {
+   polling-delay = <0>;
+   polling-delay-passive = <1000>;
+
+   thermal-sensors =
+   <&bpmp_thermal TEGRA186_BPMP_THERMAL_ZONE_AUX>;
+   };
+
+   gpu {
+   polling-delay = <0>;
+   polling-delay-passive = <1000>;
+
+   thermal-sensors =
+   <&bpmp_thermal TEGRA186_BPMP_THERMAL_ZONE_GPU>;
+   };
+
+   pll {
+   polling-delay = <0>;
+   polling-delay-passive = <1000>;
+
+   thermal-sensors =
+   <&bpmp_thermal TEGRA186_BPMP_THERMAL_ZONE_PLLX>;
+   };
+
+   always_on {
+   polling-delay = <0>;
+   polling-delay-passive = <1000>;
+
+   thermal-sensors =
+   <&bpmp_thermal TEGRA186_BPMP_THERMAL_ZONE_AO>;
+   };


All the above zones are lacking mandatory fields. Please refer to the
thermal binding documentation.


Will fix.




};

timer {
--
2.13.1


--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3 v2] KVM: vmx: Enable VMFUNCs

[Paolo Bonzini]

On 10/07/2017 10:54, David Hildenbrand wrote:
> 
>>  /*
>>   * The exit handlers return 1 if the exit was handled fully and guest 
>> execution
>>   * may resume.  Otherwise they set the kvm_run parameter to indicate what 
>> needs
>> @@ -7790,6 +7806,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct 
>> kvm_vcpu *vcpu) = {
>>  [EXIT_REASON_XSAVES]  = handle_xsaves,
>>  [EXIT_REASON_XRSTORS] = handle_xrstors,
>>  [EXIT_REASON_PML_FULL]= handle_pml_full,
>> +[EXIT_REASON_VMFUNC]  = handle_vmfunc,
>>  [EXIT_REASON_PREEMPTION_TIMER]= handle_preemption_timer,
>>  };
>>  
>> @@ -8111,6 +8128,9 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu 
>> *vcpu)
>>  case EXIT_REASON_PML_FULL:
>>  /* We emulate PML support to L1. */
>>  return false;
>> +case EXIT_REASON_VMFUNC:
>> +/* VM functions are emulated through L2->L0 vmexits. */
>> +return false;
> 
> This would fit better into the second patch.

It depends on how you reason about it.  I put it here because:

- until this patch, EXIT_REASON_VMFUNC should never be generated.  We
don't even know that it exists.

- after this patch, it should still never be generated in nested
scenarios.  However, if it did because of a bug, we're in a better place
to handle it than L1 (because as far as L1 knows, it should never be
generated).

Perhaps this is an argument in favor of changing the default case of
nested_vmx_exit_handled from true to false.

Paolo

>>  default:
>>  return true;
>>  }
>>
> 
> 
> Looks good to me.
> 

Re: [PATCH 2/3 v2] KVM: nVMX: Enable VMFUNC for the L1 hypervisor

[David Hildenbrand]

> @@ -7752,7 +7769,29 @@ static int handle_preemption_timer(struct kvm_vcpu 
> *vcpu)
>  
>  static int handle_vmfunc(struct kvm_vcpu *vcpu)
>  {
> - kvm_queue_exception(vcpu, UD_VECTOR);
> + struct vcpu_vmx *vmx = to_vmx(vcpu);
> + struct vmcs12 *vmcs12;
> + u32 function = vcpu->arch.regs[VCPU_REGS_RAX];
> +
> + /*
> +  * VMFUNC is only supported for nested guests, but we always enable the
> +  * secondary control for simplicity; for non-nested mode, fake that we
> +  * didn't by injecting #UD.
> +  */
> + if (!is_guest_mode(vcpu)) {
> + kvm_queue_exception(vcpu, UD_VECTOR);
> + return 1;
> + }
> +
> + vmcs12 = get_vmcs12(vcpu);
> + if ((vmcs12->vm_function_control & (1 << function)) == 0)

(learned that in c, shifting beyond the type size is undefined)

Should we check for function < 64 here? (as SDM mentions)

> + goto fail;
> + WARN(1, "VMCS12 VM function control should have been zero");
> +
> +fail:

We will never hit the case !nested_cpu_has_vmfunc(vmcs12) here, correct?

> + nested_vmx_vmexit(vcpu, vmx->exit_reason,
> +   vmcs_read32(VM_EXIT_INTR_INFO),
> +   vmcs_readl(EXIT_QUALIFICATION));
>   return 1;
>  }
>  


-- 

Thanks,

David

Re: [PATCH] slub: make sure struct kmem_cache_node is initialized before publication

[Alexander Potapenko]

On Sat, Jul 8, 2017 at 1:18 AM, Christoph Lameter  wrote:
> On Fri, 7 Jul 2017, Andrew Morton wrote:
>
>> On Fri,  7 Jul 2017 10:34:08 +0200 Alexander Potapenko  
>> wrote:
>>
>> > --- a/mm/slub.c
>> > +++ b/mm/slub.c
>> > @@ -3389,8 +3389,8 @@ static int init_kmem_cache_nodes(struct kmem_cache 
>> > *s)
>> > return 0;
>> > }
>> >
>> > -   s->node[node] = n;
>> > init_kmem_cache_node(n);
>> > +   s->node[node] = n;
>> > }
>> > return 1;
>> >  }
>>
>> If this matters then I have bad feelings about free_kmem_cache_nodes():
>
> At creation time the kmem_cache structure is private and no one can run a
> free operation.
>
>> Inviting a use-after-free?  I guess not, as there should be no way
>> to look up these items at this stage.
>
> Right.
>
>> Could the slab maintainers please take a look at these and also have a
>> think about Alexander's READ_ONCE/WRITE_ONCE question?
>
> Was I cced on these?
I've asked Andrew about READ_ONCE privately.
My concern is as follows.
Since unfreeze_partials() sees uninitialized value of n->list_lock, I
was suspecting there's a data race between unfreeze_partials() and
init_kmem_cache_nodes().
If so, reads and writes to s->node[node] must be acquire/release
atomics (not actually READ_ONCE/WRITE_ONCE, but
smp_load_acquire/smp_store_release).




-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Straße, 33
80636 München

Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg

[PATCH v3 1/1] KVM: trigger uevents when starting or stopping a VM

[Claudio Imbrenda]

This patch adds a few lines to the KVM common code to fire a
KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
carries five environment variables:

CREATED indicates how many times a new VM has been created. It is
useful for example to trigger specific actions when the first
VM is started
COUNT indicates how many VMs are currently active. This can be used for
logging or monitoring purposes
PID has the pid of the KVM process that has been started or stopped.
This can be used to perform process-specific tuning.
STATS_PATH contains the path in debugfs to the directory with all the
runtime statistics for this VM. This is useful for performance
monitoring and profiling.
EVENT described the type of event, its value can be either "create" or
"destroy"

Specific udev rules can be then set up in userspace to deal with the
creation or destruction of VMs as needed.

Signed-off-by: Claudio Imbrenda 
---
 virt/kvm/kvm_main.c | 59 +
 1 file changed, 59 insertions(+)

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index f0fe9d0..7c39783 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -130,6 +130,12 @@ EXPORT_SYMBOL_GPL(kvm_rebooting);
 
 static bool largepages_enabled = true;
 
+#define KVM_EVENT_CREATE_VM 0
+#define KVM_EVENT_DESTROY_VM 1
+static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm);
+static unsigned long long kvm_createvm_count;
+static unsigned long long kvm_active_vms;
+
 bool kvm_is_reserved_pfn(kvm_pfn_t pfn)
 {
if (pfn_valid(pfn))
@@ -728,6 +734,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
int i;
struct mm_struct *mm = kvm->mm;
 
+   kvm_uevent_notify_change(KVM_EVENT_DESTROY_VM, kvm);
kvm_destroy_vm_debugfs(kvm);
kvm_arch_sync_events(kvm);
spin_lock(&kvm_lock);
@@ -3196,6 +3203,7 @@ static int kvm_dev_ioctl_create_vm(unsigned long type)
fput(file);
return -ENOMEM;
}
+   kvm_uevent_notify_change(KVM_EVENT_CREATE_VM, kvm);
 
fd_install(r, file);
return r;
@@ -3848,6 +3856,57 @@ static const struct file_operations *stat_fops[] = {
[KVM_STAT_VM]   = &vm_stat_fops,
 };
 
+static void kvm_uevent_notify_change(unsigned int type, struct kvm *kvm)
+{
+   char cbuf[32], abuf[32], pidbuf[32], evbuf[16];
+   const char pathvar[11] = "STATS_PATH=";
+   char *ptr[6] = {cbuf, abuf, pidbuf, NULL, NULL, NULL};
+   char *tmp, *pathbuf;
+   unsigned long long created, active;
+   int idx = 3;
+
+   if (!kvm_dev.this_device || !kvm || !kvm->debugfs_dentry)
+   return;
+
+   spin_lock(&kvm_lock);
+   if (type == KVM_EVENT_CREATE_VM) {
+   kvm_createvm_count++;
+   kvm_active_vms++;
+   } else if (type == KVM_EVENT_DESTROY_VM) {
+   kvm_active_vms--;
+   }
+   created = kvm_createvm_count;
+   active = kvm_active_vms;
+   spin_unlock(&kvm_lock);
+
+   pathbuf = kmalloc(PATH_MAX, GFP_KERNEL);
+   if (pathbuf) {
+   tmp = dentry_path_raw(kvm->debugfs_dentry,
+ pathbuf + sizeof(pathvar),
+ PATH_MAX - sizeof(pathvar));
+   if (!IS_ERR(tmp)) {
+   memcpy(tmp - sizeof(pathvar), pathvar, sizeof(pathvar));
+   ptr[idx++] = tmp - sizeof(pathvar);
+   }
+   }
+   snprintf(cbuf, sizeof(cbuf), "CREATED=%llu", created);
+   snprintf(abuf, sizeof(abuf), "COUNT=%llu", active);
+   snprintf(pidbuf, sizeof(pidbuf), "PID=%s",
+kvm->debugfs_dentry->d_name.name);
+   tmp = strchr(pidbuf, '-');
+   if (tmp)
+   *tmp = '\0';
+   if (type == KVM_EVENT_CREATE_VM) {
+   snprintf(evbuf, sizeof(evbuf), "EVENT=create");
+   ptr[idx++] = evbuf;
+   } else if (type == KVM_EVENT_DESTROY_VM) {
+   snprintf(evbuf, sizeof(evbuf), "EVENT=destroy");
+   ptr[idx++] = evbuf;
+   }
+   kobject_uevent_env(&kvm_dev.this_device->kobj, KOBJ_CHANGE, ptr);
+   kfree(pathbuf);
+}
+
 static int kvm_init_debug(void)
 {
int r = -EEXIST;
-- 
2.7.4

Re: [PATCH 1/3 v2] KVM: vmx: Enable VMFUNCs

[Paolo Bonzini]

On 10/07/2017 11:20, David Hildenbrand wrote:
>> Perhaps this is an argument in favor of changing the default case of
>> nested_vmx_exit_handled from true to false.
>
> I remember having the same discussion before :) I still think the
> default should be changed (then we don't need nVMX hunks in VMX patches
> ;) ).

Yeah, that was my point.  Patches welcome! ;)

Paolo

Re: [PATCH 1/3 v2] KVM: vmx: Enable VMFUNCs

[David Hildenbrand]

On 10.07.2017 11:17, Paolo Bonzini wrote:
> 
> 
> On 10/07/2017 10:54, David Hildenbrand wrote:
>>
>>>  /*
>>>   * The exit handlers return 1 if the exit was handled fully and guest 
>>> execution
>>>   * may resume.  Otherwise they set the kvm_run parameter to indicate what 
>>> needs
>>> @@ -7790,6 +7806,7 @@ static int (*const kvm_vmx_exit_handlers[])(struct 
>>> kvm_vcpu *vcpu) = {
>>> [EXIT_REASON_XSAVES]  = handle_xsaves,
>>> [EXIT_REASON_XRSTORS] = handle_xrstors,
>>> [EXIT_REASON_PML_FULL]= handle_pml_full,
>>> +   [EXIT_REASON_VMFUNC]  = handle_vmfunc,
>>> [EXIT_REASON_PREEMPTION_TIMER]= handle_preemption_timer,
>>>  };
>>>  
>>> @@ -8111,6 +8128,9 @@ static bool nested_vmx_exit_handled(struct kvm_vcpu 
>>> *vcpu)
>>> case EXIT_REASON_PML_FULL:
>>> /* We emulate PML support to L1. */
>>> return false;
>>> +   case EXIT_REASON_VMFUNC:
>>> +   /* VM functions are emulated through L2->L0 vmexits. */
>>> +   return false;
>>
>> This would fit better into the second patch.
> 
> It depends on how you reason about it.  I put it here because:
> 
> - until this patch, EXIT_REASON_VMFUNC should never be generated.  We
> don't even know that it exists.
> 
> - after this patch, it should still never be generated in nested
> scenarios.  However, if it did because of a bug, we're in a better place
> to handle it than L1 (because as far as L1 knows, it should never be
> generated).
> 
> Perhaps this is an argument in favor of changing the default case of
> nested_vmx_exit_handled from true to false.

I remember having the same discussion before :) I still think the
default should be changed (then we don't need nVMX hunks in VMX patches
;) ).

Anyhow

Reviewed-by: David Hildenbrand 

> 
> Paolo


-- 

Thanks,

David

[PATCH v3 0/1]

[Claudio Imbrenda]

This patch adds a few lines to the KVM common code to fire a
KOBJ_CHANGE uevent whenever a KVM VM is created or destroyed. The event
carries five environment variables:

CREATED indicates how many times a new VM has been created. It is
useful for example to trigger specific actions when the first
VM is started
COUNT indicates how many VMs are currently active. This can be used for
logging or monitoring purposes
PID has the pid of the KVM process that has been started or stopped.
This can be used to perform process-specific tuning.
STATS_PATH contains the path in debugfs to the directory with all the
runtime statistics for this VM. This is useful for performance
monitoring and profiling.
EVENT described the type of event, its value can be either "create" or
"destroy"

Specific udev rules can be then set up in userspace to deal with the
creation or destruction of VMs as needed.

v2 -> v3:
* added EVENT
* shortened the names of the other variables

v1 -> v2:
* added KVM_VM_PID and KVM_VM_STATS_PATH
* some cleanup, the patch should look nicer now
* rebased on 4.12

*** BLURB HERE ***

Claudio Imbrenda (1):
  KVM: trigger uevents when starting or stopping a VM

 virt/kvm/kvm_main.c | 59 +
 1 file changed, 59 insertions(+)

-- 
2.7.4

[PATCH] wireless: ipw2200: constify attribute_group structures.

[Arvind Yadav]

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by  work
with const attribute_group. So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/net/wireless/intel/ipw2x00/ipw2200.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/intel/ipw2x00/ipw2200.c 
b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
index 9368abd..c311b1a 100644
--- a/drivers/net/wireless/intel/ipw2x00/ipw2200.c
+++ b/drivers/net/wireless/intel/ipw2x00/ipw2200.c
@@ -11500,7 +11500,7 @@ static int ipw_wdev_init(struct net_device *dev)
NULL
 };
 
-static struct attribute_group ipw_attribute_group = {
+static const struct attribute_group ipw_attribute_group = {
.name = NULL,   /* put in device directory */
.attrs = ipw_sysfs_entries,
 };
-- 
1.9.1

Re: [PATCH] irqchip: gicv3-its: Use NUMA aware memory allocation for ITS tables

[Marc Zyngier]

On 10/07/17 10:08, Ganapatrao Kulkarni wrote:
> On Mon, Jul 10, 2017 at 2:36 PM, Marc Zyngier  wrote:
>> On 10/07/17 09:48, Ganapatrao Kulkarni wrote:
>>> Hi Marc,
>>>
>>> On Mon, Jul 3, 2017 at 8:23 PM, Marc Zyngier  wrote:
 Hi Shanker,

 On 03/07/17 15:24, Shanker Donthineni wrote:
> Hi Marc,
>
> On 06/30/2017 03:51 AM, Marc Zyngier wrote:
>> On 30/06/17 04:01, Ganapatrao Kulkarni wrote:
>>> On Fri, Jun 30, 2017 at 8:04 AM, Ganapatrao Kulkarni
>>>  wrote:
 Hi Shanker,

 On Sun, Jun 25, 2017 at 9:16 PM, Shanker Donthineni
  wrote:
> The NUMA node information is visible to ITS driver but not being used
> other than handling errata. This patch allocates the memory for ITS
> tables from the corresponding NUMA node using the appropriate NUMA
> aware functions.
>>>
>>> IMHO, the description would have been more constructive?
>>>
>>> "All ITS tables are mapped by default to NODE 0 memory.
>>> Adding changes to allocate memory from respective NUMA NODES of ITS 
>>> devices.
>>> This will optimize tables access and avoids unnecessary inter-node 
>>> traffic."
>>
>> But more importantly, I'd like to see figures showing the actual benefit
>> of this per-node allocation. Given that both of you guys have access to
>> such platforms, please show me the numbers!
>>
>
> I'll share the actual results which shows the improvement whenever
> available on our next chips. Current version of Qualcomm qdf2400 doesn't
> support multi socket configuration to capture results and share with you.
>
> Do you see any other issues with this patch apart from the performance
> improvements. I strongly believe this brings the noticeable improvement
> in numbers on systems where it has multi node memory/CPU configuration.

 I agree that it *could* show an improvement, but it very much depends on
 how often the ITS misses in its caches. For this kind of patches, I want
 to see two things:

 1) It brings a measurable benefit on NUMA platforms
>>>
>>> Did some measurement of interrupt response time for LPIs and we don't
>>> see any major
>>> improvement due to caching of Tables. However, we have seen
>>> improvements of around 5%.
>>
>> An improvement of what exactly?
> 
> interrupt response time.

Measured how? On which HW? Using which benchmark?

Give me the actual benchmark results. Don't expect me to accept this
kind of hand-wavy statement.

M.
-- 
Jazz is not dead. It just smells funny...

[GIT PULL] HID for 4.13

[Jiri Kosina]

Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git for-linus

to receive HID updates for 4.13 merge window:

=
- open/close tracking improvements from Dmitry Torokhov
- battery support improvements in Wacom driver from Jason Gerecke
- Win8 support fixes from Benjamin Tissories and Hans de Geode
- misc fixes to Intel-ISH driver from Arnd Bergmann
- support for quite a few new devices and small assorted fixes here and 
  there
=

Thanks.


Alex Henrie (1):
  HID: apple: Use country code to detect ISO keyboards

Andy Shevchenko (1):
  HID: core: don't use negative operands when shift

Arnd Bergmann (5):
  HID: intel_ish-hid: fix potential uninitialized data usage
  HID: intel_ish-hid: clarify locking in client code
  HID: intel_ish-hid: convert timespec to ktime_t
  HID: intel_ish-hid: fix format string for size_t
  HID: intel_ish-hid: enable compile testing

Bastien Nocera (1):
  HID: Add driver for Retrode2 joypad adapter

Benjamin Tissoires (3):
  HID: multitouch: use BIT macro
  HID: multitouch: fix rare Win 8 cases when the touch up event gets missing
  HID: multitouch: optimize the sticky fingers timer

Colin Ian King (1):
  HID: wacom: fix mistake in printk

Daniel Drake (2):
  HID: move Asus keyboard support from hid-chicony to hid-asus
  HID: asus: Add support for Zen AiO MD-5110 keyboard

Dmitry Torokhov (8):
  HID: hiddev: use hid_hw_open/close instead of usbhid_open/close
  HID: hiddev: use hid_hw_power instead of usbhid_get/put_power
  HID: usbhid: do not rely on hid->open when deciding to do IO
  HID: serialize hid_hw_open and hid_hw_close
  HID: i2c-hid: remove custom locking from i2c_hid_open/close
  HID: usbhid: remove custom locking from usbhid_open/close
  greybus: hid: remove custom locking from gb_hid_open/close
  HID: remove no longer used hid->open field

Hans de Goede (3):
  HID: Add mapping for Microsoft Win8 Wireless Radio Controls extensions
  HID: ite: Add hid-ite driver
  HID: Microsoft Win8 Wireless Radio Controls cleanup

Jason Gerecke (5):
  HID: wacom: generic: Scale battery capacity measurements to percentages
  HID: wacom: generic: Ignore HID_DG_BATTERYSTRENTH == 0
  HID: wacom: generic: Report AES battery information
  HID: wacom: Add ability to provide explicit battery status info
  HID: wacom: generic: Refactor generic battery handling

Masaki Ota (1):
  HID: multitouch: Support PTP Stick and Touchpad device

Song Hongyan (2):
  HID: intel-ish-hid: Enable Cannon Lake ish driver
  HID: intel-ish-hid: Enable Gemini Lake ish driver

Wei-Ning Huang (1):
  HID: multitouch: Add support for Google Rose Touchpad

Wolfram Sang (1):
  HID: i2c-hid: move header file out of I2C realm

 drivers/hid/Kconfig|  15 ++
 drivers/hid/Makefile   |   2 +
 drivers/hid/hid-apple.c|  59 
 drivers/hid/hid-asus.c |  30 
 drivers/hid/hid-chicony.c  |   2 -
 drivers/hid/hid-core.c | 102 -
 drivers/hid/hid-ids.h  |  14 +-
 drivers/hid/hid-input.c|   9 ++
 drivers/hid/hid-ite.c  |  56 +++
 drivers/hid/hid-multitouch.c   | 184 ++-
 drivers/hid/hid-retrode.c  | 100 +
 drivers/hid/i2c-hid/i2c-hid.c  |  34 ++---
 drivers/hid/intel-ish-hid/Kconfig  |   2 +-
 drivers/hid/intel-ish-hid/ipc/hw-ish.h |   2 +
 drivers/hid/intel-ish-hid/ipc/ipc.c|  15 +-
 drivers/hid/intel-ish-hid/ipc/pci-ish.c|   2 +
 drivers/hid/intel-ish-hid/ishtp-hid-client.c   |   5 +-
 drivers/hid/intel-ish-hid/ishtp/client.c   |  49 +++---
 drivers/hid/intel-ish-hid/ishtp/client.h   |   6 +-
 drivers/hid/intel-ish-hid/ishtp/hbm.c  |  11 +-
 drivers/hid/usbhid/hid-core.c  | 150 +--
 drivers/hid/usbhid/hiddev.c|  24 +--
 drivers/hid/usbhid/usbhid.h|  15 +-
 drivers/hid/wacom.h|   1 +
 drivers/hid/wacom_sys.c|   4 +-
 drivers/hid/wacom_wac.c| 200 +++--
 drivers/hid/wacom_wac.h|   7 +
 drivers/staging/greybus/hid.c  |  43 ++
 include/linux/hid.h|  82 +++---
 include/linux/{i2c => platform_data}/i2c-hid.h |   0
 30 files changed, 798 insertions(+), 427 deletions(-)
 create mode 100644 drivers/hid/hid-ite.c
 create mode 100644 drivers/hid/hid-retrode.c
 rename include/linux/{i2c => platform_data}/i2c-hid.h (100%)

-- 
Jiri Kosina
SUSE Labs

Re: Potential scheduler regression

[Peter Zijlstra]

On Fri, Jul 07, 2017 at 04:55:27PM -0400, Ben Guthro wrote:

> Apologies on the delay - it took a bit to get the machines, to run the test.
> 
> I am happy to report that the kernel at 1ad3aaf3fcd2, seems to regain
> performance loss from 1b568f0aab, in our test environment.

Excellent.

> Since 4.9 is an LTS kernel - is this appropriate to suggest to be
> included in the linux-stable list?

Hurm... so I typically suck at (also) keeping track of -stable things.

But given LTS, there might be a few more commits that might make sense
to include.

This series corrects NUMA topology creation:

8c0334697dc3 ("sched/topology: Refactor function build_overlap_sched_groups()")
c743f0a5c50f ("sched/fair, cpumask: Export for_each_cpu_wrap()")
0372dd2736e0 ("sched/topology: Fix building of overlapping sched-groups")
91eaed0d6131 ("sched/topology: Simplify build_overlap_sched_groups()")
b0151c25548c ("sched/debug: Print the scheduler topology group mask")
a420b0630362 ("sched/topology: Verify the first group matches the child domain")
f32d782e31bf ("sched/topology: Optimize build_group_mask()")
c20e1ea4b61c ("sched/topology: Move comment about asymmetric node setups")
af85596c74de ("sched/topology: Remove FORCE_SD_OVERLAP")
73bb059f9b8a ("sched/topology: Fix overlapping sched_group_mask")
8d5dc5126bb2 ("sched/topology: Small cleanup")
005f874dd284 ("sched/topology: Add sched_group_capacity debugging")
1676330ecfa8 ("sched/topology: Fix overlapping sched_group_capacity")

(there's a few more commits at the end of that series that add comments
and renames a bunch of stuff which doesn't really fix anything).

Cures a BUG_ON through sysrq:

896bbb252258 ("sched/core: Allow __sched_setscheduler() in interrupts when PI 
is not used")


Performance issues:


502ce005ab95 ("sched/fair: Use task_groups instead of leaf_cfs_rq_list to walk 
all cfs_rqs")
a9e7f6544b9c ("sched/fair: Fix O(nr_cgroups) in load balance path")

c249f255aab8 ("sched/rt: Minimize rq->lock contention in 
do_sched_rt_period_timer()")

8655d5497735 ("sched/numa: Use down_read_trylock() for the mmap_sem")



And then the patch you want for this:

1ad3aaf3fcd2 ("sched/core: Implement new approach to scale select_idle_cpu()")



I have no real idea how much of any those qualify for 4.9, but know most
of those patches ended up in the various enterprise distros in some form
or other.


In any case, some of that will need some massaging to apply and it
obviously needs testing of sorts. So I'm not sure what all makes sense
to do.

Re: Re-routing packets via netfilter (ip_rt_bug)

[Helbing63]

I have been using free VPN but it is not that good because network is always
congested which leads to slower connection. I just finished reading 
expressvpn review    and it
seems like a good option. Does anyone here have experience with this VPN? If
yes, please share.



--
View this message in context: 
http://linux-kernel.2935.n7.nabble.com/Re-routing-packets-via-netfilter-ip-rt-bug-tp435p1381848.html
Sent from the Linux Kernel mailing list archive at Nabble.com.

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Wanpeng Li]

2017-07-10 16:46 GMT+08:00 Peter Zijlstra :
> On Mon, Jul 10, 2017 at 09:38:30AM +0800, Aubrey Li wrote:
>> We measured 3%~5% improvemnt in disk IO workload, and 8%~20% improvement in
>> network workload.
>
> Argh, what a mess :/

Agreed, this patchset is a variant of
https://lkml.org/lkml/2017/6/22/296 As I mentioned before, we should
not churn the core path.

Regards,
Wanpeng Li

>
> So how much of the gain is simply due to skipping NOHZ? Mike used to
> carry a patch that would throttle NOHZ. And that is a _far_ smaller and
> simpler patch to do.

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

[Frans Klaver]

On Mon, Jul 10, 2017 at 6:46 AM, Viresh Kumar  wrote:
> Hi Mitchell,
>
> On 09-07-17, 20:25, Mitchell Tasman wrote:
>> Adjust formatting of various statements to keep line length within
>> the 80 column limit preferred by the Linux kernel coding style.
>
> We try to follow that most of the time, but the end result should be easily
> readable.  If it isn't, then we just ignore the rule.
>
>> Signed-off-by: Mitchell Tasman 
>> ---
>> Changes in v2: Add back a missing space in a comment
>>
>>  drivers/staging/greybus/arche-platform.c | 29 +++--
>>  1 file changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/staging/greybus/arche-platform.c 
>> b/drivers/staging/greybus/arche-platform.c
>> index eced2d2..eedd239 100644
>> --- a/drivers/staging/greybus/arche-platform.c
>> +++ b/drivers/staging/greybus/arche-platform.c
>> @@ -172,15 +172,21 @@ static irqreturn_t arche_platform_wd_irq(int irq, void 
>> *devid)
>>   if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) {
>>   if (time_before(jiffies,
>>   arche_pdata->wake_detect_start +
>> - 
>> msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
>> - 
>> arche_platform_set_wake_detect_state(arche_pdata,
>> -  
>> WD_STATE_IDLE);
>> + msecs_to_jiffies(
>> + WD_COLDBOOT_PULSE_WIDTH_MS))) {
>> + arche_platform_set_wake_detect_state(
>
> We don't break the lines like this in kernel to satisfy the 80 column width
> rule. Surely, some places would have similar code, but in general this isn't
> recommended. And that's why we never bothered about 80 column rule in this and
> below cases.

In cases like this, one could argue that you should start looking at
the level of indentation, rather than the line length per se. After
all, the documentation states that "if you need more than 3 levels of
indentation, you're screwed anyway, and you should fix your program".

Re: [greybus-dev] [PATCH v2] staging: greybus: arche: wrap over-length lines

[Viresh Kumar]

On 10-07-17, 11:30, Frans Klaver wrote:
> On Mon, Jul 10, 2017 at 6:46 AM, Viresh Kumar  wrote:
> > Hi Mitchell,
> >
> > On 09-07-17, 20:25, Mitchell Tasman wrote:
> >> Adjust formatting of various statements to keep line length within
> >> the 80 column limit preferred by the Linux kernel coding style.
> >
> > We try to follow that most of the time, but the end result should be easily
> > readable.  If it isn't, then we just ignore the rule.
> >
> >> Signed-off-by: Mitchell Tasman 
> >> ---
> >> Changes in v2: Add back a missing space in a comment
> >>
> >>  drivers/staging/greybus/arche-platform.c | 29 
> >> +++--
> >>  1 file changed, 19 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/staging/greybus/arche-platform.c 
> >> b/drivers/staging/greybus/arche-platform.c
> >> index eced2d2..eedd239 100644
> >> --- a/drivers/staging/greybus/arche-platform.c
> >> +++ b/drivers/staging/greybus/arche-platform.c
> >> @@ -172,15 +172,21 @@ static irqreturn_t arche_platform_wd_irq(int irq, 
> >> void *devid)
> >>   if (arche_pdata->wake_detect_state == WD_STATE_BOOT_INIT) {
> >>   if (time_before(jiffies,
> >>   arche_pdata->wake_detect_start +
> >> - 
> >> msecs_to_jiffies(WD_COLDBOOT_PULSE_WIDTH_MS))) {
> >> - 
> >> arche_platform_set_wake_detect_state(arche_pdata,
> >> -  
> >> WD_STATE_IDLE);
> >> + msecs_to_jiffies(
> >> + 
> >> WD_COLDBOOT_PULSE_WIDTH_MS))) {
> >> + arche_platform_set_wake_detect_state(
> >
> > We don't break the lines like this in kernel to satisfy the 80 column width
> > rule. Surely, some places would have similar code, but in general this isn't
> > recommended. And that's why we never bothered about 80 column rule in this 
> > and
> > below cases.
> 
> In cases like this, one could argue that you should start looking at
> the level of indentation, rather than the line length per se. After
> all, the documentation states that "if you need more than 3 levels of
> indentation, you're screwed anyway, and you should fix your program".

And I completely agree to that :)

-- 
viresh