Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Peter Zijlstra]

On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a497024..08f3042 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
>  int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
>  unsigned int flags)
>  {
> +   if (flags & FAULT_FLAG_SPECULATIVE) {
> +   if (flags & FAULT_FLAG_KILLABLE) {
> +   int ret;
> +
> +   ret = __lock_page_killable(page);
> +   if (ret)
> +   return 0;
> +   } else
> +   __lock_page(page);
> +   return 1;
> +   }
> +
> if (flags & FAULT_FLAG_ALLOW_RETRY) {
> /*
>  * CAUTION! In this case, mmap_sem is not released

Yeah, that looks right.

> @@ -4012,17 +4010,7 @@ int handle_speculative_fault(struct mm_struct *mm, 
> unsigned long address,
> goto unlock;
> }
> 
> +   if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) {
> trace_spf_vma_notsup(_RET_IP_, vma, address);
> goto unlock;
> }

As riel pointed out on IRC slightly later, private file maps also need
->anon_vma and those actually have ->vm_ops IIRC so the condition needs
to be slightly more complicated.

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Peter Zijlstra]

On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a497024..08f3042 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
>  int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
>  unsigned int flags)
>  {
> +   if (flags & FAULT_FLAG_SPECULATIVE) {
> +   if (flags & FAULT_FLAG_KILLABLE) {
> +   int ret;
> +
> +   ret = __lock_page_killable(page);
> +   if (ret)
> +   return 0;
> +   } else
> +   __lock_page(page);
> +   return 1;
> +   }
> +
> if (flags & FAULT_FLAG_ALLOW_RETRY) {
> /*
>  * CAUTION! In this case, mmap_sem is not released

Yeah, that looks right.

> @@ -4012,17 +4010,7 @@ int handle_speculative_fault(struct mm_struct *mm, 
> unsigned long address,
> goto unlock;
> }
> 
> +   if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) {
> trace_spf_vma_notsup(_RET_IP_, vma, address);
> goto unlock;
> }

As riel pointed out on IRC slightly later, private file maps also need
->anon_vma and those actually have ->vm_ops IIRC so the condition needs
to be slightly more complicated.

Re: [PATCH] Staging:android:ion:ion.c : Using WARN_ON() rather than BUG()

[Greg KH]

On Wed, Aug 30, 2017 at 12:51:02AM +0530, harsha wrote:
> Fixes checkpatch.pl warning: Use WARN_ON() rather than BUG_ON() and BUG()
> 
> Signed-off-by: harsha 
> ---
>  drivers/staging/android/ion/ion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 93e2c90..a2d36b3 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -66,7 +66,7 @@ static void ion_buffer_add(struct ion_device *dev,
>   p = &(*p)->rb_right;
>   } else {
>   pr_err("%s: buffer already found.", __func__);
> - BUG();
> + WARN_ON();
>   }
>   }
>  

As you did not do anything different from the last submission where I
said this patch was not correct, I'm guessing that you don't want any
feedback.  So I'll go add you to my kill-file now and just ignore your
emails, as obviously, you are ignoring mine :(

good luck!

greg k-h

Re: [PATCH] Staging:android:ion:ion.c : Using WARN_ON() rather than BUG()

[Greg KH]

On Wed, Aug 30, 2017 at 12:51:02AM +0530, harsha wrote:
> Fixes checkpatch.pl warning: Use WARN_ON() rather than BUG_ON() and BUG()
> 
> Signed-off-by: harsha 
> ---
>  drivers/staging/android/ion/ion.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/android/ion/ion.c 
> b/drivers/staging/android/ion/ion.c
> index 93e2c90..a2d36b3 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -66,7 +66,7 @@ static void ion_buffer_add(struct ion_device *dev,
>   p = &(*p)->rb_right;
>   } else {
>   pr_err("%s: buffer already found.", __func__);
> - BUG();
> + WARN_ON();
>   }
>   }
>  

As you did not do anything different from the last submission where I
said this patch was not correct, I'm guessing that you don't want any
feedback.  So I'll go add you to my kill-file now and just ignore your
emails, as obviously, you are ignoring mine :(

good luck!

greg k-h

[PATCH v3] mfd: tps65217: Introduce dependency on CONFIG_OF

[Keerthy]

Currently the driver boots only via device tree hence add a
dependency on CONFIG_OF. This leaves with a bunch of unused code
so clean that up. This patch also makes use of probe_new function
in place of the probe function so as to avoid passing i2c_device_id.

Signed-off-by: Keerthy 
---

Changes in v3:

  * Added more details to commit log.
  * No changes in code. Rebased to latest next branch.

Changes in v2:

  * Cleaned up chip_id and data attached to the match.
  * Cleaned up i2c_dev_id
  * dropped the rest of the patches in series for now

Boot tested and checked for regulator registrations on am335x-boneblack

 drivers/mfd/Kconfig|  2 +-
 drivers/mfd/tps65217.c | 35 +-
 drivers/regulator/tps65217-regulator.c |  5 -
 drivers/video/backlight/tps65217_bl.c  | 14 +++---
 include/linux/mfd/tps65217.h   |  6 --
 5 files changed, 9 insertions(+), 53 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 95e8683..8177cbc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1326,7 +1326,7 @@ config MFD_TPS65090
 
 config MFD_TPS65217
tristate "TI TPS65217 Power Management / White LED chips"
-   depends on I2C
+   depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select IRQ_DOMAIN
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index f769c7d..e5a1a57 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -311,37 +311,20 @@ static bool tps65217_volatile_reg(struct device *dev, 
unsigned int reg)
 };
 
 static const struct of_device_id tps65217_of_match[] = {
-   { .compatible = "ti,tps65217", .data = (void *)TPS65217 },
+   { .compatible = "ti,tps65217"},
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, tps65217_of_match);
 
-static int tps65217_probe(struct i2c_client *client,
-   const struct i2c_device_id *ids)
+static int tps65217_probe(struct i2c_client *client)
 {
struct tps65217 *tps;
unsigned int version;
-   unsigned long chip_id = ids->driver_data;
-   const struct of_device_id *match;
bool status_off = false;
int ret;
 
-   if (client->dev.of_node) {
-   match = of_match_device(tps65217_of_match, >dev);
-   if (!match) {
-   dev_err(>dev,
-   "Failed to find matching dt id\n");
-   return -EINVAL;
-   }
-   chip_id = (unsigned long)match->data;
-   status_off = of_property_read_bool(client->dev.of_node,
-   "ti,pmic-shutdown-controller");
-   }
-
-   if (!chip_id) {
-   dev_err(>dev, "id is null.\n");
-   return -ENODEV;
-   }
+   status_off = of_property_read_bool(client->dev.of_node,
+  "ti,pmic-shutdown-controller");
 
tps = devm_kzalloc(>dev, sizeof(*tps), GFP_KERNEL);
if (!tps)
@@ -349,7 +332,6 @@ static int tps65217_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, tps);
tps->dev = >dev;
-   tps->id = chip_id;
 
tps->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(tps->regmap)) {
@@ -418,19 +400,12 @@ static int tps65217_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id tps65217_id_table[] = {
-   {"tps65217", TPS65217},
-   { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
-
 static struct i2c_driver tps65217_driver = {
.driver = {
.name   = "tps65217",
.of_match_table = tps65217_of_match,
},
-   .id_table   = tps65217_id_table,
-   .probe  = tps65217_probe,
+   .probe_new  = tps65217_probe,
.remove = tps65217_remove,
 };
 
diff --git a/drivers/regulator/tps65217-regulator.c 
b/drivers/regulator/tps65217-regulator.c
index 5324dc9..7b12e88 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -228,11 +228,6 @@ static int tps65217_regulator_probe(struct platform_device 
*pdev)
int i, ret;
unsigned int val;
 
-   if (tps65217_chip_id(tps) != TPS65217) {
-   dev_err(>dev, "Invalid tps chip version\n");
-   return -ENODEV;
-   }
-
/* Allocate memory for strobes */
tps->strobes = devm_kzalloc(>dev, sizeof(u8) *
TPS65217_NUM_REGULATOR, GFP_KERNEL);
diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index fd524ad..5ce8791 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -275,17 +275,9 @@ static int tps65217_bl_probe(struct platform_device *pdev)
struct tps65217_bl_pdata *pdata;

[PATCH v3] mfd: tps65217: Introduce dependency on CONFIG_OF

[Keerthy]

Currently the driver boots only via device tree hence add a
dependency on CONFIG_OF. This leaves with a bunch of unused code
so clean that up. This patch also makes use of probe_new function
in place of the probe function so as to avoid passing i2c_device_id.

Signed-off-by: Keerthy 
---

Changes in v3:

  * Added more details to commit log.
  * No changes in code. Rebased to latest next branch.

Changes in v2:

  * Cleaned up chip_id and data attached to the match.
  * Cleaned up i2c_dev_id
  * dropped the rest of the patches in series for now

Boot tested and checked for regulator registrations on am335x-boneblack

 drivers/mfd/Kconfig|  2 +-
 drivers/mfd/tps65217.c | 35 +-
 drivers/regulator/tps65217-regulator.c |  5 -
 drivers/video/backlight/tps65217_bl.c  | 14 +++---
 include/linux/mfd/tps65217.h   |  6 --
 5 files changed, 9 insertions(+), 53 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 95e8683..8177cbc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1326,7 +1326,7 @@ config MFD_TPS65090
 
 config MFD_TPS65217
tristate "TI TPS65217 Power Management / White LED chips"
-   depends on I2C
+   depends on I2C && OF
select MFD_CORE
select REGMAP_I2C
select IRQ_DOMAIN
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index f769c7d..e5a1a57 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -311,37 +311,20 @@ static bool tps65217_volatile_reg(struct device *dev, 
unsigned int reg)
 };
 
 static const struct of_device_id tps65217_of_match[] = {
-   { .compatible = "ti,tps65217", .data = (void *)TPS65217 },
+   { .compatible = "ti,tps65217"},
{ /* sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, tps65217_of_match);
 
-static int tps65217_probe(struct i2c_client *client,
-   const struct i2c_device_id *ids)
+static int tps65217_probe(struct i2c_client *client)
 {
struct tps65217 *tps;
unsigned int version;
-   unsigned long chip_id = ids->driver_data;
-   const struct of_device_id *match;
bool status_off = false;
int ret;
 
-   if (client->dev.of_node) {
-   match = of_match_device(tps65217_of_match, >dev);
-   if (!match) {
-   dev_err(>dev,
-   "Failed to find matching dt id\n");
-   return -EINVAL;
-   }
-   chip_id = (unsigned long)match->data;
-   status_off = of_property_read_bool(client->dev.of_node,
-   "ti,pmic-shutdown-controller");
-   }
-
-   if (!chip_id) {
-   dev_err(>dev, "id is null.\n");
-   return -ENODEV;
-   }
+   status_off = of_property_read_bool(client->dev.of_node,
+  "ti,pmic-shutdown-controller");
 
tps = devm_kzalloc(>dev, sizeof(*tps), GFP_KERNEL);
if (!tps)
@@ -349,7 +332,6 @@ static int tps65217_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, tps);
tps->dev = >dev;
-   tps->id = chip_id;
 
tps->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(tps->regmap)) {
@@ -418,19 +400,12 @@ static int tps65217_remove(struct i2c_client *client)
return 0;
 }
 
-static const struct i2c_device_id tps65217_id_table[] = {
-   {"tps65217", TPS65217},
-   { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
-
 static struct i2c_driver tps65217_driver = {
.driver = {
.name   = "tps65217",
.of_match_table = tps65217_of_match,
},
-   .id_table   = tps65217_id_table,
-   .probe  = tps65217_probe,
+   .probe_new  = tps65217_probe,
.remove = tps65217_remove,
 };
 
diff --git a/drivers/regulator/tps65217-regulator.c 
b/drivers/regulator/tps65217-regulator.c
index 5324dc9..7b12e88 100644
--- a/drivers/regulator/tps65217-regulator.c
+++ b/drivers/regulator/tps65217-regulator.c
@@ -228,11 +228,6 @@ static int tps65217_regulator_probe(struct platform_device 
*pdev)
int i, ret;
unsigned int val;
 
-   if (tps65217_chip_id(tps) != TPS65217) {
-   dev_err(>dev, "Invalid tps chip version\n");
-   return -ENODEV;
-   }
-
/* Allocate memory for strobes */
tps->strobes = devm_kzalloc(>dev, sizeof(u8) *
TPS65217_NUM_REGULATOR, GFP_KERNEL);
diff --git a/drivers/video/backlight/tps65217_bl.c 
b/drivers/video/backlight/tps65217_bl.c
index fd524ad..5ce8791 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -275,17 +275,9 @@ static int tps65217_bl_probe(struct platform_device *pdev)
struct tps65217_bl_pdata *pdata;
struct 

[PATCH] drm: vmwgfx: constify vmw_fence_ops

[Arvind Yadav]

vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index b8bc5bc..abc5f03 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool intr, 
signed long timeout)
return ret;
 }
 
-static struct dma_fence_ops vmw_fence_ops = {
+static const struct dma_fence_ops vmw_fence_ops = {
.get_driver_name = vmw_fence_get_driver_name,
.get_timeline_name = vmw_fence_get_timeline_name,
.enable_signaling = vmw_fence_enable_signaling,
-- 
1.9.1

[PATCH] drm: vmwgfx: constify vmw_fence_ops

[Arvind Yadav]

vmw_fence_ops are not supposed to change at runtime. Functions
"dma_fence_init" working with const vmw_fence_ops provided
by . So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index b8bc5bc..abc5f03 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -225,7 +225,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool intr, 
signed long timeout)
return ret;
 }
 
-static struct dma_fence_ops vmw_fence_ops = {
+static const struct dma_fence_ops vmw_fence_ops = {
.get_driver_name = vmw_fence_get_driver_name,
.get_timeline_name = vmw_fence_get_timeline_name,
.enable_signaling = vmw_fence_enable_signaling,
-- 
1.9.1

Re: WARNING: possible circular locking dependency detected

[Peter Zijlstra]

On Tue, Aug 29, 2017 at 10:10:37PM +0200, Thomas Gleixner wrote:
> On Tue, 29 Aug 2017, Peter Zijlstra wrote:
> > So I have a patch _somewhere_ that preserves the event<->cpu relation
> > across hotplug and disable/enable would be sufficient. If you want I can
> > try and dig that out and make it work again.
> > 
> > That would avoid having to do the destroy/create cycle of the watchdog
> > events.
> 
> Yes, that would solve the x86_release_hw() issue, but still lots of the
> other rework is required in one way or the other.
> 
> I'm currently trying to avoid that extra lock mess in the cpu hotplug code,
> which would just open the door for everybody to add his extra locks there,
> so we end up taking a gazillion locks before we can hotplug :)
> 
> I think I have an idea how to solve that cleanly, but certainly your offer
> of preserving the event - cpu relation accross hotplug would help
> tremendously.

I think something like the below ought to work. Compile tested only.

On offline it basically does perf_event_disable() for all CPU context
events, and then adds HOTPLUG_OFFSET (-32) to arrive at: OFF +
HOTPLUG_OFFSET = -33.

That's smaller than ERROR and thus perf_event_enable() no-ops on events
for offline CPUs (maybe we should try and plumb an error return for
IOC_ENABLE).

On online we subtract the HOTPLUG_OFFSET again and the event becomes a
regular OFF, after which perf_event_enable() should work again.

---
 include/linux/perf_event.h |  2 ++
 kernel/events/core.c   | 51 +-
 2 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9bac4bfa5e1a..7b39ceeb206b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -497,6 +497,8 @@ enum perf_event_active_state {
PERF_EVENT_STATE_OFF= -1,
PERF_EVENT_STATE_INACTIVE   =  0,
PERF_EVENT_STATE_ACTIVE =  1,
+
+   PERF_EVENT_STATE_HOTPLUG_OFFSET = -32,
 };
 
 struct file;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f77c97477e08..b277c27fd81e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11025,19 +11025,21 @@ void perf_swevent_init_cpu(unsigned int cpu)
 }
 
 #if defined CONFIG_HOTPLUG_CPU || defined CONFIG_KEXEC_CORE
-static void __perf_event_exit_context(void *__info)
+static void __perf_event_exit_cpu(void *__info)
 {
-   struct perf_event_context *ctx = __info;
-   struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
+   struct perf_cpu_context *cpuctx = __info;
+   struct perf_event_context *ctx = >ctx;
struct perf_event *event;
 
raw_spin_lock(>lock);
-   list_for_each_entry(event, >event_list, event_entry)
-   __perf_remove_from_context(event, cpuctx, ctx, (void 
*)DETACH_GROUP);
+   list_for_each_entry(event, >event_list, event_entry) {
+   __perf_event_disable(event, cpuctx, ctx, NULL);
+   event->state += PERF_EVENT_STATE_HOTPLUG_OFFSET;
+   }
raw_spin_unlock(>lock);
 }
 
-static void perf_event_exit_cpu_context(int cpu)
+int perf_event_exit_cpu(unsigned int cpu)
 {
struct perf_cpu_context *cpuctx;
struct perf_event_context *ctx;
@@ -11049,17 +11051,43 @@ static void perf_event_exit_cpu_context(int cpu)
ctx = >ctx;
 
mutex_lock(>mutex);
-   smp_call_function_single(cpu, __perf_event_exit_context, ctx, 
1);
+   smp_call_function_single(cpu, __perf_event_exit_cpu, cpuctx, 1);
cpuctx->online = 0;
mutex_unlock(>mutex);
}
cpumask_clear_cpu(cpu, perf_online_mask);
mutex_unlock(_lock);
+
+   return 0;
+}
+
+static void __perf_event_init_cpu(void *__info)
+{
+   struct perf_cpu_context *cpuctx = __info;
+   struct perf_event_context *ctx = >ctx;
+   struct perf_event *event;
+
+   raw_spin_lock(>lock);
+   list_for_each_entry(event, >event_list, event_entry)
+   event->state -= PERF_EVENT_STATE_HOTPLUG_OFFSET;
+   raw_spin_unlock(>lock);
+}
+
+static void _perf_event_init_cpu(int cpu, struct perf_cpu_context *cpuctx)
+{
+   smp_call_function_single(cpu, __perf_event_init_cpu, cpuctx, 1);
 }
+
 #else
 
-static void perf_event_exit_cpu_context(int cpu) { }
+int perf_event_exit_cpu(unsigned int cpu)
+{
+   return 0;
+}
 
+static void _perf_event_init_cpu(int cpu, struct perf_cpu_context *cpuctx)
+{
+}
 #endif
 
 int perf_event_init_cpu(unsigned int cpu)
@@ -11078,6 +11106,7 @@ int perf_event_init_cpu(unsigned int cpu)
 
mutex_lock(>mutex);
cpuctx->online = 1;
+   _perf_event_init_cpu(cpu, cpuctx);
mutex_unlock(>mutex);
}
mutex_unlock(_lock);
@@ -11085,12 +4,6 @@ int perf_event_init_cpu(unsigned int cpu)
return 0;
 }
 
-int perf_event_exit_cpu(unsigned int cpu)
-{
-   

Re: WARNING: possible circular locking dependency detected

[Peter Zijlstra]

On Tue, Aug 29, 2017 at 10:10:37PM +0200, Thomas Gleixner wrote:
> On Tue, 29 Aug 2017, Peter Zijlstra wrote:
> > So I have a patch _somewhere_ that preserves the event<->cpu relation
> > across hotplug and disable/enable would be sufficient. If you want I can
> > try and dig that out and make it work again.
> > 
> > That would avoid having to do the destroy/create cycle of the watchdog
> > events.
> 
> Yes, that would solve the x86_release_hw() issue, but still lots of the
> other rework is required in one way or the other.
> 
> I'm currently trying to avoid that extra lock mess in the cpu hotplug code,
> which would just open the door for everybody to add his extra locks there,
> so we end up taking a gazillion locks before we can hotplug :)
> 
> I think I have an idea how to solve that cleanly, but certainly your offer
> of preserving the event - cpu relation accross hotplug would help
> tremendously.

I think something like the below ought to work. Compile tested only.

On offline it basically does perf_event_disable() for all CPU context
events, and then adds HOTPLUG_OFFSET (-32) to arrive at: OFF +
HOTPLUG_OFFSET = -33.

That's smaller than ERROR and thus perf_event_enable() no-ops on events
for offline CPUs (maybe we should try and plumb an error return for
IOC_ENABLE).

On online we subtract the HOTPLUG_OFFSET again and the event becomes a
regular OFF, after which perf_event_enable() should work again.

---
 include/linux/perf_event.h |  2 ++
 kernel/events/core.c   | 51 +-
 2 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index 9bac4bfa5e1a..7b39ceeb206b 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -497,6 +497,8 @@ enum perf_event_active_state {
PERF_EVENT_STATE_OFF= -1,
PERF_EVENT_STATE_INACTIVE   =  0,
PERF_EVENT_STATE_ACTIVE =  1,
+
+   PERF_EVENT_STATE_HOTPLUG_OFFSET = -32,
 };
 
 struct file;
diff --git a/kernel/events/core.c b/kernel/events/core.c
index f77c97477e08..b277c27fd81e 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -11025,19 +11025,21 @@ void perf_swevent_init_cpu(unsigned int cpu)
 }
 
 #if defined CONFIG_HOTPLUG_CPU || defined CONFIG_KEXEC_CORE
-static void __perf_event_exit_context(void *__info)
+static void __perf_event_exit_cpu(void *__info)
 {
-   struct perf_event_context *ctx = __info;
-   struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
+   struct perf_cpu_context *cpuctx = __info;
+   struct perf_event_context *ctx = >ctx;
struct perf_event *event;
 
raw_spin_lock(>lock);
-   list_for_each_entry(event, >event_list, event_entry)
-   __perf_remove_from_context(event, cpuctx, ctx, (void 
*)DETACH_GROUP);
+   list_for_each_entry(event, >event_list, event_entry) {
+   __perf_event_disable(event, cpuctx, ctx, NULL);
+   event->state += PERF_EVENT_STATE_HOTPLUG_OFFSET;
+   }
raw_spin_unlock(>lock);
 }
 
-static void perf_event_exit_cpu_context(int cpu)
+int perf_event_exit_cpu(unsigned int cpu)
 {
struct perf_cpu_context *cpuctx;
struct perf_event_context *ctx;
@@ -11049,17 +11051,43 @@ static void perf_event_exit_cpu_context(int cpu)
ctx = >ctx;
 
mutex_lock(>mutex);
-   smp_call_function_single(cpu, __perf_event_exit_context, ctx, 
1);
+   smp_call_function_single(cpu, __perf_event_exit_cpu, cpuctx, 1);
cpuctx->online = 0;
mutex_unlock(>mutex);
}
cpumask_clear_cpu(cpu, perf_online_mask);
mutex_unlock(_lock);
+
+   return 0;
+}
+
+static void __perf_event_init_cpu(void *__info)
+{
+   struct perf_cpu_context *cpuctx = __info;
+   struct perf_event_context *ctx = >ctx;
+   struct perf_event *event;
+
+   raw_spin_lock(>lock);
+   list_for_each_entry(event, >event_list, event_entry)
+   event->state -= PERF_EVENT_STATE_HOTPLUG_OFFSET;
+   raw_spin_unlock(>lock);
+}
+
+static void _perf_event_init_cpu(int cpu, struct perf_cpu_context *cpuctx)
+{
+   smp_call_function_single(cpu, __perf_event_init_cpu, cpuctx, 1);
 }
+
 #else
 
-static void perf_event_exit_cpu_context(int cpu) { }
+int perf_event_exit_cpu(unsigned int cpu)
+{
+   return 0;
+}
 
+static void _perf_event_init_cpu(int cpu, struct perf_cpu_context *cpuctx)
+{
+}
 #endif
 
 int perf_event_init_cpu(unsigned int cpu)
@@ -11078,6 +11106,7 @@ int perf_event_init_cpu(unsigned int cpu)
 
mutex_lock(>mutex);
cpuctx->online = 1;
+   _perf_event_init_cpu(cpu, cpuctx);
mutex_unlock(>mutex);
}
mutex_unlock(_lock);
@@ -11085,12 +4,6 @@ int perf_event_init_cpu(unsigned int cpu)
return 0;
 }
 
-int perf_event_exit_cpu(unsigned int cpu)
-{
-   

Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG_OF

[Keerthy]

On Thursday 08 June 2017 07:41 PM, Javier Martinez Canillas wrote:
> On Thu, Jun 8, 2017 at 3:32 PM, Enric Balletbo Serra
>  wrote:
>> Hi Keerthy:
>>
>> 2017-06-08 12:46 GMT+02:00 Keerthy :
>>> Currently the driver boots only via device tree hence add a
>>> dependency on CONFIG_OF. This leaves with a bunch of unused code
>>> so clean that up.
>>>
>>> Signed-off-by: Keerthy 
>>
> 
> [snip]
> 
>>>
>>>  config MFD_TPS65217
>>> tristate "TI TPS65217 Power Management / White LED chips"
>>> -   depends on I2C
>>> +   depends on I2C && OF
>>
>> I think you should append || COMPILE_TEST here.
>>
> 
> For me it should be a separate patch, it's nice to have COMPILE_TEST
> but not related to this change IMHO.

Resurrecting this patch.

> 
>>>
>>> -static const struct i2c_device_id tps65217_id_table[] = {
>>> -   {"tps65217", TPS65217},
>>> -   { /* sentinel */ }
>>> -};
>>> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
> 
> Unfortunately you can't get rid of this table (yet) since the I2C
> subsystem always reports a MODALIAS of the form "i2c:tps65217" even
> when the devices have been registered via OF. There are only a couple
> of drivers more to clean-up and then I'll post a patch that fixes the
> I2C core to report a proper OF modalias. But for now, removing will
> mean that module autoload will be broken for this driver.

I believe now all the dependent patches are in to get rid of the above
table.

> 
> Best regards,
> Javier
> 

Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG_OF

[Keerthy]

On Thursday 08 June 2017 07:41 PM, Javier Martinez Canillas wrote:
> On Thu, Jun 8, 2017 at 3:32 PM, Enric Balletbo Serra
>  wrote:
>> Hi Keerthy:
>>
>> 2017-06-08 12:46 GMT+02:00 Keerthy :
>>> Currently the driver boots only via device tree hence add a
>>> dependency on CONFIG_OF. This leaves with a bunch of unused code
>>> so clean that up.
>>>
>>> Signed-off-by: Keerthy 
>>
> 
> [snip]
> 
>>>
>>>  config MFD_TPS65217
>>> tristate "TI TPS65217 Power Management / White LED chips"
>>> -   depends on I2C
>>> +   depends on I2C && OF
>>
>> I think you should append || COMPILE_TEST here.
>>
> 
> For me it should be a separate patch, it's nice to have COMPILE_TEST
> but not related to this change IMHO.

Resurrecting this patch.

> 
>>>
>>> -static const struct i2c_device_id tps65217_id_table[] = {
>>> -   {"tps65217", TPS65217},
>>> -   { /* sentinel */ }
>>> -};
>>> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
> 
> Unfortunately you can't get rid of this table (yet) since the I2C
> subsystem always reports a MODALIAS of the form "i2c:tps65217" even
> when the devices have been registered via OF. There are only a couple
> of drivers more to clean-up and then I'll post a patch that fixes the
> I2C core to report a proper OF modalias. But for now, removing will
> mean that module autoload will be broken for this driver.

I believe now all the dependent patches are in to get rid of the above
table.

> 
> Best regards,
> Javier
> 

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

[Byungchul Park]

On Wed, Aug 30, 2017 at 02:20:37PM +0900, Sergey Senozhatsky wrote:
> Byungchul, a quick question.

Hello Sergey,

> have you measured the performance impact? somehow my linux-next is

Yeah, it might have performance impact inevitably.

> notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
> is irritatingly slow)

To Ingo,

I cannot decide if we have to roll back CONFIG_LOCKDEP_CROSSRELEASE
dependency on CONFIG_PROVE_LOCKING in Kconfig. With them enabled,
lockdep detection becomes strong but has performance impact. But,
it's anyway a debug option so IMHO we don't have to take case of the
performance impact. Please let me know your decision.

> `time dmesg' shows some difference, but probably that's not a good
> test.
> 
>   !LOCKDEPLOCKDEP LOCKDEP -CROSSRELEASE -COMPLETIONS
>   real 0m0.661s   0m2.290s0m1.920s
>   user 0m0.010s   0m0.105s0m0.000s
>   sys  0m0.636s   0m2.224s0m1.888s
> 
> anyone else "sees"/"can confirm" the slow down?
> 
> 
> it gets back to "usual normal" when I disable CROSSRELEASE and COMPLETIONS.
> 
> ---
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index b19c491cbc4e..cdc30ef81c5e 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1091,8 +1091,6 @@ config PROVE_LOCKING
> select DEBUG_MUTEXES
> select DEBUG_RT_MUTEXES if RT_MUTEXES
> select DEBUG_LOCK_ALLOC
> -   select LOCKDEP_CROSSRELEASE
> -   select LOCKDEP_COMPLETIONS
> select TRACE_IRQFLAGS
> default n
> help
> 
> ---
> 
>   -ss

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

[Byungchul Park]

On Wed, Aug 30, 2017 at 02:20:37PM +0900, Sergey Senozhatsky wrote:
> Byungchul, a quick question.

Hello Sergey,

> have you measured the performance impact? somehow my linux-next is

Yeah, it might have performance impact inevitably.

> notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
> is irritatingly slow)

To Ingo,

I cannot decide if we have to roll back CONFIG_LOCKDEP_CROSSRELEASE
dependency on CONFIG_PROVE_LOCKING in Kconfig. With them enabled,
lockdep detection becomes strong but has performance impact. But,
it's anyway a debug option so IMHO we don't have to take case of the
performance impact. Please let me know your decision.

> `time dmesg' shows some difference, but probably that's not a good
> test.
> 
>   !LOCKDEPLOCKDEP LOCKDEP -CROSSRELEASE -COMPLETIONS
>   real 0m0.661s   0m2.290s0m1.920s
>   user 0m0.010s   0m0.105s0m0.000s
>   sys  0m0.636s   0m2.224s0m1.888s
> 
> anyone else "sees"/"can confirm" the slow down?
> 
> 
> it gets back to "usual normal" when I disable CROSSRELEASE and COMPLETIONS.
> 
> ---
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index b19c491cbc4e..cdc30ef81c5e 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1091,8 +1091,6 @@ config PROVE_LOCKING
> select DEBUG_MUTEXES
> select DEBUG_RT_MUTEXES if RT_MUTEXES
> select DEBUG_LOCK_ALLOC
> -   select LOCKDEP_CROSSRELEASE
> -   select LOCKDEP_COMPLETIONS
> select TRACE_IRQFLAGS
> default n
> help
> 
> ---
> 
>   -ss

Re: [PATCH net-next v3 0/3] NCSI VLAN Filtering Support

[David Miller]

From: Samuel Mendoza-Jonas 
Date: Wed, 30 Aug 2017 14:37:21 +1000

> On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
>> From: Samuel Mendoza-Jonas 
>> Date: Mon, 28 Aug 2017 16:18:40 +1000
>> 
>> > This series (mainly patch 2) adds VLAN filtering to the NCSI 
>> > implementation.
>> > A fair amount of code already exists in the NCSI stack for VLAN filtering 
>> > but
>> > none of it is actually hooked up. This goes the final mile and fixes a few
>> > bugs in the existing code found along the way (patch 1).
>> > 
>> > Patch 3 adds the appropriate flag and callbacks to the ftgmac100 driver to
>> > enable filtering as it's a large consumer of NCSI (and what I've been
>> > testing on).
>> > 
>> > v3:   - Add comment describing change to ncsi_find_filter()
>> >   - Catch NULL in clear_one_vid() from ncsi_get_filter()
>> >   - Simplify state changes when kicking updated channel
>> 
>> Series applied.
> 
> Thanks David,
> 
> The kbuild bot caught a build error where the add/kill callbacks aren't
> defined without CONFIG_NET_NCSI:
> 
>>> ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>>> undefined!
>>> ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>>> undefined!
> 
> It's a quick fixup to patch 3 as below, would you like me to send it as a v4?

You must submit a formal fixup patch to fix bugs if I've said that I've
already applied your patch.

Re: [PATCH net-next v3 0/3] NCSI VLAN Filtering Support

[David Miller]

From: Samuel Mendoza-Jonas 
Date: Wed, 30 Aug 2017 14:37:21 +1000

> On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
>> From: Samuel Mendoza-Jonas 
>> Date: Mon, 28 Aug 2017 16:18:40 +1000
>> 
>> > This series (mainly patch 2) adds VLAN filtering to the NCSI 
>> > implementation.
>> > A fair amount of code already exists in the NCSI stack for VLAN filtering 
>> > but
>> > none of it is actually hooked up. This goes the final mile and fixes a few
>> > bugs in the existing code found along the way (patch 1).
>> > 
>> > Patch 3 adds the appropriate flag and callbacks to the ftgmac100 driver to
>> > enable filtering as it's a large consumer of NCSI (and what I've been
>> > testing on).
>> > 
>> > v3:   - Add comment describing change to ncsi_find_filter()
>> >   - Catch NULL in clear_one_vid() from ncsi_get_filter()
>> >   - Simplify state changes when kicking updated channel
>> 
>> Series applied.
> 
> Thanks David,
> 
> The kbuild bot caught a build error where the add/kill callbacks aren't
> defined without CONFIG_NET_NCSI:
> 
>>> ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>>> undefined!
>>> ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>>> undefined!
> 
> It's a quick fixup to patch 3 as below, would you like me to send it as a v4?

You must submit a formal fixup patch to fix bugs if I've said that I've
already applied your patch.

Re: printk: what is going on with additional newlines?

[Sergey Senozhatsky]

On (08/29/17 19:58), Joe Perches wrote:
> > > 
> > > Why?
> > > 
> > > What's wrong with a simple printk?
> > > It'd still do a log_store.
> > 
> > sure, it will. but in separate logbuf entries, and between two
> > consequent printk calls on the same CPU a lot of stuff can happen:
> 
> I think you don't quite understand how this would work.
> The idea is that the entire concatenated bit would be emitted
> in one go.

may be :)

I was thinking about the way to make it work in similar way with
printk-safe/printk-nmi. basically seq buffer should hold both
continuation and "normal" lines, IMHO. when we emit the buffer
we do something like this

/* Print line by line. */
while (c < end) {
if (*c == '\n') {
printk_safe_flush_line(start, c - start + 1);
start = ++c;
header = true;
continue;
}

/* Handle continuous lines or missing new line. */
if ((c + 1 < end) && printk_get_level(c)) {
if (header) {
c = printk_skip_level(c);
continue;
}

printk_safe_flush_line(start, c - start);
start = c++;
header = true;
continue;
}

header = false;
c++;
}

except that instead of printk_safe_flush_line() we will call log_store()
and the whole loop will be under logbuf_lock.

for that to work, we need API to require header/loglevel etc for every
message. so the use case can look like this:

init_printk_buffer();
print_line(, KERN_ERR "Oops\n");

print_line(, KERN_ERR "continuation line: foo");
print_line(, KERN_CONT "bar");
print_line(, KERN_CONT "baz\n");
...

print_line(, KERN_ERR "\n");
...
print_line(, KERN_ERR "--- end of oops ---\n");
emit_printk_buffer();

so that not only concatenated continuation lines will be handled,
but also more complex things. like backtraces or whatever someone
might want to handle.

-ss

Re: printk: what is going on with additional newlines?

[Sergey Senozhatsky]

On (08/29/17 19:58), Joe Perches wrote:
> > > 
> > > Why?
> > > 
> > > What's wrong with a simple printk?
> > > It'd still do a log_store.
> > 
> > sure, it will. but in separate logbuf entries, and between two
> > consequent printk calls on the same CPU a lot of stuff can happen:
> 
> I think you don't quite understand how this would work.
> The idea is that the entire concatenated bit would be emitted
> in one go.

may be :)

I was thinking about the way to make it work in similar way with
printk-safe/printk-nmi. basically seq buffer should hold both
continuation and "normal" lines, IMHO. when we emit the buffer
we do something like this

/* Print line by line. */
while (c < end) {
if (*c == '\n') {
printk_safe_flush_line(start, c - start + 1);
start = ++c;
header = true;
continue;
}

/* Handle continuous lines or missing new line. */
if ((c + 1 < end) && printk_get_level(c)) {
if (header) {
c = printk_skip_level(c);
continue;
}

printk_safe_flush_line(start, c - start);
start = c++;
header = true;
continue;
}

header = false;
c++;
}

except that instead of printk_safe_flush_line() we will call log_store()
and the whole loop will be under logbuf_lock.

for that to work, we need API to require header/loglevel etc for every
message. so the use case can look like this:

init_printk_buffer();
print_line(, KERN_ERR "Oops\n");

print_line(, KERN_ERR "continuation line: foo");
print_line(, KERN_CONT "bar");
print_line(, KERN_CONT "baz\n");
...

print_line(, KERN_ERR "\n");
...
print_line(, KERN_ERR "--- end of oops ---\n");
emit_printk_buffer();

so that not only concatenated continuation lines will be handled,
but also more complex things. like backtraces or whatever someone
might want to handle.

-ss

Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver

[Kishon Vijay Abraham I]

Hi,

On Tuesday 29 August 2017 06:42 PM, Antoine Tenart wrote:
> Hi Kishon,
> 
> On Tue, Aug 29, 2017 at 05:55:06PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
>>> On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
 On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> + /* lane 0 */
> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> + /* lane 1 */
> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> + /* lane 2 */
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> + /* lane 3 */
> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> + /* lane 4 */
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> + /* lane 5 */
> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> +};

 IMHO all the lane and mode configuration should come from dt. That would 
 make
 it more reusable when comphy is configured differently.
>>>
>>> These connexions between engines and the comphy lanes are inside the
>>> SoC. They won't change for a given SoC, and the actual configuration is
>>> at the board level to know what is connected to the output of a given
>>> lane, which is already described into the dt (the lane phandle).
>>>
>>> So I think we can keep this inside the driver, and we'll had other
>>> tables if the same comphy is ever used in another SoC.
>>>
>>> What do you think?
>>
>> I'd like to avoid adding tables for every SoC. These are configuration 
>> details
>> and can come from dt.
> 
> Actually this is per CP design, not SoC (this one is used in both 7k and
> 8k SoCs from Marvell, and probably others). I'm still not convinced this
> is a good idea to put this into the dt. First of all we would end up with
> something like (and this is only for a single lane, out of *6*):
> 
> cpm_comphy: phy@phy@12 {
>   compatible = "marvell,comphy-cp110";
>   reg = <0x12 0x6000>;
>   marvell,system-controller = <_syscon0>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   cpm_comphy0: phy@0 {
>   reg = <0>;
>   #phy-cells = <1>;
> 
>   mode@0 {
>   phy-mode = PHY_MODE_SGMII;
>   selector = <0x1>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@1 {
>   phy-mode = PHY_MODE_HS_SGMII;
>   selector = <0x1>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@2 {
>   phy-mode = PHY_MODE_RXAUI;
>   selector = <0x2>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@3 {
>   phy-mode = PHY_MODE_10GKR;
>   selector = <0x2>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@4 {
>   phy-mode = PHY_MODE_SATA;
>   selector = <0x4>;
>   pipe-selector = <0x0>;
>   port = <1>;
>   };
> 
>   mode@5 {
>   phy-mode = PHY_MODE_USB;
>   selector = <0x0>;
>   pipe-selector = <0x1>;
>   port = <2>;
>   };
> 
>   mode@6 {
>   phy-mode = PHY_MODE_USB;
>   selector = <0x0>;
>   pipe-selector = <0x2>;
>   port = <0>;
>   };

I think we should just select the mode that a particular lane has been
configured here instead of populating all the modes. But I think that doesn't
make sense since the mode is set by the consumer and the initial mode is
INVALID. So ignore my comment on having it in dt.
> 
>   ... + PCIe, other ports ...
>   };
> 
>   cpm_comphy1: phy@1 {
>   ...
>   };
> 
>   ...
> };
> 
> And this "configuration" makes us think the comphy driver would be
> somehow generic with only these parameters to update when using a
> different CP. In reality we do have one other comphy in another CP, and
> it requires more than just updating the above parameters: the init
> functions also are SoC specific. So the table used in the patch proposed
> only is a small part of this "configuration". In fact it's not a
> configuration at all, but only a mode-to-bit indirection, used in the
> comphy init functions.
> 
> What is proposed instead, is very close to what actually changes a lot,
> and what a designer can change: the CP 

Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver

[Kishon Vijay Abraham I]

Hi,

On Tuesday 29 August 2017 06:42 PM, Antoine Tenart wrote:
> Hi Kishon,
> 
> On Tue, Aug 29, 2017 at 05:55:06PM +0530, Kishon Vijay Abraham I wrote:
>> On Tuesday 29 August 2017 04:53 PM, Antoine Tenart wrote:
>>> On Tue, Aug 29, 2017 at 04:34:17PM +0530, Kishon Vijay Abraham I wrote:
 On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> +static const struct mvebu_comhy_conf mvebu_comphy_cp110_modes[] = {
> + /* lane 0 */
> + MVEBU_COMPHY_CONF(0, 1, PHY_MODE_SGMII, 0x1),
> + /* lane 1 */
> + MVEBU_COMPHY_CONF(1, 2, PHY_MODE_SGMII, 0x1),
> + /* lane 2 */
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_SGMII, 0x1),
> + MVEBU_COMPHY_CONF(2, 0, PHY_MODE_10GKR, 0x1),
> + /* lane 3 */
> + MVEBU_COMPHY_CONF(3, 1, PHY_MODE_SGMII, 0x2),
> + /* lane 4 */
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_SGMII, 0x2),
> + MVEBU_COMPHY_CONF(4, 0, PHY_MODE_10GKR, 0x2),
> + MVEBU_COMPHY_CONF(4, 1, PHY_MODE_SGMII, 0x1),
> + /* lane 5 */
> + MVEBU_COMPHY_CONF(5, 2, PHY_MODE_SGMII, 0x1),
> +};

 IMHO all the lane and mode configuration should come from dt. That would 
 make
 it more reusable when comphy is configured differently.
>>>
>>> These connexions between engines and the comphy lanes are inside the
>>> SoC. They won't change for a given SoC, and the actual configuration is
>>> at the board level to know what is connected to the output of a given
>>> lane, which is already described into the dt (the lane phandle).
>>>
>>> So I think we can keep this inside the driver, and we'll had other
>>> tables if the same comphy is ever used in another SoC.
>>>
>>> What do you think?
>>
>> I'd like to avoid adding tables for every SoC. These are configuration 
>> details
>> and can come from dt.
> 
> Actually this is per CP design, not SoC (this one is used in both 7k and
> 8k SoCs from Marvell, and probably others). I'm still not convinced this
> is a good idea to put this into the dt. First of all we would end up with
> something like (and this is only for a single lane, out of *6*):
> 
> cpm_comphy: phy@phy@12 {
>   compatible = "marvell,comphy-cp110";
>   reg = <0x12 0x6000>;
>   marvell,system-controller = <_syscon0>;
>   #address-cells = <1>;
>   #size-cells = <0>;
> 
>   cpm_comphy0: phy@0 {
>   reg = <0>;
>   #phy-cells = <1>;
> 
>   mode@0 {
>   phy-mode = PHY_MODE_SGMII;
>   selector = <0x1>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@1 {
>   phy-mode = PHY_MODE_HS_SGMII;
>   selector = <0x1>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@2 {
>   phy-mode = PHY_MODE_RXAUI;
>   selector = <0x2>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@3 {
>   phy-mode = PHY_MODE_10GKR;
>   selector = <0x2>;
>   pipe-selector = <0x0>;
>   port = <0>;
>   };
> 
>   mode@4 {
>   phy-mode = PHY_MODE_SATA;
>   selector = <0x4>;
>   pipe-selector = <0x0>;
>   port = <1>;
>   };
> 
>   mode@5 {
>   phy-mode = PHY_MODE_USB;
>   selector = <0x0>;
>   pipe-selector = <0x1>;
>   port = <2>;
>   };
> 
>   mode@6 {
>   phy-mode = PHY_MODE_USB;
>   selector = <0x0>;
>   pipe-selector = <0x2>;
>   port = <0>;
>   };

I think we should just select the mode that a particular lane has been
configured here instead of populating all the modes. But I think that doesn't
make sense since the mode is set by the consumer and the initial mode is
INVALID. So ignore my comment on having it in dt.
> 
>   ... + PCIe, other ports ...
>   };
> 
>   cpm_comphy1: phy@1 {
>   ...
>   };
> 
>   ...
> };
> 
> And this "configuration" makes us think the comphy driver would be
> somehow generic with only these parameters to update when using a
> different CP. In reality we do have one other comphy in another CP, and
> it requires more than just updating the above parameters: the init
> functions also are SoC specific. So the table used in the patch proposed
> only is a small part of this "configuration". In fact it's not a
> configuration at all, but only a mode-to-bit indirection, used in the
> comphy init functions.
> 
> What is proposed instead, is very close to what actually changes a lot,
> and what a designer can change: the CP 

Re: [kernel-hardening] [PATCH v5 04/10] arm64: Add __flush_tlb_one()

[Juerg Haefliger]

On 08/23/2017 07:04 PM, Mark Rutland wrote:
> On Wed, Aug 23, 2017 at 10:58:42AM -0600, Tycho Andersen wrote:
>> Hi Mark,
>>
>> On Mon, Aug 14, 2017 at 05:50:47PM +0100, Mark Rutland wrote:
>>> That said, is there any reason not to use flush_tlb_kernel_range()
>>> directly?
>>
>> So it turns out that there is a difference between __flush_tlb_one() and
>> flush_tlb_kernel_range() on x86: flush_tlb_kernel_range() flushes all the 
>> TLBs
>> via on_each_cpu(), where as __flush_tlb_one() only flushes the local TLB 
>> (which
>> I think is enough here).
> 
> That sounds suspicious; I don't think that __flush_tlb_one() is
> sufficient.
> 
> If you only do local TLB maintenance, then the page is left accessible
> to other CPUs via the (stale) kernel mappings. i.e. the page isn't
> exclusively mapped by userspace.

We flush all CPUs to get rid of stale entries when a new page is
allocated to userspace that was previously allocated to the kernel.
Is that the scenario you were thinking of?

...Juerg


> Thanks,
> Mark.
> 



signature.asc
Description: OpenPGP digital signature

Re: [kernel-hardening] [PATCH v5 04/10] arm64: Add __flush_tlb_one()

[Juerg Haefliger]

On 08/23/2017 07:04 PM, Mark Rutland wrote:
> On Wed, Aug 23, 2017 at 10:58:42AM -0600, Tycho Andersen wrote:
>> Hi Mark,
>>
>> On Mon, Aug 14, 2017 at 05:50:47PM +0100, Mark Rutland wrote:
>>> That said, is there any reason not to use flush_tlb_kernel_range()
>>> directly?
>>
>> So it turns out that there is a difference between __flush_tlb_one() and
>> flush_tlb_kernel_range() on x86: flush_tlb_kernel_range() flushes all the 
>> TLBs
>> via on_each_cpu(), where as __flush_tlb_one() only flushes the local TLB 
>> (which
>> I think is enough here).
> 
> That sounds suspicious; I don't think that __flush_tlb_one() is
> sufficient.
> 
> If you only do local TLB maintenance, then the page is left accessible
> to other CPUs via the (stale) kernel mappings. i.e. the page isn't
> exclusively mapped by userspace.

We flush all CPUs to get rid of stale entries when a new page is
allocated to userspace that was previously allocated to the kernel.
Is that the scenario you were thinking of?

...Juerg


> Thanks,
> Mark.
> 



signature.asc
Description: OpenPGP digital signature

[PATCH] staging:rt8712:xmit_linux.c: Avoid multiple assignments in a single line

[harsha]

Fixed coding style issue

Signed-off-by: Harsha Sharma 
---
 drivers/staging/rtl8712/xmit_linux.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/xmit_linux.c 
b/drivers/staging/rtl8712/xmit_linux.c
index d13fd15..03c6b0c 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -49,8 +49,10 @@ static uint remainder_len(struct pkt_file *pfile)
 void _r8712_open_pktfile(_pkt *pktptr, struct pkt_file *pfile)
 {
pfile->pkt = pktptr;
-   pfile->cur_addr = pfile->buf_start = pktptr->data;
-   pfile->pkt_len = pfile->buf_len = pktptr->len;
+   pfile->cur_addr = pktptr->data;
+   pfile->buf_start = pfile->cur_addr;
+   pfile->pkt_len = pktptr->len;
+   pfile->buf_len = pfile->pkt_len;
pfile->cur_buffer = pfile->buf_start;
 }
 
-- 
1.9.1

[PATCH] staging:rt8712:xmit_linux.c: Avoid multiple assignments in a single line

[harsha]

Fixed coding style issue

Signed-off-by: Harsha Sharma 
---
 drivers/staging/rtl8712/xmit_linux.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8712/xmit_linux.c 
b/drivers/staging/rtl8712/xmit_linux.c
index d13fd15..03c6b0c 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -49,8 +49,10 @@ static uint remainder_len(struct pkt_file *pfile)
 void _r8712_open_pktfile(_pkt *pktptr, struct pkt_file *pfile)
 {
pfile->pkt = pktptr;
-   pfile->cur_addr = pfile->buf_start = pktptr->data;
-   pfile->pkt_len = pfile->buf_len = pktptr->len;
+   pfile->cur_addr = pktptr->data;
+   pfile->buf_start = pfile->cur_addr;
+   pfile->pkt_len = pktptr->len;
+   pfile->buf_len = pfile->pkt_len;
pfile->cur_buffer = pfile->buf_start;
 }
 
-- 
1.9.1

Dear Talented

[BSFS]

Dear Talented,

I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film 
Corporation Located in the United State, is Soliciting for the Right to use 
Your Photo/Face and Personality as One of the Semi -Major Role/ Character in 
our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Anubis (Anubis 2018) 
The Movie is Currently Filming (In Production) Please Note That There Will Be 
No Auditions, Traveling or Any Special / Professional Acting Skills, Since the 
Production of This Movie Will Be Done with our State of Art Computer - 
Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of 
$620,000.00 USD. For
More Information/Understanding, Please Write us via this email.

Note: Only the Response send to this mail will be Given a Prior Consideration.

Talent Scout

Dear Talented

[BSFS]

Dear Talented,

I am Talent Scout For BLUE SKY FILM STUDIO, Present Blue sky Studio a Film 
Corporation Located in the United State, is Soliciting for the Right to use 
Your Photo/Face and Personality as One of the Semi -Major Role/ Character in 
our Upcoming ANIMATED Stereoscope 3D Movie-The Story of Anubis (Anubis 2018) 
The Movie is Currently Filming (In Production) Please Note That There Will Be 
No Auditions, Traveling or Any Special / Professional Acting Skills, Since the 
Production of This Movie Will Be Done with our State of Art Computer - 
Generating Imagery Equipment. We Are Prepared to Pay the Total Sum of 
$620,000.00 USD. For
More Information/Understanding, Please Write us via this email.

Note: Only the Response send to this mail will be Given a Prior Consideration.

Talent Scout

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Anshuman Khandual]

On 08/27/2017 05:48 AM, Kirill A. Shutemov wrote:
>> +/* Transparent huge pages are not supported. */
>> +if (unlikely(pmd_trans_huge(*pmd)))
>> +goto out_walk;
> That's looks like a blocker to me.
> 
> Is there any problem with making it supported (besides plain coding)?

IIUC we would have to reattempt once for each PMD level fault because
of the lack of a page table entry there. Besides do we want to support
huge pages in general as part of speculative page fault path ? The
number of faults will be very less (256 times lower on POWER and 512
times lower on X86). So is it worth it ? BTW calling hugetlb_fault()
after figuring out the VMA, works correctly inside handle_speculative
_fault() last time I checked.

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Anshuman Khandual]

On 08/27/2017 05:48 AM, Kirill A. Shutemov wrote:
>> +/* Transparent huge pages are not supported. */
>> +if (unlikely(pmd_trans_huge(*pmd)))
>> +goto out_walk;
> That's looks like a blocker to me.
> 
> Is there any problem with making it supported (besides plain coding)?

IIUC we would have to reattempt once for each PMD level fault because
of the lack of a page table entry there. Besides do we want to support
huge pages in general as part of speculative page fault path ? The
number of faults will be very less (256 times lower on POWER and 512
times lower on X86). So is it worth it ? BTW calling hugetlb_fault()
after figuring out the VMA, works correctly inside handle_speculative
_fault() last time I checked.

[PATCH -mm] mm: Improve readability of clear_huge_page

[Huang, Ying]

From: Huang Ying 

The optimized clear_huge_page() isn't easy to read and understand.
This is suggested by Michael Hocko to improve it.

Suggested-by: Michal Hocko 
Signed-off-by: "Huang, Ying" 
---
 mm/memory.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 20ac58c128e9..694ddbd3a020 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4507,12 +4507,15 @@ void clear_huge_page(struct page *page,
 * towards the sub-page to access
 */
for (i = 0; i < l; i++) {
+   int left_idx = base + i;
+   int right_idx = base + 2 * l - 1 - i;
+
cond_resched();
-   clear_user_highpage(page + base + i,
-   addr + (base + i) * PAGE_SIZE);
+   clear_user_highpage(page + left_idx,
+   addr + left_idx * PAGE_SIZE);
cond_resched();
-   clear_user_highpage(page + base + 2 * l - 1 - i,
-   addr + (base + 2 * l - 1 - i) * PAGE_SIZE);
+   clear_user_highpage(page + right_idx,
+   addr + right_idx * PAGE_SIZE);
}
 }
 
-- 
2.13.2

[PATCH -mm] mm: Improve readability of clear_huge_page

[Huang, Ying]

From: Huang Ying 

The optimized clear_huge_page() isn't easy to read and understand.
This is suggested by Michael Hocko to improve it.

Suggested-by: Michal Hocko 
Signed-off-by: "Huang, Ying" 
---
 mm/memory.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index 20ac58c128e9..694ddbd3a020 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4507,12 +4507,15 @@ void clear_huge_page(struct page *page,
 * towards the sub-page to access
 */
for (i = 0; i < l; i++) {
+   int left_idx = base + i;
+   int right_idx = base + 2 * l - 1 - i;
+
cond_resched();
-   clear_user_highpage(page + base + i,
-   addr + (base + i) * PAGE_SIZE);
+   clear_user_highpage(page + left_idx,
+   addr + left_idx * PAGE_SIZE);
cond_resched();
-   clear_user_highpage(page + base + 2 * l - 1 - i,
-   addr + (base + 2 * l - 1 - i) * PAGE_SIZE);
+   clear_user_highpage(page + right_idx,
+   addr + right_idx * PAGE_SIZE);
}
 }
 
-- 
2.13.2

Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver

[Kishon Vijay Abraham I]

Hi Antoine,

On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> On the CP110 unit, which can be found on various Marvell platforms such
> as the 7k and 8k (currently), a comphy (common PHYs) hardware block can
> be found. This block provides a number of PHYs which can be used in
> various modes by other controllers (network, SATA ...). These common
> PHYs must be configured for the controllers using them to work correctly
> either at boot time, or when the system runs to switch the mode used.
> This patch adds a driver for this comphy hardware block, providing
> callbacks for the its PHYs so that consumers can configure the modes
> used.
> 
> As of this commit, two modes are supported by the comphy driver: sgmii
> and 10gkr.

Have one more minor comment in addition to my previous comments..
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/phy/marvell/Kconfig  |  10 +
>  drivers/phy/marvell/Makefile |   1 +
>  drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 656 
> +++
>  3 files changed, 667 insertions(+)
>  create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> 
> diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
> index 048d8893bc2e..26755f3d1a9a 100644
> --- a/drivers/phy/marvell/Kconfig
> +++ b/drivers/phy/marvell/Kconfig
> @@ -21,6 +21,16 @@ config PHY_BERLIN_USB
>   help
> Enable this to support the USB PHY on Marvell Berlin SoCs.
>  
> +config PHY_MVEBU_CP110_COMPHY
> + tristate "Marvell CP110 comphy driver"
> + depends on ARCH_MVEBU && OF
> + select GENERIC_PHY
> + help
> +   This driver allows to control the comphy, an hardware block providing
> +   shared serdes PHYs on Marvell Armada 7k/8k (in the CP110). Its serdes
> +   lanes can be used by various controllers (Ethernet, sata, usb,
> +   PCIe...).
> +
>  config PHY_MVEBU_SATA
>   def_bool y
>   depends on ARCH_DOVE || MACH_DOVE || MACH_KIRKWOOD
> diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
> index 3fc188f59118..0cf6a7cbaf9f 100644
> --- a/drivers/phy/marvell/Makefile
> +++ b/drivers/phy/marvell/Makefile
> @@ -1,6 +1,7 @@
>  obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)   += phy-armada375-usb2.o
>  obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
>  obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> +obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
>  obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
>  obj-$(CONFIG_PHY_PXA_28NM_HSIC)  += phy-pxa-28nm-hsic.o
>  obj-$(CONFIG_PHY_PXA_28NM_USB2)  += phy-pxa-28nm-usb2.o
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
> b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> new file mode 100644
> index ..41556e790856
> --- /dev/null
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -0,0 +1,656 @@
> +/*
> + * Copyright (C) 2017 Marvell
> + *
> + * Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Relative to priv->base */
> +#define MVEBU_COMPHY_SERDES_CFG0(n)  (0x0 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_PLL  BIT(1)
> +#define MVEBU_COMPHY_SERDES_CFG0_GEN_RX(n)   ((n) << 3)
> +#define MVEBU_COMPHY_SERDES_CFG0_GEN_TX(n)   ((n) << 7)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_RX   BIT(11)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_TX   BIT(12)
> +#define MVEBU_COMPHY_SERDES_CFG0_HALF_BUSBIT(14)
> +#define MVEBU_COMPHY_SERDES_CFG1(n)  (0x4 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG1_RESET   BIT(3)
> +#define MVEBU_COMPHY_SERDES_CFG1_RX_INIT BIT(4)
> +#define MVEBU_COMPHY_SERDES_CFG1_CORE_RESET  BIT(5)
> +#define MVEBU_COMPHY_SERDES_CFG1_RF_RESETBIT(6)
> +#define MVEBU_COMPHY_SERDES_CFG2(n)  (0x8 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG2_DFE_EN  BIT(4)
> +#define MVEBU_COMPHY_SERDES_STATUS0(n)   (0x18 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_STATUS0_TX_PLL_RDY   BIT(2)
> +#define MVEBU_COMPHY_SERDES_STATUS0_RX_PLL_RDY   BIT(3)
> +#define MVEBU_COMPHY_SERDES_STATUS0_RX_INIT  BIT(4)
> +#define MVEBU_COMPHY_PWRPLL_CTRL(n)  (0x804 + (n) * 0x1000)
> +#define MVEBU_COMPHY_PWRPLL_CTRL_RFREQ(n)((n) << 0)
> +#define MVEBU_COMPHY_PWRPLL_PHY_MODE(n)  ((n) << 5)
> +#define MVEBU_COMPHY_IMP_CAL(n)  (0x80c + (n) * 0x1000)
> +#define MVEBU_COMPHY_IMP_CAL_TX_EXT(n)   ((n) << 10)
> +#define MVEBU_COMPHY_IMP_CAL_TX_EXT_EN   BIT(15)
> +#define MVEBU_COMPHY_DFE_RES(n)  (0x81c + 

Re: [PATCH net-next v3 02/13] phy: add the mvebu cp110 comphy driver

[Kishon Vijay Abraham I]

Hi Antoine,

On Monday 28 August 2017 08:27 PM, Antoine Tenart wrote:
> On the CP110 unit, which can be found on various Marvell platforms such
> as the 7k and 8k (currently), a comphy (common PHYs) hardware block can
> be found. This block provides a number of PHYs which can be used in
> various modes by other controllers (network, SATA ...). These common
> PHYs must be configured for the controllers using them to work correctly
> either at boot time, or when the system runs to switch the mode used.
> This patch adds a driver for this comphy hardware block, providing
> callbacks for the its PHYs so that consumers can configure the modes
> used.
> 
> As of this commit, two modes are supported by the comphy driver: sgmii
> and 10gkr.

Have one more minor comment in addition to my previous comments..
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/phy/marvell/Kconfig  |  10 +
>  drivers/phy/marvell/Makefile |   1 +
>  drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 656 
> +++
>  3 files changed, 667 insertions(+)
>  create mode 100644 drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> 
> diff --git a/drivers/phy/marvell/Kconfig b/drivers/phy/marvell/Kconfig
> index 048d8893bc2e..26755f3d1a9a 100644
> --- a/drivers/phy/marvell/Kconfig
> +++ b/drivers/phy/marvell/Kconfig
> @@ -21,6 +21,16 @@ config PHY_BERLIN_USB
>   help
> Enable this to support the USB PHY on Marvell Berlin SoCs.
>  
> +config PHY_MVEBU_CP110_COMPHY
> + tristate "Marvell CP110 comphy driver"
> + depends on ARCH_MVEBU && OF
> + select GENERIC_PHY
> + help
> +   This driver allows to control the comphy, an hardware block providing
> +   shared serdes PHYs on Marvell Armada 7k/8k (in the CP110). Its serdes
> +   lanes can be used by various controllers (Ethernet, sata, usb,
> +   PCIe...).
> +
>  config PHY_MVEBU_SATA
>   def_bool y
>   depends on ARCH_DOVE || MACH_DOVE || MACH_KIRKWOOD
> diff --git a/drivers/phy/marvell/Makefile b/drivers/phy/marvell/Makefile
> index 3fc188f59118..0cf6a7cbaf9f 100644
> --- a/drivers/phy/marvell/Makefile
> +++ b/drivers/phy/marvell/Makefile
> @@ -1,6 +1,7 @@
>  obj-$(CONFIG_ARMADA375_USBCLUSTER_PHY)   += phy-armada375-usb2.o
>  obj-$(CONFIG_PHY_BERLIN_SATA)+= phy-berlin-sata.o
>  obj-$(CONFIG_PHY_BERLIN_USB) += phy-berlin-usb.o
> +obj-$(CONFIG_PHY_MVEBU_CP110_COMPHY) += phy-mvebu-cp110-comphy.o
>  obj-$(CONFIG_PHY_MVEBU_SATA) += phy-mvebu-sata.o
>  obj-$(CONFIG_PHY_PXA_28NM_HSIC)  += phy-pxa-28nm-hsic.o
>  obj-$(CONFIG_PHY_PXA_28NM_USB2)  += phy-pxa-28nm-usb2.o
> diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
> b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> new file mode 100644
> index ..41556e790856
> --- /dev/null
> +++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
> @@ -0,0 +1,656 @@
> +/*
> + * Copyright (C) 2017 Marvell
> + *
> + * Antoine Tenart 
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Relative to priv->base */
> +#define MVEBU_COMPHY_SERDES_CFG0(n)  (0x0 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_PLL  BIT(1)
> +#define MVEBU_COMPHY_SERDES_CFG0_GEN_RX(n)   ((n) << 3)
> +#define MVEBU_COMPHY_SERDES_CFG0_GEN_TX(n)   ((n) << 7)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_RX   BIT(11)
> +#define MVEBU_COMPHY_SERDES_CFG0_PU_TX   BIT(12)
> +#define MVEBU_COMPHY_SERDES_CFG0_HALF_BUSBIT(14)
> +#define MVEBU_COMPHY_SERDES_CFG1(n)  (0x4 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG1_RESET   BIT(3)
> +#define MVEBU_COMPHY_SERDES_CFG1_RX_INIT BIT(4)
> +#define MVEBU_COMPHY_SERDES_CFG1_CORE_RESET  BIT(5)
> +#define MVEBU_COMPHY_SERDES_CFG1_RF_RESETBIT(6)
> +#define MVEBU_COMPHY_SERDES_CFG2(n)  (0x8 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_CFG2_DFE_EN  BIT(4)
> +#define MVEBU_COMPHY_SERDES_STATUS0(n)   (0x18 + (n) * 0x1000)
> +#define MVEBU_COMPHY_SERDES_STATUS0_TX_PLL_RDY   BIT(2)
> +#define MVEBU_COMPHY_SERDES_STATUS0_RX_PLL_RDY   BIT(3)
> +#define MVEBU_COMPHY_SERDES_STATUS0_RX_INIT  BIT(4)
> +#define MVEBU_COMPHY_PWRPLL_CTRL(n)  (0x804 + (n) * 0x1000)
> +#define MVEBU_COMPHY_PWRPLL_CTRL_RFREQ(n)((n) << 0)
> +#define MVEBU_COMPHY_PWRPLL_PHY_MODE(n)  ((n) << 5)
> +#define MVEBU_COMPHY_IMP_CAL(n)  (0x80c + (n) * 0x1000)
> +#define MVEBU_COMPHY_IMP_CAL_TX_EXT(n)   ((n) << 10)
> +#define MVEBU_COMPHY_IMP_CAL_TX_EXT_EN   BIT(15)
> +#define MVEBU_COMPHY_DFE_RES(n)  (0x81c + (n) * 0x1000)
> +#define MVEBU_COMPHY_DFE_RES_FORCE_GEN_TBL   

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

[Sergey Senozhatsky]

On (08/23/17 09:03), Byungchul Park wrote:
[..]
> > Byungchul, did you add the crosslock checks to lockdep? Can you have a look 
> > at
> > the above report? That report namely doesn't make sense to me.
> 
> The report is talking about the following lockup:
> 
> A work in a worker A task work on exit to user
> -- ---
> mutex_lock(>bd_mutex)
>mutext_lock(>bd_mutex)
> blk_execute_rq()
>wait_for_completion_io_timeout()
>complete()
> 
[..]
> To Peterz,
> 
> Anyway I wanted to avoid lockdep reports in the case using a timeout
> interface. Do you think it's still worth reporting the kind of lockup?
> I'm ok if you do.

Byungchul, a quick question.
have you measured the performance impact? somehow my linux-next is
notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
is irritatingly slow)


`time dmesg' shows some difference, but probably that's not a good
test.

!LOCKDEPLOCKDEP LOCKDEP -CROSSRELEASE -COMPLETIONS
real 0m0.661s   0m2.290s0m1.920s
user 0m0.010s   0m0.105s0m0.000s
sys  0m0.636s   0m2.224s0m1.888s

anyone else "sees"/"can confirm" the slow down?


it gets back to "usual normal" when I disable CROSSRELEASE and COMPLETIONS.

---

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b19c491cbc4e..cdc30ef81c5e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1091,8 +1091,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE
-   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help

---

-ss

Re: possible circular locking dependency detected [was: linux-next: Tree for Aug 22]

[Sergey Senozhatsky]

On (08/23/17 09:03), Byungchul Park wrote:
[..]
> > Byungchul, did you add the crosslock checks to lockdep? Can you have a look 
> > at
> > the above report? That report namely doesn't make sense to me.
> 
> The report is talking about the following lockup:
> 
> A work in a worker A task work on exit to user
> -- ---
> mutex_lock(>bd_mutex)
>mutext_lock(>bd_mutex)
> blk_execute_rq()
>wait_for_completion_io_timeout()
>complete()
> 
[..]
> To Peterz,
> 
> Anyway I wanted to avoid lockdep reports in the case using a timeout
> interface. Do you think it's still worth reporting the kind of lockup?
> I'm ok if you do.

Byungchul, a quick question.
have you measured the performance impact? somehow my linux-next is
notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
is irritatingly slow)


`time dmesg' shows some difference, but probably that's not a good
test.

!LOCKDEPLOCKDEP LOCKDEP -CROSSRELEASE -COMPLETIONS
real 0m0.661s   0m2.290s0m1.920s
user 0m0.010s   0m0.105s0m0.000s
sys  0m0.636s   0m2.224s0m1.888s

anyone else "sees"/"can confirm" the slow down?


it gets back to "usual normal" when I disable CROSSRELEASE and COMPLETIONS.

---

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index b19c491cbc4e..cdc30ef81c5e 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1091,8 +1091,6 @@ config PROVE_LOCKING
select DEBUG_MUTEXES
select DEBUG_RT_MUTEXES if RT_MUTEXES
select DEBUG_LOCK_ALLOC
-   select LOCKDEP_CROSSRELEASE
-   select LOCKDEP_COMPLETIONS
select TRACE_IRQFLAGS
default n
help

---

-ss

Re: I/O hangs after resuming from suspend-to-ram

[Ming Lei]

On Wed, Aug 30, 2017 at 10:15:37AM +0800, Ming Lei wrote:
> Hi,
> 
> On Tue, Aug 29, 2017 at 05:52:42PM +0200, Oleksandr Natalenko wrote:
> > Hello.
> > 
> > Re-tested with v4.13-rc7 + proposed patch and got the same result.
> 
> Maybe there is another issue, I didn't use dmcrypt on raid10, will
> test in your way to see if I can reproduce it.
> 
> BTW, could you share us which blk-mq scheduler you are using on sata?
> The patch I posted should address one issue on none scheduler.

Can't reproduce even with putting dmcypt on raid10 after applying
my patch.

Could you apply the following debug patch and provide the dmesg log
after running the commands below?

# echo 9 > /proc/sys/kernel/printk
# echo devices > /sys/power/pm_test
# echo mem > /sys/power/state

BTW, it is better to provide the two sata disk(behind raid10) name.

diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index b44c1bb687a2..75b13248ea1c 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -53,17 +53,22 @@ static int scsi_dev_type_suspend(struct device *dev,
 {
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int err;
+   struct scsi_device *sdev = to_scsi_device(dev);
 
/* flush pending in-flight resume operations, suspend is synchronous */
async_synchronize_full_domain(_sd_pm_domain);
 
-   err = scsi_device_quiesce(to_scsi_device(dev));
+   sdev_printk(KERN_WARNING, sdev, "%s: enter\n", __func__);
+   err = scsi_device_quiesce(sdev);
if (err == 0) {
+   sdev_printk(KERN_WARNING, sdev, "%s: before suspend\n", 
__func__);
err = cb(dev, pm);
+   sdev_printk(KERN_WARNING, sdev, "%s: after suspend\n", 
__func__);
if (err)
-   scsi_device_resume(to_scsi_device(dev));
+   scsi_device_resume(sdev);
}
dev_dbg(dev, "scsi suspend: %d\n", err);
+   sdev_printk(KERN_WARNING, sdev, "%s: exit\n", __func__);
return err;
 }
 
@@ -72,9 +77,13 @@ static int scsi_dev_type_resume(struct device *dev,
 {
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int err = 0;
+   struct scsi_device *sdev = to_scsi_device(dev);
 
+   sdev_printk(KERN_WARNING, sdev, "%s: enter\n", __func__);
+   sdev_printk(KERN_WARNING, sdev, "%s: before resume\n", __func__);
err = cb(dev, pm);
-   scsi_device_resume(to_scsi_device(dev));
+   sdev_printk(KERN_WARNING, sdev, "%s: after resume\n", __func__);
+   scsi_device_resume(sdev);
dev_dbg(dev, "scsi resume: %d\n", err);
 
if (err == 0) {
@@ -83,6 +92,7 @@ static int scsi_dev_type_resume(struct device *dev,
pm_runtime_enable(dev);
}
 
+   sdev_printk(KERN_WARNING, sdev, "%s: exit\n", __func__);
return err;
 }


-- 
Ming

Re: I/O hangs after resuming from suspend-to-ram

[Ming Lei]

On Wed, Aug 30, 2017 at 10:15:37AM +0800, Ming Lei wrote:
> Hi,
> 
> On Tue, Aug 29, 2017 at 05:52:42PM +0200, Oleksandr Natalenko wrote:
> > Hello.
> > 
> > Re-tested with v4.13-rc7 + proposed patch and got the same result.
> 
> Maybe there is another issue, I didn't use dmcrypt on raid10, will
> test in your way to see if I can reproduce it.
> 
> BTW, could you share us which blk-mq scheduler you are using on sata?
> The patch I posted should address one issue on none scheduler.

Can't reproduce even with putting dmcypt on raid10 after applying
my patch.

Could you apply the following debug patch and provide the dmesg log
after running the commands below?

# echo 9 > /proc/sys/kernel/printk
# echo devices > /sys/power/pm_test
# echo mem > /sys/power/state

BTW, it is better to provide the two sata disk(behind raid10) name.

diff --git a/drivers/scsi/scsi_pm.c b/drivers/scsi/scsi_pm.c
index b44c1bb687a2..75b13248ea1c 100644
--- a/drivers/scsi/scsi_pm.c
+++ b/drivers/scsi/scsi_pm.c
@@ -53,17 +53,22 @@ static int scsi_dev_type_suspend(struct device *dev,
 {
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int err;
+   struct scsi_device *sdev = to_scsi_device(dev);
 
/* flush pending in-flight resume operations, suspend is synchronous */
async_synchronize_full_domain(_sd_pm_domain);
 
-   err = scsi_device_quiesce(to_scsi_device(dev));
+   sdev_printk(KERN_WARNING, sdev, "%s: enter\n", __func__);
+   err = scsi_device_quiesce(sdev);
if (err == 0) {
+   sdev_printk(KERN_WARNING, sdev, "%s: before suspend\n", 
__func__);
err = cb(dev, pm);
+   sdev_printk(KERN_WARNING, sdev, "%s: after suspend\n", 
__func__);
if (err)
-   scsi_device_resume(to_scsi_device(dev));
+   scsi_device_resume(sdev);
}
dev_dbg(dev, "scsi suspend: %d\n", err);
+   sdev_printk(KERN_WARNING, sdev, "%s: exit\n", __func__);
return err;
 }
 
@@ -72,9 +77,13 @@ static int scsi_dev_type_resume(struct device *dev,
 {
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
int err = 0;
+   struct scsi_device *sdev = to_scsi_device(dev);
 
+   sdev_printk(KERN_WARNING, sdev, "%s: enter\n", __func__);
+   sdev_printk(KERN_WARNING, sdev, "%s: before resume\n", __func__);
err = cb(dev, pm);
-   scsi_device_resume(to_scsi_device(dev));
+   sdev_printk(KERN_WARNING, sdev, "%s: after resume\n", __func__);
+   scsi_device_resume(sdev);
dev_dbg(dev, "scsi resume: %d\n", err);
 
if (err == 0) {
@@ -83,6 +92,7 @@ static int scsi_dev_type_resume(struct device *dev,
pm_runtime_enable(dev);
}
 
+   sdev_printk(KERN_WARNING, sdev, "%s: exit\n", __func__);
return err;
 }


-- 
Ming

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

[Stefan Metzmacher]

Hi,

>> This is great to see.  Is there a Linux implementation of the server side (in
>> Samba?) so that the client can be tested without needing a Windows server?
> 
> I'm not aware of a Linux implementation on server side.

Here's a very early work in progress branch:
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-rdma
It only explores how the protocol works, as it uses a userspace
smb-direct proxy (which works around the missing fork support of the
userspace libibverbs), which makes it really slow, but is required
in order to have the code tested in Samba's autobuild.

I think once this code lands in the kernel tree, we'll be able to
arrange a userspace api to it, in order to make a useful implementation,
so we can skip the userspace smb-dorect proxy.

metze



signature.asc
Description: OpenPGP digital signature

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

[Stefan Metzmacher]

Hi,

>> This is great to see.  Is there a Linux implementation of the server side (in
>> Samba?) so that the client can be tested without needing a Windows server?
> 
> I'm not aware of a Linux implementation on server side.

Here's a very early work in progress branch:
https://git.samba.org/?p=metze/samba/wip.git;a=shortlog;h=refs/heads/master3-rdma
It only explores how the protocol works, as it uses a userspace
smb-direct proxy (which works around the missing fork support of the
userspace libibverbs), which makes it really slow, but is required
in order to have the code tested in Samba's autobuild.

I think once this code lands in the kernel tree, we'll be able to
arrange a userspace api to it, in order to make a useful implementation,
so we can skip the userspace smb-dorect proxy.

metze



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Anshuman Khandual]

On 08/29/2017 07:15 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 03:18:25PM +0200, Laurent Dufour wrote:
>> On 29/08/2017 14:04, Peter Zijlstra wrote:
>>> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
 On 27/08/2017 02:18, Kirill A. Shutemov wrote:
>> +
>> +if (unlikely(!vma->anon_vma))
>> +goto unlock;
>
> It deserves a comment.

 You're right I'll add it in the next version.
 For the record, the root cause is that __anon_vma_prepare() requires the
 mmap_sem to be held because vm_next and vm_prev must be safe.
>>>
>>> But should that test not be:
>>>
>>> if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
>>> goto unlock;
>>>
>>> Because !anon vmas will never have ->anon_vma set and you don't want to
>>> exclude those.
>>
>> Yes in the case we later allow non anonymous vmas to be handled.
>> Currently only anonymous vmas are supported so the check is good enough,
>> isn't it ?
> 
> That wasn't at all clear from reading the code. This makes it clear
> ->anon_vma is only ever looked at for anonymous.
> 
> And like Kirill says, we _really_ should start allowing some (if not
> all) vm_ops. Large file based mappings aren't particularly rare.
> 
> I'm not sure we want to introduce a white-list or just bite the bullet
> and audit all ->fault() implementations. But either works and isn't
> terribly difficult, auditing all is more work though.

filemap_fault() is used as vma-vm_ops->fault() for most of the file
systems. Changing it can enable speculative fault support for all of
them. It will still exclude other driver based vma-vm_ops->fault()
implementation. AFAICS, __lock_page_or_retry() function can drop
mm->mmap_sem if the page could not be locked right away. As suggested
by Peterz, making it understand FAULT_FLAG_SPECULATIVE should be good
enough. The patch is lightly tested for file mappings on top of this
series.

diff --git a/mm/filemap.c b/mm/filemap.c
index a497024..08f3042 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
 int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
 unsigned int flags)
 {
+   if (flags & FAULT_FLAG_SPECULATIVE) {
+   if (flags & FAULT_FLAG_KILLABLE) {
+   int ret;
+
+   ret = __lock_page_killable(page);
+   if (ret)
+   return 0;
+   } else
+   __lock_page(page);
+   return 1;
+   }
+
if (flags & FAULT_FLAG_ALLOW_RETRY) {
/*
 * CAUTION! In this case, mmap_sem is not released
diff --git a/mm/memory.c b/mm/memory.c
index 549d235..02347f3 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3836,8 +3836,6 @@ static int handle_pte_fault(struct vm_fault *vmf)
if (!vmf->pte) {
if (vma_is_anonymous(vmf->vma))
return do_anonymous_page(vmf);
-   else if (vmf->flags & FAULT_FLAG_SPECULATIVE)
-   return VM_FAULT_RETRY;
else
return do_fault(vmf);
}
@@ -4012,17 +4010,7 @@ int handle_speculative_fault(struct mm_struct *mm, 
unsigned long address,
goto unlock;
}

-   /*
-* Can't call vm_ops service has we don't know what they would do
-* with the VMA.
-* This include huge page from hugetlbfs.
-*/
-   if (vma->vm_ops) {
-   trace_spf_vma_notsup(_RET_IP_, vma, address);
-   goto unlock;
-   }
-
-   if (unlikely(!vma->anon_vma)) {
+   if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) {
trace_spf_vma_notsup(_RET_IP_, vma, address);
goto unlock;
}

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Anshuman Khandual]

On 08/29/2017 07:15 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 03:18:25PM +0200, Laurent Dufour wrote:
>> On 29/08/2017 14:04, Peter Zijlstra wrote:
>>> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
 On 27/08/2017 02:18, Kirill A. Shutemov wrote:
>> +
>> +if (unlikely(!vma->anon_vma))
>> +goto unlock;
>
> It deserves a comment.

 You're right I'll add it in the next version.
 For the record, the root cause is that __anon_vma_prepare() requires the
 mmap_sem to be held because vm_next and vm_prev must be safe.
>>>
>>> But should that test not be:
>>>
>>> if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
>>> goto unlock;
>>>
>>> Because !anon vmas will never have ->anon_vma set and you don't want to
>>> exclude those.
>>
>> Yes in the case we later allow non anonymous vmas to be handled.
>> Currently only anonymous vmas are supported so the check is good enough,
>> isn't it ?
> 
> That wasn't at all clear from reading the code. This makes it clear
> ->anon_vma is only ever looked at for anonymous.
> 
> And like Kirill says, we _really_ should start allowing some (if not
> all) vm_ops. Large file based mappings aren't particularly rare.
> 
> I'm not sure we want to introduce a white-list or just bite the bullet
> and audit all ->fault() implementations. But either works and isn't
> terribly difficult, auditing all is more work though.

filemap_fault() is used as vma-vm_ops->fault() for most of the file
systems. Changing it can enable speculative fault support for all of
them. It will still exclude other driver based vma-vm_ops->fault()
implementation. AFAICS, __lock_page_or_retry() function can drop
mm->mmap_sem if the page could not be locked right away. As suggested
by Peterz, making it understand FAULT_FLAG_SPECULATIVE should be good
enough. The patch is lightly tested for file mappings on top of this
series.

diff --git a/mm/filemap.c b/mm/filemap.c
index a497024..08f3042 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
 int __lock_page_or_retry(struct page *page, struct mm_struct *mm,
 unsigned int flags)
 {
+   if (flags & FAULT_FLAG_SPECULATIVE) {
+   if (flags & FAULT_FLAG_KILLABLE) {
+   int ret;
+
+   ret = __lock_page_killable(page);
+   if (ret)
+   return 0;
+   } else
+   __lock_page(page);
+   return 1;
+   }
+
if (flags & FAULT_FLAG_ALLOW_RETRY) {
/*
 * CAUTION! In this case, mmap_sem is not released
diff --git a/mm/memory.c b/mm/memory.c
index 549d235..02347f3 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -3836,8 +3836,6 @@ static int handle_pte_fault(struct vm_fault *vmf)
if (!vmf->pte) {
if (vma_is_anonymous(vmf->vma))
return do_anonymous_page(vmf);
-   else if (vmf->flags & FAULT_FLAG_SPECULATIVE)
-   return VM_FAULT_RETRY;
else
return do_fault(vmf);
}
@@ -4012,17 +4010,7 @@ int handle_speculative_fault(struct mm_struct *mm, 
unsigned long address,
goto unlock;
}

-   /*
-* Can't call vm_ops service has we don't know what they would do
-* with the VMA.
-* This include huge page from hugetlbfs.
-*/
-   if (vma->vm_ops) {
-   trace_spf_vma_notsup(_RET_IP_, vma, address);
-   goto unlock;
-   }
-
-   if (unlikely(!vma->anon_vma)) {
+   if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma)) {
trace_spf_vma_notsup(_RET_IP_, vma, address);
goto unlock;
}

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

[Mike Galbraith]

On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> disabled)?

Nogo.

...
[  OK  ] Mounted /abuild.
[  OK  ] Mounted /homer.
[  OK  ] Mounted /home/git.
[  OK  ] Mounted /usr/local/src.
[  OK  ] Mounted /usr/local/gcc.
[  OK  ] Mounted /usr/local/lib/albumcovers.
[  OK  ] Mounted /usr/local/lib/mp3.
[  OK  ] Mounted /usr/local/ltp.
[  OK  ] Started SuSEfirewall2 phase 2.
 Starting Locale Service...
[   44.901304] [ cut here ]
[   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 
netlink_sock_destruct+0x82/0xa0
[   44.902679] Modules linked in: nf_log_ipv6(E) xt_comment(E) nf_log_ipv4(E) 
rpcsec_gss_krb5(E) nfsv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) 
dns_resolver(E) nfs(E) fscache(E) af_packet(E) iscsi_ibft(E) 
iscsi_boot_sysfs(E) ip6t_REJECT(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) 
ipt_REJECT(E) xt_pkttype(E) xt_tcpudp(E) iptable_filter(E) ip6table_mangle(E) 
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) libcrc32c(E) 
ip6table_filter(E) ip6_tables(E) x_tables(E) snd_hda_codec_generic(E) 
snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) 
snd_timer(E) joydev(E) snd(E) ppdev(E) soundcore(E) parport_pc(E) 
crct10dif_pclmul(E) 8139too(E) crc32_pclmul(E) ghash_clmulni_intel(E) 8139cp(E) 
pcbc(E) aesni_intel(E)
[   44.908297]  i2c_piix4(E) mii(E) parport(E) aes_x86_64(E) crypto_simd(E) 
glue_helper(E) pcspkr(E) cryptd(E) button(E) qemu_fw_cfg(E) nfsd(E) 
auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) ata_generic(E) hid_generic(E) usbhid(E) ata_piix(E) 
virtio_balloon(E) virtio_rng(E) virtio_blk(E) virtio_console(E) qxl(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) ahci(E) 
fb_sys_fops(E) ttm(E) libahci(E) uhci_hcd(E) ehci_pci(E) crc32c_intel(E) 
ehci_hcd(E) libata(E) serio_raw(E) virtio_pci(E) virtio_ring(E) drm(E) 
usbcore(E) virtio(E) floppy(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) 
scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[   44.913190] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW   E   
4.13.0.g94a2d62-tip-default #45
[   44.915217] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.0.0-prebuilt.qemu-project.org 04/01/2014
[   44.916073] task: 88018ee78400 task.stack: c9cc8000
[   44.916742] RIP: 0010:netlink_sock_destruct+0x82/0xa0
[   44.917291] RSP: 0018:880246143eb0 EFLAGS: 00010206
[   44.917818] RAX: 0300 RBX: 8802370a6800 RCX: 77ff8000
[   44.918497] RDX: 0001 RSI: 0246 RDI: 0246
[   44.919093] RBP: 8802370a6800 R08: 0001 R09: 00011000
[   44.919826] R10: 1104 R11: 00011bf8 R12: 0202
[   44.920486] R13: 81cf1440 R14: 88018ee78400 R15: 815e0f30
[   44.921138] FS:  () GS:88024614() 
knlGS:
[   44.921861] CS:  0010 DS:  ES:  CR0: 80050033
[   44.922419] CR2: 563972a82768 CR3: 00011d25a005 CR4: 001606e0
[   44.923079] Call Trace:
[   44.923503]  
[   44.923786]  __sk_destruct+0x21/0x190
[   44.924160]  rcu_process_callbacks+0x23e/0x880
[   44.924583]  ? rebalance_domains+0xf4/0x2b0
[   44.925147]  __do_softirq+0xc8/0x287
[   44.925620]  irq_exit+0xd5/0xe0
[   44.926072]  smp_apic_timer_interrupt+0x64/0x140
[   44.926602]  apic_timer_interrupt+0x96/0xa0
[   44.927138]  
[   44.927512] RIP: 0010:native_safe_halt+0x2/0x10
[   44.928104] RSP: 0018:c9ccbed8 EFLAGS: 0246 ORIG_RAX: 
ff10
[   44.928897] RAX: 816d46e0 RBX: 88018ee78400 RCX: 
[   44.931217] RDX:  RSI:  RDI: 
[   44.932064] RBP: 0005 R08: 8e8d32c4 R09: 
[   44.932757] R10: 0006 R11: 0005 R12: 88018ee78400
[   44.933423] R13:  R14:  R15: 
[   44.934187]  ? __sched_text_end+0x5/0x5
[   44.934609]  default_idle+0x18/0x110
[   44.935041]  do_idle+0x15e/0x1f0
[   44.935455]  cpu_startup_entry+0x5f/0x70
[   44.935934]  start_secondary+0x14c/0x180
[   44.936445]  secondary_startup_64+0xa5/0xa5
[   44.936933] Code: 00 00 85 c0 75 25 8b 83 44 01 00 00 85 c0 75 10 48 83 bb 
e0 02 00 00 00 75 02 5b c3 0f ff 5b c3 0f ff 0f 1f 80 00 00 00 00 eb e5 <0f> ff 
eb d7 48 89 de 48 c7 c7 d8 e6 ab 81 31 c0 5b e9 d5 ca af 
[   44.938829] ---[ end trace bcf2d20b852804b6 ]---
[  OK  ] Started Locale Service.
[  OK  ] Started Postfix Mail Transport Agent.
[  OK  ] Started Command Scheduler.

Re: [PATCH v2] membarrier: provide register sync core cmd

[Andy Lutomirski]

> On Aug 27, 2017, at 8:05 PM, Mathieu Desnoyers 
>  wrote:
>
> - On Aug 27, 2017, at 3:53 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>>> On Aug 27, 2017, at 1:50 PM, Mathieu Desnoyers 
>>> 
>>> wrote:
>>>
>>> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
>>> system call. It allows processes to register their intent to have their
>>> threads issue core serializing barriers in addition to memory barriers
>>> whenever a membarrier command is performed.
>>>
>>
>> Why is this stateful?  That is, why not just have a new membarrier command to
>> sync every thread's icache?
>
> If we'd do it on every CPU icache, it would be as trivial as you say. The
> concern here is sending IPIs only to CPUs running threads that belong to the
> same process, so we don't disturb unrelated processes.
>
> If we could just grab each CPU's runqueue lock, it would be fairly simple
> to do. But we want to avoid hitting each runqueue with exclusive atomic
> access associated with grabbing the lock. (cache-line bouncing)

Hmm.  Are there really arches where there is no clean implementation
without this hacker?  It seems rather unfortunate that munmap() can be
done efficiently but this barrier can't be.

At the very least, could there be a register command *and* a special
sync command?  I dislike the idea that the sync command does something
different depending on some other state.  Even better (IMO) would be a
design where you ask for an isync and, if the arch can do it
efficiently (x86), you get an efficient isync and, if the arch can't
(arm64?) you take all the rq locks?

--Andy

Re: tip -ENOBOOT - bisected to locking/refcounts, x86/asm: Implement fast refcount overflow protection

[Mike Galbraith]

On Tue, 2017-08-29 at 11:41 -0700, Kees Cook wrote:
> Can you also test with 14afee4b6092 ("net: convert sock.sk_wmem_alloc
> from atomic_t to refcount_t") reverted (instead of ARCH_HAS_REFCOUNT
> disabled)?

Nogo.

...
[  OK  ] Mounted /abuild.
[  OK  ] Mounted /homer.
[  OK  ] Mounted /home/git.
[  OK  ] Mounted /usr/local/src.
[  OK  ] Mounted /usr/local/gcc.
[  OK  ] Mounted /usr/local/lib/albumcovers.
[  OK  ] Mounted /usr/local/lib/mp3.
[  OK  ] Mounted /usr/local/ltp.
[  OK  ] Started SuSEfirewall2 phase 2.
 Starting Locale Service...
[   44.901304] [ cut here ]
[   44.901930] WARNING: CPU: 5 PID: 0 at net/netlink/af_netlink.c:374 
netlink_sock_destruct+0x82/0xa0
[   44.902679] Modules linked in: nf_log_ipv6(E) xt_comment(E) nf_log_ipv4(E) 
rpcsec_gss_krb5(E) nfsv4(E) nf_log_common(E) xt_LOG(E) xt_limit(E) 
dns_resolver(E) nfs(E) fscache(E) af_packet(E) iscsi_ibft(E) 
iscsi_boot_sysfs(E) ip6t_REJECT(E) nf_conntrack_ipv6(E) nf_defrag_ipv6(E) 
ipt_REJECT(E) xt_pkttype(E) xt_tcpudp(E) iptable_filter(E) ip6table_mangle(E) 
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) nf_conntrack_ipv4(E) 
nf_defrag_ipv4(E) ip_tables(E) xt_conntrack(E) nf_conntrack(E) libcrc32c(E) 
ip6table_filter(E) ip6_tables(E) x_tables(E) snd_hda_codec_generic(E) 
snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) 
snd_timer(E) joydev(E) snd(E) ppdev(E) soundcore(E) parport_pc(E) 
crct10dif_pclmul(E) 8139too(E) crc32_pclmul(E) ghash_clmulni_intel(E) 8139cp(E) 
pcbc(E) aesni_intel(E)
[   44.908297]  i2c_piix4(E) mii(E) parport(E) aes_x86_64(E) crypto_simd(E) 
glue_helper(E) pcspkr(E) cryptd(E) button(E) qemu_fw_cfg(E) nfsd(E) 
auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) ext4(E) crc16(E) 
mbcache(E) jbd2(E) ata_generic(E) hid_generic(E) usbhid(E) ata_piix(E) 
virtio_balloon(E) virtio_rng(E) virtio_blk(E) virtio_console(E) qxl(E) 
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) ahci(E) 
fb_sys_fops(E) ttm(E) libahci(E) uhci_hcd(E) ehci_pci(E) crc32c_intel(E) 
ehci_hcd(E) libata(E) serio_raw(E) virtio_pci(E) virtio_ring(E) drm(E) 
usbcore(E) virtio(E) floppy(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) 
scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[   44.913190] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW   E   
4.13.0.g94a2d62-tip-default #45
[   44.915217] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.0.0-prebuilt.qemu-project.org 04/01/2014
[   44.916073] task: 88018ee78400 task.stack: c9cc8000
[   44.916742] RIP: 0010:netlink_sock_destruct+0x82/0xa0
[   44.917291] RSP: 0018:880246143eb0 EFLAGS: 00010206
[   44.917818] RAX: 0300 RBX: 8802370a6800 RCX: 77ff8000
[   44.918497] RDX: 0001 RSI: 0246 RDI: 0246
[   44.919093] RBP: 8802370a6800 R08: 0001 R09: 00011000
[   44.919826] R10: 1104 R11: 00011bf8 R12: 0202
[   44.920486] R13: 81cf1440 R14: 88018ee78400 R15: 815e0f30
[   44.921138] FS:  () GS:88024614() 
knlGS:
[   44.921861] CS:  0010 DS:  ES:  CR0: 80050033
[   44.922419] CR2: 563972a82768 CR3: 00011d25a005 CR4: 001606e0
[   44.923079] Call Trace:
[   44.923503]  
[   44.923786]  __sk_destruct+0x21/0x190
[   44.924160]  rcu_process_callbacks+0x23e/0x880
[   44.924583]  ? rebalance_domains+0xf4/0x2b0
[   44.925147]  __do_softirq+0xc8/0x287
[   44.925620]  irq_exit+0xd5/0xe0
[   44.926072]  smp_apic_timer_interrupt+0x64/0x140
[   44.926602]  apic_timer_interrupt+0x96/0xa0
[   44.927138]  
[   44.927512] RIP: 0010:native_safe_halt+0x2/0x10
[   44.928104] RSP: 0018:c9ccbed8 EFLAGS: 0246 ORIG_RAX: 
ff10
[   44.928897] RAX: 816d46e0 RBX: 88018ee78400 RCX: 
[   44.931217] RDX:  RSI:  RDI: 
[   44.932064] RBP: 0005 R08: 8e8d32c4 R09: 
[   44.932757] R10: 0006 R11: 0005 R12: 88018ee78400
[   44.933423] R13:  R14:  R15: 
[   44.934187]  ? __sched_text_end+0x5/0x5
[   44.934609]  default_idle+0x18/0x110
[   44.935041]  do_idle+0x15e/0x1f0
[   44.935455]  cpu_startup_entry+0x5f/0x70
[   44.935934]  start_secondary+0x14c/0x180
[   44.936445]  secondary_startup_64+0xa5/0xa5
[   44.936933] Code: 00 00 85 c0 75 25 8b 83 44 01 00 00 85 c0 75 10 48 83 bb 
e0 02 00 00 00 75 02 5b c3 0f ff 5b c3 0f ff 0f 1f 80 00 00 00 00 eb e5 <0f> ff 
eb d7 48 89 de 48 c7 c7 d8 e6 ab 81 31 c0 5b e9 d5 ca af 
[   44.938829] ---[ end trace bcf2d20b852804b6 ]---
[  OK  ] Started Locale Service.
[  OK  ] Started Postfix Mail Transport Agent.
[  OK  ] Started Command Scheduler.

Re: [PATCH v2] membarrier: provide register sync core cmd

[Andy Lutomirski]

> On Aug 27, 2017, at 8:05 PM, Mathieu Desnoyers 
>  wrote:
>
> - On Aug 27, 2017, at 3:53 PM, Andy Lutomirski l...@amacapital.net wrote:
>
>>> On Aug 27, 2017, at 1:50 PM, Mathieu Desnoyers 
>>> 
>>> wrote:
>>>
>>> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
>>> system call. It allows processes to register their intent to have their
>>> threads issue core serializing barriers in addition to memory barriers
>>> whenever a membarrier command is performed.
>>>
>>
>> Why is this stateful?  That is, why not just have a new membarrier command to
>> sync every thread's icache?
>
> If we'd do it on every CPU icache, it would be as trivial as you say. The
> concern here is sending IPIs only to CPUs running threads that belong to the
> same process, so we don't disturb unrelated processes.
>
> If we could just grab each CPU's runqueue lock, it would be fairly simple
> to do. But we want to avoid hitting each runqueue with exclusive atomic
> access associated with grabbing the lock. (cache-line bouncing)

Hmm.  Are there really arches where there is no clean implementation
without this hacker?  It seems rather unfortunate that munmap() can be
done efficiently but this barrier can't be.

At the very least, could there be a register command *and* a special
sync command?  I dislike the idea that the sync command does something
different depending on some other state.  Even better (IMO) would be a
design where you ask for an isync and, if the arch can do it
efficiently (x86), you get an efficient isync and, if the arch can't
(arm64?) you take all the rq locks?

--Andy

Re: [PATCH net-next v3 0/3] NCSI VLAN Filtering Support

[Samuel Mendoza-Jonas]

On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
> From: Samuel Mendoza-Jonas 
> Date: Mon, 28 Aug 2017 16:18:40 +1000
> 
> > This series (mainly patch 2) adds VLAN filtering to the NCSI implementation.
> > A fair amount of code already exists in the NCSI stack for VLAN filtering 
> > but
> > none of it is actually hooked up. This goes the final mile and fixes a few
> > bugs in the existing code found along the way (patch 1).
> > 
> > Patch 3 adds the appropriate flag and callbacks to the ftgmac100 driver to
> > enable filtering as it's a large consumer of NCSI (and what I've been
> > testing on).
> > 
> > v3:   - Add comment describing change to ncsi_find_filter()
> >   - Catch NULL in clear_one_vid() from ncsi_get_filter()
> >   - Simplify state changes when kicking updated channel
> 
> Series applied.

Thanks David,

The kbuild bot caught a build error where the add/kill callbacks aren't
defined without CONFIG_NET_NCSI:

>> ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>> undefined!
>> ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>> undefined!

It's a quick fixup to patch 3 as below, would you like me to send it as a v4?


diff --git a/include/net/ncsi.h b/include/net/ncsi.h
index 1f96af46df49..2b13b6b91a4d 100644
--- a/include/net/ncsi.h
+++ b/include/net/ncsi.h
@@ -36,6 +36,14 @@ int ncsi_start_dev(struct ncsi_dev *nd);
 void ncsi_stop_dev(struct ncsi_dev *nd);
 void ncsi_unregister_dev(struct ncsi_dev *nd);
 #else /* !CONFIG_NET_NCSI */
+int ncsi_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid)
+{
+   return -ENOTTY;
+}
+int ncsi_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, u16 vid)
+{
+   return -ENOTTY;
+}
 static inline struct ncsi_dev *ncsi_register_dev(struct net_device *dev,
void (*notifier)(struct ncsi_dev *nd))
 {

Re: [PATCH net-next v3 0/3] NCSI VLAN Filtering Support

[Samuel Mendoza-Jonas]

On Mon, 2017-08-28 at 16:50 -0700, David Miller wrote:
> From: Samuel Mendoza-Jonas 
> Date: Mon, 28 Aug 2017 16:18:40 +1000
> 
> > This series (mainly patch 2) adds VLAN filtering to the NCSI implementation.
> > A fair amount of code already exists in the NCSI stack for VLAN filtering 
> > but
> > none of it is actually hooked up. This goes the final mile and fixes a few
> > bugs in the existing code found along the way (patch 1).
> > 
> > Patch 3 adds the appropriate flag and callbacks to the ftgmac100 driver to
> > enable filtering as it's a large consumer of NCSI (and what I've been
> > testing on).
> > 
> > v3:   - Add comment describing change to ncsi_find_filter()
> >   - Catch NULL in clear_one_vid() from ncsi_get_filter()
> >   - Simplify state changes when kicking updated channel
> 
> Series applied.

Thanks David,

The kbuild bot caught a build error where the add/kill callbacks aren't
defined without CONFIG_NET_NCSI:

>> ERROR: "ncsi_vlan_rx_kill_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>> undefined!
>> ERROR: "ncsi_vlan_rx_add_vid" [drivers/net/ethernet/faraday/ftgmac100.ko] 
>> undefined!

It's a quick fixup to patch 3 as below, would you like me to send it as a v4?


diff --git a/include/net/ncsi.h b/include/net/ncsi.h
index 1f96af46df49..2b13b6b91a4d 100644
--- a/include/net/ncsi.h
+++ b/include/net/ncsi.h
@@ -36,6 +36,14 @@ int ncsi_start_dev(struct ncsi_dev *nd);
 void ncsi_stop_dev(struct ncsi_dev *nd);
 void ncsi_unregister_dev(struct ncsi_dev *nd);
 #else /* !CONFIG_NET_NCSI */
+int ncsi_vlan_rx_add_vid(struct net_device *dev, __be16 proto, u16 vid)
+{
+   return -ENOTTY;
+}
+int ncsi_vlan_rx_kill_vid(struct net_device *dev, __be16 proto, u16 vid)
+{
+   return -ENOTTY;
+}
 static inline struct ncsi_dev *ncsi_register_dev(struct net_device *dev,
void (*notifier)(struct ncsi_dev *nd))
 {

[PATCH v2] tracing: Ignore mmiotrace from kernel commandline

[Ziqian SUN (Zamir)]

From: "Ziqian SUN (Zamir)" 

The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and continue booting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196557
Signed-off-by: Ziqian SUN (Zamir) 
---
 kernel/trace/trace.c   | 34 +-
 kernel/trace/trace.h   | 11 +++
 kernel/trace/trace_mmiotrace.c |  4 
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 44004d8..0d25b1e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -319,6 +319,33 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
kfree(pid_list);
 }
 
+struct mutex trace_noboot_tracer_lock;
+
+DEFINE_MUTEX(trace_noboot_tracer_lock);
+LIST_HEAD(trace_noboot_tracer_list);
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer)
+{
+   mutex_lock(_noboot_tracer_lock);
+   list_add(_tracer->list, _noboot_tracer_list);
+   mutex_unlock(_noboot_tracer_lock);
+}
+
+bool trace_noboot_tracer_find(const char *str)
+{
+   mutex_lock(_noboot_tracer_lock);
+   struct tracer_noboot *ptr = NULL;
+
+   list_for_each_entry(ptr, _noboot_tracer_list, list) {
+   if (strcmp(ptr->name, str) == 0) {
+   mutex_unlock(_noboot_tracer_lock);
+   return true;
+   }
+   }
+   mutex_unlock(_noboot_tracer_lock);
+   return false;
+}
+
 /**
  * trace_find_filtered_pid - check if a pid exists in a filtered_pid list
  * @filtered_pids: The list of pids to check
@@ -1641,8 +1668,13 @@ int __init register_tracer(struct tracer *type)
if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
goto out_unlock;
 
+   /* If the tracer should not be enabled by kernel parameter */
+   if (trace_noboot_tracer_find(type->name)) {
+   pr_warn("Tracer '%s' cannot be enabled during boot\n", 
type->name);
+   goto out_unlock;
+   }
+
printk(KERN_INFO "Starting tracer '%s'\n", type->name);
-   /* Do we want this tracer to start on bootup? */
tracing_set_tracer(_trace, type->name);
default_bootup_tracer = NULL;
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 490ba22..23bc668 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -502,6 +502,17 @@ enum {
TRACE_IRQ_BIT,
 };
 
+/*
+ * For tracer that cannot be enabled during boot time.
+ */
+
+struct tracer_noboot {
+   const char  *name;
+   struct list_headlist;
+};
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer);
+
 #define trace_recursion_set(bit)   do { (current)->trace_recursion |= 
(1<<(bit)); } while (0)
 #define trace_recursion_clear(bit) do { (current)->trace_recursion &= 
~(1<<(bit)); } while (0)
 #define trace_recursion_test(bit)  ((current)->trace_recursion & 
(1<<(bit)))
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index cd7480d..06aa0a5 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -286,6 +286,10 @@ static enum print_line_t mmio_print_line(struct 
trace_iterator *iter)
 
 __init static int init_mmio_trace(void)
 {
+   struct tracer_noboot mmio_notrace;
+
+   mmio_notrace.name = "mmiotrace";
+   trace_noboot_tracer_put(_notrace);
return register_tracer(_tracer);
 }
 device_initcall(init_mmio_trace);
-- 
1.8.3.1

[PATCH v2] tracing: Ignore mmiotrace from kernel commandline

[Ziqian SUN (Zamir)]

From: "Ziqian SUN (Zamir)" 

The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and continue booting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196557
Signed-off-by: Ziqian SUN (Zamir) 
---
 kernel/trace/trace.c   | 34 +-
 kernel/trace/trace.h   | 11 +++
 kernel/trace/trace_mmiotrace.c |  4 
 3 files changed, 48 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 44004d8..0d25b1e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -319,6 +319,33 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
kfree(pid_list);
 }
 
+struct mutex trace_noboot_tracer_lock;
+
+DEFINE_MUTEX(trace_noboot_tracer_lock);
+LIST_HEAD(trace_noboot_tracer_list);
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer)
+{
+   mutex_lock(_noboot_tracer_lock);
+   list_add(_tracer->list, _noboot_tracer_list);
+   mutex_unlock(_noboot_tracer_lock);
+}
+
+bool trace_noboot_tracer_find(const char *str)
+{
+   mutex_lock(_noboot_tracer_lock);
+   struct tracer_noboot *ptr = NULL;
+
+   list_for_each_entry(ptr, _noboot_tracer_list, list) {
+   if (strcmp(ptr->name, str) == 0) {
+   mutex_unlock(_noboot_tracer_lock);
+   return true;
+   }
+   }
+   mutex_unlock(_noboot_tracer_lock);
+   return false;
+}
+
 /**
  * trace_find_filtered_pid - check if a pid exists in a filtered_pid list
  * @filtered_pids: The list of pids to check
@@ -1641,8 +1668,13 @@ int __init register_tracer(struct tracer *type)
if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
goto out_unlock;
 
+   /* If the tracer should not be enabled by kernel parameter */
+   if (trace_noboot_tracer_find(type->name)) {
+   pr_warn("Tracer '%s' cannot be enabled during boot\n", 
type->name);
+   goto out_unlock;
+   }
+
printk(KERN_INFO "Starting tracer '%s'\n", type->name);
-   /* Do we want this tracer to start on bootup? */
tracing_set_tracer(_trace, type->name);
default_bootup_tracer = NULL;
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 490ba22..23bc668 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -502,6 +502,17 @@ enum {
TRACE_IRQ_BIT,
 };
 
+/*
+ * For tracer that cannot be enabled during boot time.
+ */
+
+struct tracer_noboot {
+   const char  *name;
+   struct list_headlist;
+};
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer);
+
 #define trace_recursion_set(bit)   do { (current)->trace_recursion |= 
(1<<(bit)); } while (0)
 #define trace_recursion_clear(bit) do { (current)->trace_recursion &= 
~(1<<(bit)); } while (0)
 #define trace_recursion_test(bit)  ((current)->trace_recursion & 
(1<<(bit)))
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index cd7480d..06aa0a5 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -286,6 +286,10 @@ static enum print_line_t mmio_print_line(struct 
trace_iterator *iter)
 
 __init static int init_mmio_trace(void)
 {
+   struct tracer_noboot mmio_notrace;
+
+   mmio_notrace.name = "mmiotrace";
+   trace_noboot_tracer_put(_notrace);
return register_tracer(_tracer);
 }
 device_initcall(init_mmio_trace);
-- 
1.8.3.1

Re: [PATCH] tracing: Ignore mmiotrace from kernel commandline

[Ziqian SUN (Zamir)]

On 08/30/2017 11:25 AM, Ziqian SUN (Zamir) wrote:

From: "Ziqian SUN (Zamir)" 

The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and continue booting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196557
Signed-off-by: Ziqian SUN (Zamir) 
---
  kernel/trace/trace.c   | 35 ++-
  kernel/trace/trace.h   | 11 +++
  kernel/trace/trace_mmiotrace.c |  4 
  3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 44004d8..aba774d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -319,6 +319,34 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
kfree(pid_list);
  }
  
+/*struct list_head trace_noboot_tracer_list;*/
Just realized this commented line is no longer needed. I will send out 
v2 to remove it.

+struct mutex trace_noboot_tracer_lock;
+
+DEFINE_MUTEX(trace_noboot_tracer_lock);
+LIST_HEAD(trace_noboot_tracer_list);
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer)
+{
+   mutex_lock(_noboot_tracer_lock);
+   list_add(_tracer->list, _noboot_tracer_list);
+   mutex_unlock(_noboot_tracer_lock);
+}
+
+bool trace_noboot_tracer_find(const char *str)
+{
+   mutex_lock(_noboot_tracer_lock);
+   struct tracer_noboot *ptr = NULL;
+
+   list_for_each_entry(ptr, _noboot_tracer_list, list) {
+   if (strcmp(ptr->name, str) == 0) {
+   mutex_unlock(_noboot_tracer_lock);
+   return true;
+   }
+   }
+   mutex_unlock(_noboot_tracer_lock);
+   return false;
+}
+
  /**
   * trace_find_filtered_pid - check if a pid exists in a filtered_pid list
   * @filtered_pids: The list of pids to check
@@ -1641,8 +1669,13 @@ int __init register_tracer(struct tracer *type)
if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
goto out_unlock;
  
+	/* If the tracer should not be enabled by kernel parameter */

+   if (trace_noboot_tracer_find(type->name)) {
+   pr_warn("Tracer '%s' cannot be enabled during boot\n", 
type->name);
+   goto out_unlock;
+   }
+
printk(KERN_INFO "Starting tracer '%s'\n", type->name);
-   /* Do we want this tracer to start on bootup? */
tracing_set_tracer(_trace, type->name);
default_bootup_tracer = NULL;
  
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h

index 490ba22..23bc668 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -502,6 +502,17 @@ enum {
TRACE_IRQ_BIT,
  };
  
+/*

+ * For tracer that cannot be enabled during boot time.
+ */
+
+struct tracer_noboot {
+   const char  *name;
+   struct list_headlist;
+};
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer);
+
  #define trace_recursion_set(bit)  do { (current)->trace_recursion |= 
(1<<(bit)); } while (0)
  #define trace_recursion_clear(bit)do { (current)->trace_recursion &= 
~(1<<(bit)); } while (0)
  #define trace_recursion_test(bit) ((current)->trace_recursion & 
(1<<(bit)))
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index cd7480d..06aa0a5 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -286,6 +286,10 @@ static enum print_line_t mmio_print_line(struct 
trace_iterator *iter)
  
  __init static int init_mmio_trace(void)

  {
+   struct tracer_noboot mmio_notrace;
+
+   mmio_notrace.name = "mmiotrace";
+   trace_noboot_tracer_put(_notrace);
return register_tracer(_tracer);
  }
  device_initcall(init_mmio_trace);



--
Ziqian SUN (Zamir)
Red Hat Software (Beijing) Co.,Ltd

Re: [PATCH] tracing: Ignore mmiotrace from kernel commandline

[Ziqian SUN (Zamir)]

On 08/30/2017 11:25 AM, Ziqian SUN (Zamir) wrote:

From: "Ziqian SUN (Zamir)" 

The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and continue booting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196557
Signed-off-by: Ziqian SUN (Zamir) 
---
  kernel/trace/trace.c   | 35 ++-
  kernel/trace/trace.h   | 11 +++
  kernel/trace/trace_mmiotrace.c |  4 
  3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 44004d8..aba774d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -319,6 +319,34 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
kfree(pid_list);
  }
  
+/*struct list_head trace_noboot_tracer_list;*/
Just realized this commented line is no longer needed. I will send out 
v2 to remove it.

+struct mutex trace_noboot_tracer_lock;
+
+DEFINE_MUTEX(trace_noboot_tracer_lock);
+LIST_HEAD(trace_noboot_tracer_list);
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer)
+{
+   mutex_lock(_noboot_tracer_lock);
+   list_add(_tracer->list, _noboot_tracer_list);
+   mutex_unlock(_noboot_tracer_lock);
+}
+
+bool trace_noboot_tracer_find(const char *str)
+{
+   mutex_lock(_noboot_tracer_lock);
+   struct tracer_noboot *ptr = NULL;
+
+   list_for_each_entry(ptr, _noboot_tracer_list, list) {
+   if (strcmp(ptr->name, str) == 0) {
+   mutex_unlock(_noboot_tracer_lock);
+   return true;
+   }
+   }
+   mutex_unlock(_noboot_tracer_lock);
+   return false;
+}
+
  /**
   * trace_find_filtered_pid - check if a pid exists in a filtered_pid list
   * @filtered_pids: The list of pids to check
@@ -1641,8 +1669,13 @@ int __init register_tracer(struct tracer *type)
if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
goto out_unlock;
  
+	/* If the tracer should not be enabled by kernel parameter */

+   if (trace_noboot_tracer_find(type->name)) {
+   pr_warn("Tracer '%s' cannot be enabled during boot\n", 
type->name);
+   goto out_unlock;
+   }
+
printk(KERN_INFO "Starting tracer '%s'\n", type->name);
-   /* Do we want this tracer to start on bootup? */
tracing_set_tracer(_trace, type->name);
default_bootup_tracer = NULL;
  
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h

index 490ba22..23bc668 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -502,6 +502,17 @@ enum {
TRACE_IRQ_BIT,
  };
  
+/*

+ * For tracer that cannot be enabled during boot time.
+ */
+
+struct tracer_noboot {
+   const char  *name;
+   struct list_headlist;
+};
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer);
+
  #define trace_recursion_set(bit)  do { (current)->trace_recursion |= 
(1<<(bit)); } while (0)
  #define trace_recursion_clear(bit)do { (current)->trace_recursion &= 
~(1<<(bit)); } while (0)
  #define trace_recursion_test(bit) ((current)->trace_recursion & 
(1<<(bit)))
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index cd7480d..06aa0a5 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -286,6 +286,10 @@ static enum print_line_t mmio_print_line(struct 
trace_iterator *iter)
  
  __init static int init_mmio_trace(void)

  {
+   struct tracer_noboot mmio_notrace;
+
+   mmio_notrace.name = "mmiotrace";
+   trace_noboot_tracer_put(_notrace);
return register_tracer(_tracer);
  }
  device_initcall(init_mmio_trace);



--
Ziqian SUN (Zamir)
Red Hat Software (Beijing) Co.,Ltd

[PATCH v3 3/3] eeprom: at24: enable runtime pm support

[Divagar Mohandass]

Currently the device is kept in D0, there is an opportunity
to save power by enabling runtime pm.

Device can be daisy chained from PMIC and we can't rely on I2C core
for auto resume/suspend. Driver will decide when to resume/suspend.

Signed-off-by: Divagar Mohandass 
---
 drivers/misc/eeprom/at24.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2199c42..a670814 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
@@ -501,11 +502,22 @@ static ssize_t at24_eeprom_write_i2c(struct at24_data 
*at24, const char *buf,
 static int at24_read(void *priv, unsigned int off, void *val, size_t count)
 {
struct at24_data *at24 = priv;
+   struct i2c_client *client;
char *buf = val;
+   int ret;
 
if (unlikely(!count))
return count;
 
+   client = at24_translate_offset(at24, );
+
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_put(>dev);
+   return ret;
+   }
+
/*
 * Read data from chip, protecting against concurrent updates
 * from this host, but not from other I2C masters.
@@ -527,17 +539,30 @@ static int at24_read(void *priv, unsigned int off, void 
*val, size_t count)
 
mutex_unlock(>lock);
 
+   pm_runtime_put(>dev);
+
return 0;
 }
 
 static int at24_write(void *priv, unsigned int off, void *val, size_t count)
 {
struct at24_data *at24 = priv;
+   struct i2c_client *client;
char *buf = val;
+   int ret;
 
if (unlikely(!count))
return -EINVAL;
 
+   client = at24_translate_offset(at24, );
+
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_put(>dev);
+   return ret;
+   }
+
/*
 * Write data to chip, protecting against concurrent updates
 * from this host, but not from other I2C masters.
@@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned int off, void 
*val, size_t count)
 
mutex_unlock(>lock);
 
+   pm_runtime_put(>dev);
+
return 0;
 }
 
@@ -743,6 +770,15 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
i2c_set_clientdata(client, at24);
 
+   /* enable runtime pm */
+   pm_runtime_get_noresume(>dev);
+   err = pm_runtime_set_active(>dev);
+   if (err < 0)
+   goto err_clients;
+
+   pm_runtime_enable(>dev);
+   pm_runtime_put(>dev);
+
/*
 * Perform a one-byte test read to verify that the
 * chip is functional.
@@ -810,6 +846,9 @@ static int at24_remove(struct i2c_client *client)
for (i = 1; i < at24->num_addresses; i++)
i2c_unregister_device(at24->client[i]);
 
+   pm_runtime_disable(>dev);
+   pm_runtime_set_suspended(>dev);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v3 3/3] eeprom: at24: enable runtime pm support

[Divagar Mohandass]

Currently the device is kept in D0, there is an opportunity
to save power by enabling runtime pm.

Device can be daisy chained from PMIC and we can't rely on I2C core
for auto resume/suspend. Driver will decide when to resume/suspend.

Signed-off-by: Divagar Mohandass 
---
 drivers/misc/eeprom/at24.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2199c42..a670814 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * I2C EEPROMs from most vendors are inexpensive and mostly interchangeable.
@@ -501,11 +502,22 @@ static ssize_t at24_eeprom_write_i2c(struct at24_data 
*at24, const char *buf,
 static int at24_read(void *priv, unsigned int off, void *val, size_t count)
 {
struct at24_data *at24 = priv;
+   struct i2c_client *client;
char *buf = val;
+   int ret;
 
if (unlikely(!count))
return count;
 
+   client = at24_translate_offset(at24, );
+
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_put(>dev);
+   return ret;
+   }
+
/*
 * Read data from chip, protecting against concurrent updates
 * from this host, but not from other I2C masters.
@@ -527,17 +539,30 @@ static int at24_read(void *priv, unsigned int off, void 
*val, size_t count)
 
mutex_unlock(>lock);
 
+   pm_runtime_put(>dev);
+
return 0;
 }
 
 static int at24_write(void *priv, unsigned int off, void *val, size_t count)
 {
struct at24_data *at24 = priv;
+   struct i2c_client *client;
char *buf = val;
+   int ret;
 
if (unlikely(!count))
return -EINVAL;
 
+   client = at24_translate_offset(at24, );
+
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_put(>dev);
+   return ret;
+   }
+
/*
 * Write data to chip, protecting against concurrent updates
 * from this host, but not from other I2C masters.
@@ -559,6 +584,8 @@ static int at24_write(void *priv, unsigned int off, void 
*val, size_t count)
 
mutex_unlock(>lock);
 
+   pm_runtime_put(>dev);
+
return 0;
 }
 
@@ -743,6 +770,15 @@ static int at24_probe(struct i2c_client *client, const 
struct i2c_device_id *id)
 
i2c_set_clientdata(client, at24);
 
+   /* enable runtime pm */
+   pm_runtime_get_noresume(>dev);
+   err = pm_runtime_set_active(>dev);
+   if (err < 0)
+   goto err_clients;
+
+   pm_runtime_enable(>dev);
+   pm_runtime_put(>dev);
+
/*
 * Perform a one-byte test read to verify that the
 * chip is functional.
@@ -810,6 +846,9 @@ static int at24_remove(struct i2c_client *client)
for (i = 1; i < at24->num_addresses; i++)
i2c_unregister_device(at24->client[i]);
 
+   pm_runtime_disable(>dev);
+   pm_runtime_set_suspended(>dev);
+
return 0;
 }
 
-- 
1.9.1

[PATCH v3 2/3] eeprom: at24: add support to fetch eeprom device property "size"

[Divagar Mohandass]

Obtain the size of the EEPROM chip from DT if the "size" property is
specified for the device.

Signed-off-by: Divagar Mohandass 
---
 drivers/misc/eeprom/at24.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 764ff5df..2199c42 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -570,6 +570,10 @@ static void at24_get_pdata(struct device *dev, struct 
at24_platform_data *chip)
if (device_property_present(dev, "read-only"))
chip->flags |= AT24_FLAG_READONLY;
 
+   err = device_property_read_u32(dev, "size", );
+   if (!err)
+   chip->byte_len = val;
+
err = device_property_read_u32(dev, "pagesize", );
if (!err) {
chip->page_size = val;
-- 
1.9.1

[PATCH v3 2/3] eeprom: at24: add support to fetch eeprom device property "size"

[Divagar Mohandass]

Obtain the size of the EEPROM chip from DT if the "size" property is
specified for the device.

Signed-off-by: Divagar Mohandass 
---
 drivers/misc/eeprom/at24.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 764ff5df..2199c42 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -570,6 +570,10 @@ static void at24_get_pdata(struct device *dev, struct 
at24_platform_data *chip)
if (device_property_present(dev, "read-only"))
chip->flags |= AT24_FLAG_READONLY;
 
+   err = device_property_read_u32(dev, "size", );
+   if (!err)
+   chip->byte_len = val;
+
err = device_property_read_u32(dev, "pagesize", );
if (!err) {
chip->page_size = val;
-- 
1.9.1

[PATCH v3 0/3] enable eeprom "size" property and runtime pm

[Divagar Mohandass]

This series adds support for eeprom "size" property which will be read by the
driver for eeprom size. The existing ACPI has a different default size which
can be overridden with a DSD property value provided by the platform FW.

This series also adds support for runtime PM. The eeprom driver currently
did not have support for runtime PM and the device was kept in D0 throughout.

[v1]
- Add support for eeprom "size" property.
- Add runtime PM support to the driver.

[v2]
- Improved the patch subject.

[v3]
- Addressed comments from Sakari Ailus.
- Improved patch description.
- Improved pm support patch.

Divagar Mohandass (3):
  dt-bindings: add eeprom "size" property
  eeprom: at24: add support to fetch eeprom device property "size"
  eeprom: at24: enable runtime pm support

 .../devicetree/bindings/eeprom/eeprom.txt  |  2 +
 drivers/misc/eeprom/at24.c | 43 ++
 2 files changed, 45 insertions(+)

-- 
1.9.1

[PATCH v3 0/3] enable eeprom "size" property and runtime pm

[Divagar Mohandass]

This series adds support for eeprom "size" property which will be read by the
driver for eeprom size. The existing ACPI has a different default size which
can be overridden with a DSD property value provided by the platform FW.

This series also adds support for runtime PM. The eeprom driver currently
did not have support for runtime PM and the device was kept in D0 throughout.

[v1]
- Add support for eeprom "size" property.
- Add runtime PM support to the driver.

[v2]
- Improved the patch subject.

[v3]
- Addressed comments from Sakari Ailus.
- Improved patch description.
- Improved pm support patch.

Divagar Mohandass (3):
  dt-bindings: add eeprom "size" property
  eeprom: at24: add support to fetch eeprom device property "size"
  eeprom: at24: enable runtime pm support

 .../devicetree/bindings/eeprom/eeprom.txt  |  2 +
 drivers/misc/eeprom/at24.c | 43 ++
 2 files changed, 45 insertions(+)

-- 
1.9.1

[PATCH v3 1/3] dt-bindings: add eeprom "size" property

[Divagar Mohandass]

This adds eeprom "size" as optional property for i2c eeproms.
The "size" property allows explicitly specifying the size of the
EEPROM chip in bytes.

Signed-off-by: Divagar Mohandass 
---
 Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 5696eb5..1436569 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -32,6 +32,8 @@ Optional properties:
 
   - read-only: this parameterless property disables writes to the eeprom
 
+  - size: total eeprom size in bytes
+
 Example:
 
 eeprom@52 {
-- 
1.9.1

[PATCH v3 1/3] dt-bindings: add eeprom "size" property

[Divagar Mohandass]

This adds eeprom "size" as optional property for i2c eeproms.
The "size" property allows explicitly specifying the size of the
EEPROM chip in bytes.

Signed-off-by: Divagar Mohandass 
---
 Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt 
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
index 5696eb5..1436569 100644
--- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
+++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
@@ -32,6 +32,8 @@ Optional properties:
 
   - read-only: this parameterless property disables writes to the eeprom
 
+  - size: total eeprom size in bytes
+
 Example:
 
 eeprom@52 {
-- 
1.9.1

RE: [PATCH v2 3/3] eeprom: at24: enable runtime pm support

[Mohandass, Divagar]

Hi Sakari,

Thanks for your review comments.
My comments below.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:26 PM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v2 3/3] eeprom: at24: enable runtime pm support
>
>Hi Divagar,
>
>Thanks for the patch. Please see my comments below.
>
>On Tue, Aug 15, 2017 at 12:11:59AM +0530, Divagar Mohandass wrote:
>> Currently the device is kept in D0, there is an opportunity to save
>> power by enabling runtime pm.
>>
>> Device can be daisy chained from PMIC and we can't rely on I2C core
>> for auto resume/suspend. Driver will decide when to resume/suspend.
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  drivers/misc/eeprom/at24.c | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>> index 2199c42..0d26681 100644
>> --- a/drivers/misc/eeprom/at24.c
>> +++ b/drivers/misc/eeprom/at24.c
>> @@ -24,6 +24,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /*
>>   * I2C EEPROMs from most vendors are inexpensive and mostly
>interchangeable.
>> @@ -501,11 +502,21 @@ static ssize_t at24_eeprom_write_i2c(struct
>> at24_data *at24, const char *buf,  static int at24_read(void *priv,
>> unsigned int off, void *val, size_t count)  {
>>  struct at24_data *at24 = priv;
>> +struct i2c_client *client;
>>  char *buf = val;
>> +int ret;
>>
>>  if (unlikely(!count))
>>  return count;
>>
>> +client = at24_translate_offset(at24, );
>> +
>> +ret = pm_runtime_get_sync(>dev);
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(>dev);
>> +return ret;
>> +}
>> +
>
>at24_read() may fail between the two chunks here. You'll need
>pm_runtime_put() before returning the error code.

Ack

>
>>  /*
>>   * Read data from chip, protecting against concurrent updates
>>   * from this host, but not from other I2C masters.
>> @@ -527,17 +538,29 @@ static int at24_read(void *priv, unsigned int
>> off, void *val, size_t count)
>>
>>  mutex_unlock(>lock);
>>
>> +pm_runtime_put(>dev);
>> +
>>  return 0;
>>  }
>>
>>  static int at24_write(void *priv, unsigned int off, void *val, size_t
>> count)  {
>>  struct at24_data *at24 = priv;
>> +struct i2c_client *client;
>>  char *buf = val;
>> +int ret;
>>
>>  if (unlikely(!count))
>>  return -EINVAL;
>>
>> +client = at24_translate_offset(at24, );
>> +
>> +ret = pm_runtime_get_sync(>dev);
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(>dev);
>> +return ret;
>> +}
>> +
>>  /*
>>   * Write data to chip, protecting against concurrent updates
>>   * from this host, but not from other I2C masters.
>
>Ditto for write.

Ack

>
>> @@ -559,6 +582,8 @@ static int at24_write(void *priv, unsigned int
>> off, void *val, size_t count)
>>
>>  mutex_unlock(>lock);
>>
>> +pm_runtime_put(>dev);
>> +
>>  return 0;
>>  }
>>
>> @@ -743,6 +768,13 @@ static int at24_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>>
>>  i2c_set_clientdata(client, at24);
>>
>> +/* enable runtime pm */
>> +err = pm_runtime_set_active(>dev);
>> +if (err < 0)
>> +goto err_clients;
>> +
>> +pm_runtime_enable(>dev);
>> +
>
>Here, too: at24_read() below can fail, as well as nvmem_register().

Ack
In addition to that calling pm_runtime_get_noresume before enabling pm.

>
>>  /*
>>   * Perform a one-byte test read to verify that the
>>   * chip is functional.
>> @@ -810,6 +842,8 @@ static int at24_remove(struct i2c_client *client)
>>  for (i = 1; i < at24->num_addresses; i++)
>>  i2c_unregister_device(at24->client[i]);
>>
>> +pm_runtime_disable(>dev);
>
>pm_runtime_set_suspended(>dev)

Ack

>
>> +
>>  return 0;
>>  }
>>
>
>--
>Regards,
>
>Sakari Ailus
>e-mail: sakari.ai...@iki.fi

RE: [PATCH v2 3/3] eeprom: at24: enable runtime pm support

[Mohandass, Divagar]

Hi Sakari,

Thanks for your review comments.
My comments below.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:26 PM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v2 3/3] eeprom: at24: enable runtime pm support
>
>Hi Divagar,
>
>Thanks for the patch. Please see my comments below.
>
>On Tue, Aug 15, 2017 at 12:11:59AM +0530, Divagar Mohandass wrote:
>> Currently the device is kept in D0, there is an opportunity to save
>> power by enabling runtime pm.
>>
>> Device can be daisy chained from PMIC and we can't rely on I2C core
>> for auto resume/suspend. Driver will decide when to resume/suspend.
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  drivers/misc/eeprom/at24.c | 34 ++
>>  1 file changed, 34 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>> index 2199c42..0d26681 100644
>> --- a/drivers/misc/eeprom/at24.c
>> +++ b/drivers/misc/eeprom/at24.c
>> @@ -24,6 +24,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  /*
>>   * I2C EEPROMs from most vendors are inexpensive and mostly
>interchangeable.
>> @@ -501,11 +502,21 @@ static ssize_t at24_eeprom_write_i2c(struct
>> at24_data *at24, const char *buf,  static int at24_read(void *priv,
>> unsigned int off, void *val, size_t count)  {
>>  struct at24_data *at24 = priv;
>> +struct i2c_client *client;
>>  char *buf = val;
>> +int ret;
>>
>>  if (unlikely(!count))
>>  return count;
>>
>> +client = at24_translate_offset(at24, );
>> +
>> +ret = pm_runtime_get_sync(>dev);
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(>dev);
>> +return ret;
>> +}
>> +
>
>at24_read() may fail between the two chunks here. You'll need
>pm_runtime_put() before returning the error code.

Ack

>
>>  /*
>>   * Read data from chip, protecting against concurrent updates
>>   * from this host, but not from other I2C masters.
>> @@ -527,17 +538,29 @@ static int at24_read(void *priv, unsigned int
>> off, void *val, size_t count)
>>
>>  mutex_unlock(>lock);
>>
>> +pm_runtime_put(>dev);
>> +
>>  return 0;
>>  }
>>
>>  static int at24_write(void *priv, unsigned int off, void *val, size_t
>> count)  {
>>  struct at24_data *at24 = priv;
>> +struct i2c_client *client;
>>  char *buf = val;
>> +int ret;
>>
>>  if (unlikely(!count))
>>  return -EINVAL;
>>
>> +client = at24_translate_offset(at24, );
>> +
>> +ret = pm_runtime_get_sync(>dev);
>> +if (ret < 0) {
>> +pm_runtime_put_noidle(>dev);
>> +return ret;
>> +}
>> +
>>  /*
>>   * Write data to chip, protecting against concurrent updates
>>   * from this host, but not from other I2C masters.
>
>Ditto for write.

Ack

>
>> @@ -559,6 +582,8 @@ static int at24_write(void *priv, unsigned int
>> off, void *val, size_t count)
>>
>>  mutex_unlock(>lock);
>>
>> +pm_runtime_put(>dev);
>> +
>>  return 0;
>>  }
>>
>> @@ -743,6 +768,13 @@ static int at24_probe(struct i2c_client *client,
>> const struct i2c_device_id *id)
>>
>>  i2c_set_clientdata(client, at24);
>>
>> +/* enable runtime pm */
>> +err = pm_runtime_set_active(>dev);
>> +if (err < 0)
>> +goto err_clients;
>> +
>> +pm_runtime_enable(>dev);
>> +
>
>Here, too: at24_read() below can fail, as well as nvmem_register().

Ack
In addition to that calling pm_runtime_get_noresume before enabling pm.

>
>>  /*
>>   * Perform a one-byte test read to verify that the
>>   * chip is functional.
>> @@ -810,6 +842,8 @@ static int at24_remove(struct i2c_client *client)
>>  for (i = 1; i < at24->num_addresses; i++)
>>  i2c_unregister_device(at24->client[i]);
>>
>> +pm_runtime_disable(>dev);
>
>pm_runtime_set_suspended(>dev)

Ack

>
>> +
>>  return 0;
>>  }
>>
>
>--
>Regards,
>
>Sakari Ailus
>e-mail: sakari.ai...@iki.fi

Re: [PATCH v2] membarrier: provide register sync core cmd

[Boqun Feng]

Hi Mathieu,

On Sun, Aug 27, 2017 at 01:50:35PM -0700, Mathieu Desnoyers wrote:
> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
> system call. It allows processes to register their intent to have their
> threads issue core serializing barriers in addition to memory barriers
> whenever a membarrier command is performed.
> 
> It is relevant for reclaim of JIT code, which requires to issue core
> serializing barriers on all threads running on behalf of a process
> after ensuring the old code is not visible anymore, before re-using
> memory for new code.
> 
> When a processes returns from a MEMBARRIER_CMD_REGISTER_SYNC_CORE
> command, it is guaranteed that all following MEMBARRIER_CMD_SHARED and
> MEMBARRIER_CMD_PRIVATE_EXPEDITED issue core serializing barriers, in
> addition to the memory barriers, on all of its running threads.
> 
> * Scheduler Overhead Benchmarks
> 
> Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
> taskset 01 ./perf bench sched pipe -T
> Linux v4.13-rc6
> 
>Avg. usecs/op Std.Dev. usecs/op
> Before this change: 2.75   0.12
> Non-registered processes:   2.73   0.08
> Registered processes:   3.07   0.02
> 
> Changes since v1:
> - Add missing MEMBARRIER_CMD_REGISTER_SYNC_CORE header documentation,
> - Add benchmarks to commit message.
> 
> Signed-off-by: Mathieu Desnoyers 
> CC: Peter Zijlstra 
> CC: Paul E. McKenney 
> CC: Boqun Feng 
> CC: Andrew Hunter 
> CC: Maged Michael 
> CC: gro...@google.com
> CC: Avi Kivity 
> CC: Benjamin Herrenschmidt 
> CC: Paul Mackerras 
> CC: Michael Ellerman 
> CC: Dave Watson 
> CC: Andy Lutomirski 
> CC: Will Deacon 
> CC: Hans Boehm 
> ---
>  fs/exec.c   |  1 +
>  include/linux/sched.h   | 52 
> +
>  include/uapi/linux/membarrier.h |  8 +++
>  kernel/fork.c   |  2 ++
>  kernel/sched/core.c |  3 +++
>  kernel/sched/membarrier.c   | 37 ++---
>  6 files changed, 100 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index 62175cbcc801..a4ab3253bac7 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1794,6 +1794,7 @@ static int do_execveat_common(int fd, struct filename 
> *filename,
>   /* execve succeeded */
>   current->fs->in_exec = 0;
>   current->in_execve = 0;
> + membarrier_execve(current);
>   acct_update_integrals(current);
>   task_numa_free(current);
>   free_bprm(bprm);
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8337e2db0bb2..b1ecdc4e8b84 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1086,6 +1086,9 @@ struct task_struct {
>   /* Used by LSM modules for access restriction: */
>   void*security;
>  #endif
> +#ifdef CONFIG_MEMBARRIER
> + int membarrier_sync_core;

Why put this in task_struct rather than mm_struct? If the reclaim of JIT
code is one of the target users, don't you want to make this as a
attribute of an address space?

Am I missing something subtle here?

Regards,
Boqun

> +#endif
>  
>   /*
>* New fields for task_struct should be added above here, so that
> @@ -1623,4 +1626,53 @@ extern long sched_getaffinity(pid_t pid, struct 
> cpumask *mask);
>  #define TASK_SIZE_OF(tsk)TASK_SIZE
>  #endif
>  
> +#ifdef CONFIG_MEMBARRIER
> +static inline void membarrier_fork(struct task_struct *t,
> + unsigned long clone_flags)
> +{
> + /*
> +  * Coherence of membarrier_sync_core against thread fork is
> +  * protected by siglock. membarrier_fork is called with siglock
> +  * held.
> +  */
> + t->membarrier_sync_core = current->membarrier_sync_core;
> +}
> +static inline void membarrier_execve(struct task_struct *t)
> +{
> + t->membarrier_sync_core = 0;
> +}
> +static inline void membarrier_sched_out(struct task_struct *t)
> +{
> + /*
> +  * Core serialization is performed before the memory barrier
> +  * preceding the store to rq->curr.
> +  */
> + if (unlikely(READ_ONCE(t->membarrier_sync_core)))
> + sync_core();
> +}
> +static inline void membarrier_sched_in(struct task_struct *t)
> +{
> + /*
> +  * Core serialization is performed after the memory barrier
> +  * following the store to rq->curr.
> +  */
> + if (unlikely(READ_ONCE(t->membarrier_sync_core)))
> + sync_core();
> +}
> +#else
> +static inline void membarrier_fork(struct task_struct *t,
> + unsigned long clone_flags)
> +{
> +}
> +static inline void membarrier_execve(struct task_struct 

Re: [PATCH v2] membarrier: provide register sync core cmd

[Boqun Feng]

Hi Mathieu,

On Sun, Aug 27, 2017 at 01:50:35PM -0700, Mathieu Desnoyers wrote:
> Add a new MEMBARRIER_CMD_REGISTER_SYNC_CORE command to the membarrier
> system call. It allows processes to register their intent to have their
> threads issue core serializing barriers in addition to memory barriers
> whenever a membarrier command is performed.
> 
> It is relevant for reclaim of JIT code, which requires to issue core
> serializing barriers on all threads running on behalf of a process
> after ensuring the old code is not visible anymore, before re-using
> memory for new code.
> 
> When a processes returns from a MEMBARRIER_CMD_REGISTER_SYNC_CORE
> command, it is guaranteed that all following MEMBARRIER_CMD_SHARED and
> MEMBARRIER_CMD_PRIVATE_EXPEDITED issue core serializing barriers, in
> addition to the memory barriers, on all of its running threads.
> 
> * Scheduler Overhead Benchmarks
> 
> Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz
> taskset 01 ./perf bench sched pipe -T
> Linux v4.13-rc6
> 
>Avg. usecs/op Std.Dev. usecs/op
> Before this change: 2.75   0.12
> Non-registered processes:   2.73   0.08
> Registered processes:   3.07   0.02
> 
> Changes since v1:
> - Add missing MEMBARRIER_CMD_REGISTER_SYNC_CORE header documentation,
> - Add benchmarks to commit message.
> 
> Signed-off-by: Mathieu Desnoyers 
> CC: Peter Zijlstra 
> CC: Paul E. McKenney 
> CC: Boqun Feng 
> CC: Andrew Hunter 
> CC: Maged Michael 
> CC: gro...@google.com
> CC: Avi Kivity 
> CC: Benjamin Herrenschmidt 
> CC: Paul Mackerras 
> CC: Michael Ellerman 
> CC: Dave Watson 
> CC: Andy Lutomirski 
> CC: Will Deacon 
> CC: Hans Boehm 
> ---
>  fs/exec.c   |  1 +
>  include/linux/sched.h   | 52 
> +
>  include/uapi/linux/membarrier.h |  8 +++
>  kernel/fork.c   |  2 ++
>  kernel/sched/core.c |  3 +++
>  kernel/sched/membarrier.c   | 37 ++---
>  6 files changed, 100 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/exec.c b/fs/exec.c
> index 62175cbcc801..a4ab3253bac7 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1794,6 +1794,7 @@ static int do_execveat_common(int fd, struct filename 
> *filename,
>   /* execve succeeded */
>   current->fs->in_exec = 0;
>   current->in_execve = 0;
> + membarrier_execve(current);
>   acct_update_integrals(current);
>   task_numa_free(current);
>   free_bprm(bprm);
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 8337e2db0bb2..b1ecdc4e8b84 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1086,6 +1086,9 @@ struct task_struct {
>   /* Used by LSM modules for access restriction: */
>   void*security;
>  #endif
> +#ifdef CONFIG_MEMBARRIER
> + int membarrier_sync_core;

Why put this in task_struct rather than mm_struct? If the reclaim of JIT
code is one of the target users, don't you want to make this as a
attribute of an address space?

Am I missing something subtle here?

Regards,
Boqun

> +#endif
>  
>   /*
>* New fields for task_struct should be added above here, so that
> @@ -1623,4 +1626,53 @@ extern long sched_getaffinity(pid_t pid, struct 
> cpumask *mask);
>  #define TASK_SIZE_OF(tsk)TASK_SIZE
>  #endif
>  
> +#ifdef CONFIG_MEMBARRIER
> +static inline void membarrier_fork(struct task_struct *t,
> + unsigned long clone_flags)
> +{
> + /*
> +  * Coherence of membarrier_sync_core against thread fork is
> +  * protected by siglock. membarrier_fork is called with siglock
> +  * held.
> +  */
> + t->membarrier_sync_core = current->membarrier_sync_core;
> +}
> +static inline void membarrier_execve(struct task_struct *t)
> +{
> + t->membarrier_sync_core = 0;
> +}
> +static inline void membarrier_sched_out(struct task_struct *t)
> +{
> + /*
> +  * Core serialization is performed before the memory barrier
> +  * preceding the store to rq->curr.
> +  */
> + if (unlikely(READ_ONCE(t->membarrier_sync_core)))
> + sync_core();
> +}
> +static inline void membarrier_sched_in(struct task_struct *t)
> +{
> + /*
> +  * Core serialization is performed after the memory barrier
> +  * following the store to rq->curr.
> +  */
> + if (unlikely(READ_ONCE(t->membarrier_sync_core)))
> + sync_core();
> +}
> +#else
> +static inline void membarrier_fork(struct task_struct *t,
> + unsigned long clone_flags)
> +{
> +}
> +static inline void membarrier_execve(struct task_struct *t)
> +{
> +}
> +static inline void membarrier_sched_out(struct task_struct *t)
> +{
> +}
> +static inline void membarrier_sched_in(struct task_struct *t)
> +{
> +}
> +#endif
> +
>  #endif
> diff --git a/include/uapi/linux/membarrier.h b/include/uapi/linux/membarrier.h
> index 6d47b3249d8a..933c35ebcc10 

RE: [PATCH v2 2/3] eeprom: at24: add support to fetch eeprom device property "size"

[Mohandass, Divagar]

Hi Sakari,

Thanks for your review comments. Will address it in next patch version.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:43 PM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v2 2/3] eeprom: at24: add support to fetch eeprom
>device property "size"
>
>Hi Divagar,
>
>On Tue, Aug 15, 2017 at 12:11:58AM +0530, Divagar Mohandass wrote:
>> This adds support to fetch device property "size" from _DSD.
>>
>> There is a CAT24C16/GT24C16S NVMEM chip part of the OV13858 camera
>> module and it is connected to i2c bus on Intel KBL board.
>> This device will use the existing ACPI ID INT3499 and platform fw will
>> expose "read-only", "pagesize" and "size" props via _DSD.
>
>Instead of the two paragraphs, how about:
>
>Obtain the size of the EEPROM chip from DT if the "size" property is specified
>for the device.
>
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  drivers/misc/eeprom/at24.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>> index 764ff5df..2199c42 100644
>> --- a/drivers/misc/eeprom/at24.c
>> +++ b/drivers/misc/eeprom/at24.c
>> @@ -570,6 +570,10 @@ static void at24_get_pdata(struct device *dev,
>struct at24_platform_data *chip)
>>  if (device_property_present(dev, "read-only"))
>>  chip->flags |= AT24_FLAG_READONLY;
>>
>> +err = device_property_read_u32(dev, "size", );
>> +if (!err)
>> +chip->byte_len = val;
>> +
>>  err = device_property_read_u32(dev, "pagesize", );
>>  if (!err) {
>>  chip->page_size = val;
>> --
>> 1.9.1
>>
>
>--
>Sakari Ailus
>e-mail: sakari.ai...@iki.fi

RE: [PATCH v2 2/3] eeprom: at24: add support to fetch eeprom device property "size"

[Mohandass, Divagar]

Hi Sakari,

Thanks for your review comments. Will address it in next patch version.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:43 PM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v2 2/3] eeprom: at24: add support to fetch eeprom
>device property "size"
>
>Hi Divagar,
>
>On Tue, Aug 15, 2017 at 12:11:58AM +0530, Divagar Mohandass wrote:
>> This adds support to fetch device property "size" from _DSD.
>>
>> There is a CAT24C16/GT24C16S NVMEM chip part of the OV13858 camera
>> module and it is connected to i2c bus on Intel KBL board.
>> This device will use the existing ACPI ID INT3499 and platform fw will
>> expose "read-only", "pagesize" and "size" props via _DSD.
>
>Instead of the two paragraphs, how about:
>
>Obtain the size of the EEPROM chip from DT if the "size" property is specified
>for the device.
>
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  drivers/misc/eeprom/at24.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
>> index 764ff5df..2199c42 100644
>> --- a/drivers/misc/eeprom/at24.c
>> +++ b/drivers/misc/eeprom/at24.c
>> @@ -570,6 +570,10 @@ static void at24_get_pdata(struct device *dev,
>struct at24_platform_data *chip)
>>  if (device_property_present(dev, "read-only"))
>>  chip->flags |= AT24_FLAG_READONLY;
>>
>> +err = device_property_read_u32(dev, "size", );
>> +if (!err)
>> +chip->byte_len = val;
>> +
>>  err = device_property_read_u32(dev, "pagesize", );
>>  if (!err) {
>>  chip->page_size = val;
>> --
>> 1.9.1
>>
>
>--
>Sakari Ailus
>e-mail: sakari.ai...@iki.fi

RE: [PATCH v2 1/3] dt-bindings: add eeprom "size" property

[Mohandass, Divagar]

Hi Sakari,

Thanks for your review comments. Will address it in next patch version.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:41 PM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v2 1/3] dt-bindings: add eeprom "size" property
>
>Hi Divagar,
>
>On Tue, Aug 15, 2017 at 12:11:57AM +0530, Divagar Mohandass wrote:
>> This adds eeprom "size" as optional property for i2c eeproms.
>>
>> "size" should be mentioned in byte and it should refer to the eeprom
>> size. This will be read by the driver and used to calculating the
>> number of bytes in read/write calls.
>
>Instead of the three lines above, how about:
>
>The "size" property allows explicitly specifying the size of the EEPROM chip in
>bytes.
>
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> index 5696eb5..1436569 100644
>> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -32,6 +32,8 @@ Optional properties:
>>
>>- read-only: this parameterless property disables writes to the
>> eeprom
>>
>> +  - size: total eeprom size in bytes
>> +
>>  Example:
>>
>>  eeprom@52 {
>> --
>> 1.9.1
>>
>
>--
>Regards,
>
>Sakari Ailus
>e-mail: sakari.ai...@iki.fi

RE: [PATCH v2 1/3] dt-bindings: add eeprom "size" property

[Mohandass, Divagar]

Hi Sakari,

Thanks for your review comments. Will address it in next patch version.

---
^Divagar

>-Original Message-
>From: Sakari Ailus [mailto:sakari.ai...@iki.fi]
>Sent: Tuesday, August 22, 2017 2:41 PM
>To: Mohandass, Divagar 
>Cc: robh...@kernel.org; mark.rutl...@arm.com; w...@the-dreams.de;
>devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
>ker...@vger.kernel.org; Mani, Rajmohan 
>Subject: Re: [PATCH v2 1/3] dt-bindings: add eeprom "size" property
>
>Hi Divagar,
>
>On Tue, Aug 15, 2017 at 12:11:57AM +0530, Divagar Mohandass wrote:
>> This adds eeprom "size" as optional property for i2c eeproms.
>>
>> "size" should be mentioned in byte and it should refer to the eeprom
>> size. This will be read by the driver and used to calculating the
>> number of bytes in read/write calls.
>
>Instead of the three lines above, how about:
>
>The "size" property allows explicitly specifying the size of the EEPROM chip in
>bytes.
>
>>
>> Signed-off-by: Divagar Mohandass 
>> ---
>>  Documentation/devicetree/bindings/eeprom/eeprom.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> index 5696eb5..1436569 100644
>> --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt
>> @@ -32,6 +32,8 @@ Optional properties:
>>
>>- read-only: this parameterless property disables writes to the
>> eeprom
>>
>> +  - size: total eeprom size in bytes
>> +
>>  Example:
>>
>>  eeprom@52 {
>> --
>> 1.9.1
>>
>
>--
>Regards,
>
>Sakari Ailus
>e-mail: sakari.ai...@iki.fi

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Anshuman Khandual]

On 08/29/2017 05:34 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
>> On 27/08/2017 02:18, Kirill A. Shutemov wrote:
 +
 +  if (unlikely(!vma->anon_vma))
 +  goto unlock;
>>> It deserves a comment.
>> You're right I'll add it in the next version.
>> For the record, the root cause is that __anon_vma_prepare() requires the
>> mmap_sem to be held because vm_next and vm_prev must be safe.
> But should that test not be:
> 
>   if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
>   goto unlock;

This makes more sense. We are backing off from speculative path
because struct anon_vma has not been created for this anonymous
vma and we cannot do that without holding mmap_sem. This should
have nothing to do with vma->vm_ops availability.

Re: [PATCH v2 14/20] mm: Provide speculative fault infrastructure

[Anshuman Khandual]

On 08/29/2017 05:34 PM, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
>> On 27/08/2017 02:18, Kirill A. Shutemov wrote:
 +
 +  if (unlikely(!vma->anon_vma))
 +  goto unlock;
>>> It deserves a comment.
>> You're right I'll add it in the next version.
>> For the record, the root cause is that __anon_vma_prepare() requires the
>> mmap_sem to be held because vm_next and vm_prev must be safe.
> But should that test not be:
> 
>   if (unlikely(vma_is_anonymous(vma) && !vma->anon_vma))
>   goto unlock;

This makes more sense. We are backing off from speculative path
because struct anon_vma has not been created for this anonymous
vma and we cannot do that without holding mmap_sem. This should
have nothing to do with vma->vm_ops availability.

RE: [PATCH] storvsc: fix memory leak on ring buffer busy

[Long Li]

> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, August 29, 2017 6:31 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; James E . J . Bottomley
> ; de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; Long Li
> 
> Subject: Re: [PATCH] storvsc: fix memory leak on ring buffer busy
> 
> 
> Long,
> 
> > When storvsc is sending I/O to Hyper-v, it may allocate a bigger
> > buffer descriptor for large data payload that can't fit into a
> > pre-allocated buffer descriptor. This bigger buffer is freed on return
> > path.
> >
> > If I/O request to Hyper-v fails due to ring buffer busy, the storvsc
> > allocated buffer descriptor should also be freed.
> 
> Which kernel version is this patch aimed at?

Martin, thanks for pointing this out. This should also go to stable trees.

Cc: sta...@vger.kernel.org
> 
> --
> Martin K. PetersenOracle Linux Engineering

RE: [PATCH] storvsc: fix memory leak on ring buffer busy

[Long Li]

> -Original Message-
> From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
> Sent: Tuesday, August 29, 2017 6:31 PM
> To: Long Li 
> Cc: KY Srinivasan ; Haiyang Zhang
> ; James E . J . Bottomley
> ; de...@linuxdriverproject.org; linux-
> s...@vger.kernel.org; linux-kernel@vger.kernel.org; Long Li
> 
> Subject: Re: [PATCH] storvsc: fix memory leak on ring buffer busy
> 
> 
> Long,
> 
> > When storvsc is sending I/O to Hyper-v, it may allocate a bigger
> > buffer descriptor for large data payload that can't fit into a
> > pre-allocated buffer descriptor. This bigger buffer is freed on return
> > path.
> >
> > If I/O request to Hyper-v fails due to ring buffer busy, the storvsc
> > allocated buffer descriptor should also be freed.
> 
> Which kernel version is this patch aimed at?

Martin, thanks for pointing this out. This should also go to stable trees.

Cc: sta...@vger.kernel.org
> 
> --
> Martin K. PetersenOracle Linux Engineering

Re: [PATCH RESEND v2 3/3] dt-bindings: mt8173-mtu3: add generic compatible and rename file

[Chunfeng Yun]

On Tue, 2017-08-29 at 13:08 +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 8/29/2017 12:20 PM, Chunfeng Yun wrote:
> 
> > The mt8173-mtu3.txt actually holds the bindings for all mediatek
> > SoCs with usb3 DRD IP, so add a generic compatible and change the
> > name to mediatek,mtu3.txt.
> > 
> > Signed-off-by: Chunfeng Yun 
> > Acked-by: Rob Herring 
> > ---
> >   .../usb/{mt8173-mtu3.txt => mediatek,mtu3.txt} |6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >   rename Documentation/devicetree/bindings/usb/{mt8173-mtu3.txt => 
> > mediatek,mtu3.txt} (92%)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> > b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> > similarity index 92%
> > rename from Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > rename to Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> > index b8ea394..722a029 100644
> > --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> > @@ -1,7 +1,11 @@
> >   The device node for Mediatek USB3.0 DRD controller
> >   
> >   Required properties:
> > - - compatible : should be "mediatek,mt8173-mtu3"
> > + - compatible : should be "mediatek,soc-model-mtu3", "mediatek,mtu3",
> 
> Worth enclosing soc-model in <>.
Ok, I'll modify it, thanks
> 
> > +   soc-model is the name of SoC, such as mt8173, mt2712 etc,
> > +   when using "mediatek,mtu3" compatible string, you need SoC specific
> > +   ones in addition, one of:
> > +   - "mediatek,mt8173-mtu3"
> >- reg : specifies physical base address and size of the registers
> >- reg-names: should be "mac" for device IP and "ippc" for IP port control
> >- interrupts : interrupt used by the device IP
> 
> MBR, Sergei

Re: [PATCH RESEND v2 3/3] dt-bindings: mt8173-mtu3: add generic compatible and rename file

[Chunfeng Yun]

On Tue, 2017-08-29 at 13:08 +0300, Sergei Shtylyov wrote:
> Hello!
> 
> On 8/29/2017 12:20 PM, Chunfeng Yun wrote:
> 
> > The mt8173-mtu3.txt actually holds the bindings for all mediatek
> > SoCs with usb3 DRD IP, so add a generic compatible and change the
> > name to mediatek,mtu3.txt.
> > 
> > Signed-off-by: Chunfeng Yun 
> > Acked-by: Rob Herring 
> > ---
> >   .../usb/{mt8173-mtu3.txt => mediatek,mtu3.txt} |6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >   rename Documentation/devicetree/bindings/usb/{mt8173-mtu3.txt => 
> > mediatek,mtu3.txt} (92%)
> > 
> > diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt 
> > b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> > similarity index 92%
> > rename from Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > rename to Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> > index b8ea394..722a029 100644
> > --- a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
> > +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
> > @@ -1,7 +1,11 @@
> >   The device node for Mediatek USB3.0 DRD controller
> >   
> >   Required properties:
> > - - compatible : should be "mediatek,mt8173-mtu3"
> > + - compatible : should be "mediatek,soc-model-mtu3", "mediatek,mtu3",
> 
> Worth enclosing soc-model in <>.
Ok, I'll modify it, thanks
> 
> > +   soc-model is the name of SoC, such as mt8173, mt2712 etc,
> > +   when using "mediatek,mtu3" compatible string, you need SoC specific
> > +   ones in addition, one of:
> > +   - "mediatek,mt8173-mtu3"
> >- reg : specifies physical base address and size of the registers
> >- reg-names: should be "mac" for device IP and "ippc" for IP port control
> >- interrupts : interrupt used by the device IP
> 
> MBR, Sergei

d82fed7529 ("locking/lockdep/selftests: Fix mixed read-write .."): BUG: -1 unexpected failures (out of 262) - debugging disabled! |

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core

commit d82fed75294229abc9d757f08a4817febae6c4f4
Author: Peter Zijlstra <pet...@infradead.org>
AuthorDate: Mon Aug 28 14:42:45 2017 +0200
Commit: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue Aug 29 15:15:17 2017 +0200

locking/lockdep/selftests: Fix mixed read-write ABBA tests

Commit:

  e91498589746 ("locking/lockdep/selftests: Add mixed read-write ABBA 
tests")

adds an explicit FAILURE to the locking selftest but overlooked the
fact that this kills lockdep. Fudge the test to avoid this.

Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: h...@zytor.com
Link: 
http://lkml.kernel.org/r/20170828124245.xlo2yshxq2btg...@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mi...@kernel.org>

ec81048cc3  sched/completion: Avoid unnecessary stack allocation for 
COMPLETION_INITIALIZER_ONSTACK()
d82fed7529  locking/lockdep/selftests: Fix mixed read-write ABBA tests
d82fed7529  locking/lockdep/selftests: Fix mixed read-write ABBA tests
ddad247ed1  Merge branch 'perf/core'
+-+++++
| | ec81048cc3 | 
d82fed7529 | d82fed7529 | ddad247ed1 |
+-+++++
| boot_successes  | 35 | 0  
| 0  | 0  |
| boot_failures   | 0  | 15 
| 15 | 19 |
| BUG:-#unexpected_failures(out_of#)-debugging_disabled!| | 0  | 15 
| 15 | 19 |
+-+++++

[0.004000]   context:failed|  ok  |  ok  |
[0.004000]   try:failed|  ok  |failed|
[0.004000] block:failed|  ok  |failed|
[0.004000]  spinlock:failed|  ok  |failed|
[0.004000] -
[0.004000] BUG:  -1 unexpected failures (out of 262) - debugging disabled! |
[0.004000] -
[0.004000] clocksource: hpet: mask: 0x max_cycles: 0x, 
max_idle_ns: 19112604467 ns
[0.004000] hpet clockevent registered
[0.004009] tsc: Detected 2693.508 MHz processor
[0.005226] Calibrating delay loop (skipped) preset value.. 5387.01 BogoMIPS 
(lpj=10774032)

  # HH:MM RESULT GOOD 
BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start c9d2cddca4506727eae2e7d2df0620edbf49e82e 
cc4a41fe5541a73019a864883297bd5043aa6d98 --
git bisect  bad 5a5ab909d6bfaee8dd1332c7de7cc02ff3ec087f  # 07:17  B  0
11   28   4  Merge 'wsa/i2c/for-next' into devel-catchup-201708300632
git bisect  bad 2bf7c98887d8158669b5ded3ab55d6b211eea807  # 07:34  B  0
11   28   4  Merge 'andersson-remoteproc/rpmsg-next' into 
devel-catchup-201708300632
git bisect  bad 0dee929f30bd25284c2f49fee5546691222a05b0  # 07:51  B  0
11   26   2  Merge 'tip/master' into devel-catchup-201708300632
git bisect good 08cc918622aa4d5516f770f8246d41f4a30c2c61  # 08:02  G 11 
00   0  0day base guard for 'devel-catchup-201708300632'
git bisect good 1b2f76d77a277bb70d38ad0991ed7f16bbc115a9  # 08:17  G 11     
0    0   0  Merge tag 'perf-core-for-mingo-4.14-20170829' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
git bisect  bad 8ea7c2d9a971f95ec9f6ffac60cb4847d35f0b36  # 08:27  B  0 
3   16   0  manual merge of locking/core
git bisect good af07c8069f9951cff957500f3adce04b8665934c  # 08:44  G 11 
00   0  Merge branch 'efi/core'
git bisect good 70911fdc9576f4eeb3986689a1c9a778a4a4aacb  # 09:02  G 11 
00   0  locking/lockdep: Change the meaning of check_prev_add()'s return 
value
git bisect good a1d14934ea4b9db816a8dbfeab1c3e7204a0d871  # 09:16  G 11 
00   0  workqueue/lockdep: 'Fix' flush_work() annotation
git bisect good 500912121411e0175d44b69a7810ac6068e78326  # 09:29  G 11 
00   0  irqchip/xtensa-mx: Report that effective affinity is a single target
git bisect good d45e3dd0a26d52e508e7796cb8f86cde4b3d8a92  # 09:43  G 11 
00   0  Merge branch 'irq/core'
git bisect good 966a967116e699762dbf4af7f9e0d1955c25aa37  # 09:55  G 11 
00   0  smp: Avoid u

d82fed7529 ("locking/lockdep/selftests: Fix mixed read-write .."): BUG: -1 unexpected failures (out of 262) - debugging disabled! |

[kernel test robot]

Greetings,

0day kernel testing robot got the below dmesg and the first bad commit is

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core

commit d82fed75294229abc9d757f08a4817febae6c4f4
Author: Peter Zijlstra 
AuthorDate: Mon Aug 28 14:42:45 2017 +0200
Commit: Ingo Molnar 
CommitDate: Tue Aug 29 15:15:17 2017 +0200

locking/lockdep/selftests: Fix mixed read-write ABBA tests

Commit:

  e91498589746 ("locking/lockdep/selftests: Add mixed read-write ABBA 
tests")

adds an explicit FAILURE to the locking selftest but overlooked the
fact that this kills lockdep. Fudge the test to avoid this.

Signed-off-by: Peter Zijlstra (Intel) 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: h...@zytor.com
Link: 
http://lkml.kernel.org/r/20170828124245.xlo2yshxq2btg...@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar 

ec81048cc3  sched/completion: Avoid unnecessary stack allocation for 
COMPLETION_INITIALIZER_ONSTACK()
d82fed7529  locking/lockdep/selftests: Fix mixed read-write ABBA tests
d82fed7529  locking/lockdep/selftests: Fix mixed read-write ABBA tests
ddad247ed1  Merge branch 'perf/core'
+-+++++
| | ec81048cc3 | 
d82fed7529 | d82fed7529 | ddad247ed1 |
+-+++++
| boot_successes  | 35 | 0  
| 0  | 0  |
| boot_failures   | 0  | 15 
| 15 | 19 |
| BUG:-#unexpected_failures(out_of#)-debugging_disabled!| | 0  | 15 
| 15 | 19 |
+-+++++

[0.004000]   context:failed|  ok  |  ok  |
[0.004000]   try:failed|  ok  |failed|
[0.004000] block:failed|  ok  |failed|
[0.004000]  spinlock:failed|  ok  |failed|
[0.004000] -
[0.004000] BUG:  -1 unexpected failures (out of 262) - debugging disabled! |
[0.004000] -
[0.004000] clocksource: hpet: mask: 0x max_cycles: 0x, 
max_idle_ns: 19112604467 ns
[0.004000] hpet clockevent registered
[0.004009] tsc: Detected 2693.508 MHz processor
[0.005226] Calibrating delay loop (skipped) preset value.. 5387.01 BogoMIPS 
(lpj=10774032)

  # HH:MM RESULT GOOD 
BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start c9d2cddca4506727eae2e7d2df0620edbf49e82e 
cc4a41fe5541a73019a864883297bd5043aa6d98 --
git bisect  bad 5a5ab909d6bfaee8dd1332c7de7cc02ff3ec087f  # 07:17  B  0
11   28   4  Merge 'wsa/i2c/for-next' into devel-catchup-201708300632
git bisect  bad 2bf7c98887d8158669b5ded3ab55d6b211eea807  # 07:34  B  0
11   28   4  Merge 'andersson-remoteproc/rpmsg-next' into 
devel-catchup-201708300632
git bisect  bad 0dee929f30bd25284c2f49fee5546691222a05b0  # 07:51  B  0
11   26   2  Merge 'tip/master' into devel-catchup-201708300632
git bisect good 08cc918622aa4d5516f770f8246d41f4a30c2c61  # 08:02  G 11 
00   0  0day base guard for 'devel-catchup-201708300632'
git bisect good 1b2f76d77a277bb70d38ad0991ed7f16bbc115a9  # 08:17  G 11 
00   0  Merge tag 'perf-core-for-mingo-4.14-20170829' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
git bisect  bad 8ea7c2d9a971f95ec9f6ffac60cb4847d35f0b36  # 08:27  B  0 
3   16   0  manual merge of locking/core
git bisect good af07c8069f9951cff957500f3adce04b8665934c  # 08:44  G 11 
00   0  Merge branch 'efi/core'
git bisect good 70911fdc9576f4eeb3986689a1c9a778a4a4aacb  # 09:02  G 11 
00   0  locking/lockdep: Change the meaning of check_prev_add()'s return 
value
git bisect good a1d14934ea4b9db816a8dbfeab1c3e7204a0d871  # 09:16  G 11 
00   0  workqueue/lockdep: 'Fix' flush_work() annotation
git bisect good 500912121411e0175d44b69a7810ac6068e78326  # 09:29  G 11 
00   0  irqchip/xtensa-mx: Report that effective affinity is a single target
git bisect good d45e3dd0a26d52e508e7796cb8f86cde4b3d8a92  # 09:43  G 11 
00   0  Merge branch 'irq/core'
git bisect good 966a967116e699762dbf4af7f9e0d1955c25aa37  # 09:55  G 11 
00   0  smp: Avoid using two cache lines for struct call_single_data
git bisect good 1c322ac06d9af7ea259098ae5dc977855207d335  # 10:02  G 11 
00   0  acpi/nfit: Fix COMPLETION_INITIALIZER_ONSTACK() abuse

[PATCH] mm, uprobes: fix multiple free of ->uprobes_state.xol_area

[Eric Biggers]

From: Eric Biggers 

Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().

However, it was overlooked that this introduced an new error path before
the new mm_struct's ->uprobes_state.xol_area has been set to NULL after
being copied from the old mm_struct by the memcpy in dup_mm().  For a
task that has previously hit a uprobe tracepoint, this resulted in the
'struct xol_area' being freed multiple times if the task was killed at
just the right time while forking.

Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather
than in uprobe_dup_mmap().

With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C
program given by commit 2b7e8665b4ff ("fork: fix incorrect fput of
->exe_file causing use-after-free"), provided that a uprobe tracepoint
has been set on the fork_thread() function.  For example:

$ gcc reproducer.c -o reproducer -lpthread
$ nm reproducer | grep fork_thread
00400719 t fork_thread
$ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events
$ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
$ ./reproducer

Here is the use-after-free reported by KASAN:

BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200
Read of size 8 at addr 8800320a8b88 by task reproducer/198

CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f3fb5 
#255
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-20170228_101828-anatol 04/01/2014
Call Trace:
 dump_stack+0xdb/0x185
 print_address_description+0x7e/0x290
 kasan_report+0x23b/0x350
 __asan_report_load8_noabort+0x19/0x20
 uprobe_clear_state+0x1c4/0x200
 mmput+0xd6/0x360
 do_exit+0x740/0x1670
 do_group_exit+0x13f/0x380
 get_signal+0x597/0x17d0
 do_signal+0x99/0x1df0
 exit_to_usermode_loop+0x166/0x1e0
 syscall_return_slowpath+0x258/0x2c0
 entry_SYSCALL_64_fastpath+0xbc/0xbe

...

Allocated by task 199:
 save_stack_trace+0x1b/0x20
 kasan_kmalloc+0xfc/0x180
 kmem_cache_alloc_trace+0xf3/0x330
 __create_xol_area+0x10f/0x780
 uprobe_notify_resume+0x1674/0x2210
 exit_to_usermode_loop+0x150/0x1e0
 prepare_exit_to_usermode+0x14b/0x180
 retint_user+0x8/0x20

Freed by task 199:
 save_stack_trace+0x1b/0x20
 kasan_slab_free+0xa8/0x1a0
 kfree+0xba/0x210
 uprobe_clear_state+0x151/0x200
 mmput+0xd6/0x360
 copy_process.part.8+0x605f/0x65d0
 _do_fork+0x1a5/0xbd0
 SyS_clone+0x19/0x20
 do_syscall_64+0x22f/0x660
 return_from_SYSCALL_64+0x0/0x7a

Note: without KASAN, you may instead see a "Bad page state" message, or
simply a general protection fault.

Fixes: 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write 
killable")
Reported-by: Oleg Nesterov 
Cc: Alexander Shishkin 
Cc: Andrew Morton 
Cc: Arnaldo Carvalho de Melo 
Cc: Dmitry Vyukov 
Cc: Ingo Molnar 
Cc: Konstantin Khlebnikov 
Cc: Mark Rutland 
Cc: Michal Hocko 
Cc: Peter Zijlstra 
Cc: Vlastimil Babka 
Cc: [v4.7+]
Signed-off-by: Eric Biggers 
---
 kernel/events/uprobes.c | 2 --
 kernel/fork.c   | 8 
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 0e137f98a50c..267f6ef91d97 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1262,8 +1262,6 @@ void uprobe_end_dup_mmap(void)
 
 void uprobe_dup_mmap(struct mm_struct *oldmm, struct mm_struct *newmm)
 {
-   newmm->uprobes_state.xol_area = NULL;
-
if (test_bit(MMF_HAS_UPROBES, >flags)) {
set_bit(MMF_HAS_UPROBES, >flags);
/* unconditionally, dup_mmap() skips VM_DONTCOPY vmas */
diff --git a/kernel/fork.c b/kernel/fork.c
index cbbea277b3fb..b7e9e57b71ea 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -785,6 +785,13 @@ static void mm_init_owner(struct mm_struct *mm, struct 
task_struct *p)
 #endif
 }
 
+static void mm_init_uprobes_state(struct mm_struct *mm)
+{
+#ifdef CONFIG_UPROBES
+   mm->uprobes_state.xol_area = NULL;
+#endif
+}
+
 static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
struct user_namespace *user_ns)
 {
@@ -812,6 +819,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, 
struct task_struct *p,
 #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
mm->pmd_huge_pte = NULL;
 #endif
+   mm_init_uprobes_state(mm);
 
if (current->mm) {
mm->flags = current->mm->flags & MMF_INIT_MASK;
-- 
2.14.1

[PATCH] mm, uprobes: fix multiple free of ->uprobes_state.xol_area

[Eric Biggers]

From: Eric Biggers 

Commit 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for
write killable") made it possible to kill a forking task while it is
waiting to acquire its ->mmap_sem for write, in dup_mmap().

However, it was overlooked that this introduced an new error path before
the new mm_struct's ->uprobes_state.xol_area has been set to NULL after
being copied from the old mm_struct by the memcpy in dup_mm().  For a
task that has previously hit a uprobe tracepoint, this resulted in the
'struct xol_area' being freed multiple times if the task was killed at
just the right time while forking.

Fix it by setting ->uprobes_state.xol_area to NULL in mm_init() rather
than in uprobe_dup_mmap().

With CONFIG_UPROBE_EVENTS=y, the bug can be reproduced by the same C
program given by commit 2b7e8665b4ff ("fork: fix incorrect fput of
->exe_file causing use-after-free"), provided that a uprobe tracepoint
has been set on the fork_thread() function.  For example:

$ gcc reproducer.c -o reproducer -lpthread
$ nm reproducer | grep fork_thread
00400719 t fork_thread
$ echo "p $PWD/reproducer:0x719" > /sys/kernel/debug/tracing/uprobe_events
$ echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
$ ./reproducer

Here is the use-after-free reported by KASAN:

BUG: KASAN: use-after-free in uprobe_clear_state+0x1c4/0x200
Read of size 8 at addr 8800320a8b88 by task reproducer/198

CPU: 1 PID: 198 Comm: reproducer Not tainted 4.13.0-rc7-00015-g36fde05f3fb5 
#255
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-20170228_101828-anatol 04/01/2014
Call Trace:
 dump_stack+0xdb/0x185
 print_address_description+0x7e/0x290
 kasan_report+0x23b/0x350
 __asan_report_load8_noabort+0x19/0x20
 uprobe_clear_state+0x1c4/0x200
 mmput+0xd6/0x360
 do_exit+0x740/0x1670
 do_group_exit+0x13f/0x380
 get_signal+0x597/0x17d0
 do_signal+0x99/0x1df0
 exit_to_usermode_loop+0x166/0x1e0
 syscall_return_slowpath+0x258/0x2c0
 entry_SYSCALL_64_fastpath+0xbc/0xbe

...

Allocated by task 199:
 save_stack_trace+0x1b/0x20
 kasan_kmalloc+0xfc/0x180
 kmem_cache_alloc_trace+0xf3/0x330
 __create_xol_area+0x10f/0x780
 uprobe_notify_resume+0x1674/0x2210
 exit_to_usermode_loop+0x150/0x1e0
 prepare_exit_to_usermode+0x14b/0x180
 retint_user+0x8/0x20

Freed by task 199:
 save_stack_trace+0x1b/0x20
 kasan_slab_free+0xa8/0x1a0
 kfree+0xba/0x210
 uprobe_clear_state+0x151/0x200
 mmput+0xd6/0x360
 copy_process.part.8+0x605f/0x65d0
 _do_fork+0x1a5/0xbd0
 SyS_clone+0x19/0x20
 do_syscall_64+0x22f/0x660
 return_from_SYSCALL_64+0x0/0x7a

Note: without KASAN, you may instead see a "Bad page state" message, or
simply a general protection fault.

Fixes: 7c051267931a ("mm, fork: make dup_mmap wait for mmap_sem for write 
killable")
Reported-by: Oleg Nesterov 
Cc: Alexander Shishkin 
Cc: Andrew Morton 
Cc: Arnaldo Carvalho de Melo 
Cc: Dmitry Vyukov 
Cc: Ingo Molnar 
Cc: Konstantin Khlebnikov 
Cc: Mark Rutland 
Cc: Michal Hocko 
Cc: Peter Zijlstra 
Cc: Vlastimil Babka 
Cc: [v4.7+]
Signed-off-by: Eric Biggers 
---
 kernel/events/uprobes.c | 2 --
 kernel/fork.c   | 8 
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 0e137f98a50c..267f6ef91d97 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -1262,8 +1262,6 @@ void uprobe_end_dup_mmap(void)
 
 void uprobe_dup_mmap(struct mm_struct *oldmm, struct mm_struct *newmm)
 {
-   newmm->uprobes_state.xol_area = NULL;
-
if (test_bit(MMF_HAS_UPROBES, >flags)) {
set_bit(MMF_HAS_UPROBES, >flags);
/* unconditionally, dup_mmap() skips VM_DONTCOPY vmas */
diff --git a/kernel/fork.c b/kernel/fork.c
index cbbea277b3fb..b7e9e57b71ea 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -785,6 +785,13 @@ static void mm_init_owner(struct mm_struct *mm, struct 
task_struct *p)
 #endif
 }
 
+static void mm_init_uprobes_state(struct mm_struct *mm)
+{
+#ifdef CONFIG_UPROBES
+   mm->uprobes_state.xol_area = NULL;
+#endif
+}
+
 static struct mm_struct *mm_init(struct mm_struct *mm, struct task_struct *p,
struct user_namespace *user_ns)
 {
@@ -812,6 +819,7 @@ static struct mm_struct *mm_init(struct mm_struct *mm, 
struct task_struct *p,
 #if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
mm->pmd_huge_pte = NULL;
 #endif
+   mm_init_uprobes_state(mm);
 
if (current->mm) {
mm->flags = current->mm->flags & MMF_INIT_MASK;
-- 
2.14.1

Re: watchdog: mei_wdt: constify mei_cl_device_id

[Guenter Roeck]

On Sat, Aug 26, 2017 at 11:41:06AM +0530, Arvind Yadav wrote:
> mei_cl_device_id are not supposed to change at runtime. All functions
> working with mei_cl_device_id provided by  work
> with const mei_cl_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/mei_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> index b29c6fd..ea60b29 100644
> --- a/drivers/watchdog/mei_wdt.c
> +++ b/drivers/watchdog/mei_wdt.c
> @@ -670,7 +670,7 @@ static int mei_wdt_remove(struct mei_cl_device *cldev)
>  #define MEI_UUID_WD UUID_LE(0x05B79A6F, 0x4628, 0x4D7F, \
>   0x89, 0x9D, 0xA9, 0x15, 0x14, 0xCB, 0x32, 0xAB)
>  
> -static struct mei_cl_device_id mei_wdt_tbl[] = {
> +static const struct mei_cl_device_id mei_wdt_tbl[] = {
>   { .uuid = MEI_UUID_WD, .version = MEI_CL_VERSION_ANY },
>   /* required last entry */
>   { }

Re: watchdog: mei_wdt: constify mei_cl_device_id

[Guenter Roeck]

On Sat, Aug 26, 2017 at 11:41:06AM +0530, Arvind Yadav wrote:
> mei_cl_device_id are not supposed to change at runtime. All functions
> working with mei_cl_device_id provided by  work
> with const mei_cl_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/mei_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/mei_wdt.c b/drivers/watchdog/mei_wdt.c
> index b29c6fd..ea60b29 100644
> --- a/drivers/watchdog/mei_wdt.c
> +++ b/drivers/watchdog/mei_wdt.c
> @@ -670,7 +670,7 @@ static int mei_wdt_remove(struct mei_cl_device *cldev)
>  #define MEI_UUID_WD UUID_LE(0x05B79A6F, 0x4628, 0x4D7F, \
>   0x89, 0x9D, 0xA9, 0x15, 0x14, 0xCB, 0x32, 0xAB)
>  
> -static struct mei_cl_device_id mei_wdt_tbl[] = {
> +static const struct mei_cl_device_id mei_wdt_tbl[] = {
>   { .uuid = MEI_UUID_WD, .version = MEI_CL_VERSION_ANY },
>   /* required last entry */
>   { }

Re: watchdog: sp805: constify amba_id

[Guenter Roeck]

On Wed, Aug 23, 2017 at 10:04:08PM +0530, Arvind Yadav wrote:
> amba_id are not supposed to change at runtime. All functions
> working with const amba_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/sp805_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
> index e7a715e..03805bc 100644
> --- a/drivers/watchdog/sp805_wdt.c
> +++ b/drivers/watchdog/sp805_wdt.c
> @@ -281,7 +281,7 @@ static int __maybe_unused sp805_wdt_resume(struct device 
> *dev)
>  static SIMPLE_DEV_PM_OPS(sp805_wdt_dev_pm_ops, sp805_wdt_suspend,
>   sp805_wdt_resume);
>  
> -static struct amba_id sp805_wdt_ids[] = {
> +static const struct amba_id sp805_wdt_ids[] = {
>   {
>   .id = 0x00141805,
>   .mask   = 0x00ff,

Re: watchdog: sp805: constify amba_id

[Guenter Roeck]

On Wed, Aug 23, 2017 at 10:04:08PM +0530, Arvind Yadav wrote:
> amba_id are not supposed to change at runtime. All functions
> working with const amba_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/sp805_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
> index e7a715e..03805bc 100644
> --- a/drivers/watchdog/sp805_wdt.c
> +++ b/drivers/watchdog/sp805_wdt.c
> @@ -281,7 +281,7 @@ static int __maybe_unused sp805_wdt_resume(struct device 
> *dev)
>  static SIMPLE_DEV_PM_OPS(sp805_wdt_dev_pm_ops, sp805_wdt_suspend,
>   sp805_wdt_resume);
>  
> -static struct amba_id sp805_wdt_ids[] = {
> +static const struct amba_id sp805_wdt_ids[] = {
>   {
>   .id = 0x00141805,
>   .mask   = 0x00ff,

Re: watchdog: ziirave: constify i2c_device_id

[Guenter Roeck]

On Mon, Aug 21, 2017 at 10:18:38PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by  work with
> const i2c_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/ziirave_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c
> index b4e0cea..d3594aa 100644
> --- a/drivers/watchdog/ziirave_wdt.c
> +++ b/drivers/watchdog/ziirave_wdt.c
> @@ -737,7 +737,7 @@ static int ziirave_wdt_remove(struct i2c_client *client)
>   return 0;
>  }
>  
> -static struct i2c_device_id ziirave_wdt_id[] = {
> +static const struct i2c_device_id ziirave_wdt_id[] = {
>   { "rave-wdt", 0 },
>   { }
>  };

Re: watchdog: ziirave: constify i2c_device_id

[Guenter Roeck]

On Mon, Aug 21, 2017 at 10:18:38PM +0530, Arvind Yadav wrote:
> i2c_device_id are not supposed to change at runtime. All functions
> working with i2c_device_id provided by  work with
> const i2c_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/ziirave_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/ziirave_wdt.c b/drivers/watchdog/ziirave_wdt.c
> index b4e0cea..d3594aa 100644
> --- a/drivers/watchdog/ziirave_wdt.c
> +++ b/drivers/watchdog/ziirave_wdt.c
> @@ -737,7 +737,7 @@ static int ziirave_wdt_remove(struct i2c_client *client)
>   return 0;
>  }
>  
> -static struct i2c_device_id ziirave_wdt_id[] = {
> +static const struct i2c_device_id ziirave_wdt_id[] = {
>   { "rave-wdt", 0 },
>   { }
>  };

[PATCH] tracing: Ignore mmiotrace from kernel commandline

[Ziqian SUN (Zamir)]

From: "Ziqian SUN (Zamir)" 

The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and continue booting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196557
Signed-off-by: Ziqian SUN (Zamir) 
---
 kernel/trace/trace.c   | 35 ++-
 kernel/trace/trace.h   | 11 +++
 kernel/trace/trace_mmiotrace.c |  4 
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 44004d8..aba774d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -319,6 +319,34 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
kfree(pid_list);
 }
 
+/*struct list_head trace_noboot_tracer_list;*/
+struct mutex trace_noboot_tracer_lock;
+
+DEFINE_MUTEX(trace_noboot_tracer_lock);
+LIST_HEAD(trace_noboot_tracer_list);
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer)
+{
+   mutex_lock(_noboot_tracer_lock);
+   list_add(_tracer->list, _noboot_tracer_list);
+   mutex_unlock(_noboot_tracer_lock);
+}
+
+bool trace_noboot_tracer_find(const char *str)
+{
+   mutex_lock(_noboot_tracer_lock);
+   struct tracer_noboot *ptr = NULL;
+
+   list_for_each_entry(ptr, _noboot_tracer_list, list) {
+   if (strcmp(ptr->name, str) == 0) {
+   mutex_unlock(_noboot_tracer_lock);
+   return true;
+   }
+   }
+   mutex_unlock(_noboot_tracer_lock);
+   return false;
+}
+
 /**
  * trace_find_filtered_pid - check if a pid exists in a filtered_pid list
  * @filtered_pids: The list of pids to check
@@ -1641,8 +1669,13 @@ int __init register_tracer(struct tracer *type)
if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
goto out_unlock;
 
+   /* If the tracer should not be enabled by kernel parameter */
+   if (trace_noboot_tracer_find(type->name)) {
+   pr_warn("Tracer '%s' cannot be enabled during boot\n", 
type->name);
+   goto out_unlock;
+   }
+
printk(KERN_INFO "Starting tracer '%s'\n", type->name);
-   /* Do we want this tracer to start on bootup? */
tracing_set_tracer(_trace, type->name);
default_bootup_tracer = NULL;
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 490ba22..23bc668 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -502,6 +502,17 @@ enum {
TRACE_IRQ_BIT,
 };
 
+/*
+ * For tracer that cannot be enabled during boot time.
+ */
+
+struct tracer_noboot {
+   const char  *name;
+   struct list_headlist;
+};
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer);
+
 #define trace_recursion_set(bit)   do { (current)->trace_recursion |= 
(1<<(bit)); } while (0)
 #define trace_recursion_clear(bit) do { (current)->trace_recursion &= 
~(1<<(bit)); } while (0)
 #define trace_recursion_test(bit)  ((current)->trace_recursion & 
(1<<(bit)))
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index cd7480d..06aa0a5 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -286,6 +286,10 @@ static enum print_line_t mmio_print_line(struct 
trace_iterator *iter)
 
 __init static int init_mmio_trace(void)
 {
+   struct tracer_noboot mmio_notrace;
+
+   mmio_notrace.name = "mmiotrace";
+   trace_noboot_tracer_put(_notrace);
return register_tracer(_tracer);
 }
 device_initcall(init_mmio_trace);
-- 
1.8.3.1

[PATCH] tracing: Ignore mmiotrace from kernel commandline

[Ziqian SUN (Zamir)]

From: "Ziqian SUN (Zamir)" 

The mmiotrace tracer cannot be enabled with ftrace=mmiotrace in
kernel commandline. With this patch, a trace_noboot_tracer_list
is implemented and will be checked during system boot. If the
tracer declares itself as not for boot up, system will print out
a message and continue booting.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=196557
Signed-off-by: Ziqian SUN (Zamir) 
---
 kernel/trace/trace.c   | 35 ++-
 kernel/trace/trace.h   | 11 +++
 kernel/trace/trace_mmiotrace.c |  4 
 3 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 44004d8..aba774d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -319,6 +319,34 @@ void trace_free_pid_list(struct trace_pid_list *pid_list)
kfree(pid_list);
 }
 
+/*struct list_head trace_noboot_tracer_list;*/
+struct mutex trace_noboot_tracer_lock;
+
+DEFINE_MUTEX(trace_noboot_tracer_lock);
+LIST_HEAD(trace_noboot_tracer_list);
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer)
+{
+   mutex_lock(_noboot_tracer_lock);
+   list_add(_tracer->list, _noboot_tracer_list);
+   mutex_unlock(_noboot_tracer_lock);
+}
+
+bool trace_noboot_tracer_find(const char *str)
+{
+   mutex_lock(_noboot_tracer_lock);
+   struct tracer_noboot *ptr = NULL;
+
+   list_for_each_entry(ptr, _noboot_tracer_list, list) {
+   if (strcmp(ptr->name, str) == 0) {
+   mutex_unlock(_noboot_tracer_lock);
+   return true;
+   }
+   }
+   mutex_unlock(_noboot_tracer_lock);
+   return false;
+}
+
 /**
  * trace_find_filtered_pid - check if a pid exists in a filtered_pid list
  * @filtered_pids: The list of pids to check
@@ -1641,8 +1669,13 @@ int __init register_tracer(struct tracer *type)
if (strncmp(default_bootup_tracer, type->name, MAX_TRACER_SIZE))
goto out_unlock;
 
+   /* If the tracer should not be enabled by kernel parameter */
+   if (trace_noboot_tracer_find(type->name)) {
+   pr_warn("Tracer '%s' cannot be enabled during boot\n", 
type->name);
+   goto out_unlock;
+   }
+
printk(KERN_INFO "Starting tracer '%s'\n", type->name);
-   /* Do we want this tracer to start on bootup? */
tracing_set_tracer(_trace, type->name);
default_bootup_tracer = NULL;
 
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 490ba22..23bc668 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -502,6 +502,17 @@ enum {
TRACE_IRQ_BIT,
 };
 
+/*
+ * For tracer that cannot be enabled during boot time.
+ */
+
+struct tracer_noboot {
+   const char  *name;
+   struct list_headlist;
+};
+
+void trace_noboot_tracer_put(struct tracer_noboot *noboot_tracer);
+
 #define trace_recursion_set(bit)   do { (current)->trace_recursion |= 
(1<<(bit)); } while (0)
 #define trace_recursion_clear(bit) do { (current)->trace_recursion &= 
~(1<<(bit)); } while (0)
 #define trace_recursion_test(bit)  ((current)->trace_recursion & 
(1<<(bit)))
diff --git a/kernel/trace/trace_mmiotrace.c b/kernel/trace/trace_mmiotrace.c
index cd7480d..06aa0a5 100644
--- a/kernel/trace/trace_mmiotrace.c
+++ b/kernel/trace/trace_mmiotrace.c
@@ -286,6 +286,10 @@ static enum print_line_t mmio_print_line(struct 
trace_iterator *iter)
 
 __init static int init_mmio_trace(void)
 {
+   struct tracer_noboot mmio_notrace;
+
+   mmio_notrace.name = "mmiotrace";
+   trace_noboot_tracer_put(_notrace);
return register_tracer(_tracer);
 }
 device_initcall(init_mmio_trace);
-- 
1.8.3.1

Re: watchdog: sc1200: constify pnp_device_id

[Guenter Roeck]

On Wed, Aug 16, 2017 at 10:27:03AM +0530, Arvind Yadav wrote:
> pnp_device_id are not supposed to change at runtime. All functions
> working with pnp_device_id provided by  work with
> const pnp_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/sc1200wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/sc1200wdt.c b/drivers/watchdog/sc1200wdt.c
> index b34d3d5..8e4e2fc 100644
> --- a/drivers/watchdog/sc1200wdt.c
> +++ b/drivers/watchdog/sc1200wdt.c
> @@ -342,7 +342,7 @@ static int __init sc1200wdt_probe(void)
>  
>  #if defined CONFIG_PNP
>  
> -static struct pnp_device_id scl200wdt_pnp_devices[] = {
> +static const struct pnp_device_id scl200wdt_pnp_devices[] = {
>   /* National Semiconductor PC87307/PC97307 watchdog component */
>   {.id = "NSC0800", .driver_data = 0},
>   {.id = ""},

Re: watchdog: sc1200: constify pnp_device_id

[Guenter Roeck]

On Wed, Aug 16, 2017 at 10:27:03AM +0530, Arvind Yadav wrote:
> pnp_device_id are not supposed to change at runtime. All functions
> working with pnp_device_id provided by  work with
> const pnp_device_id. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/sc1200wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/sc1200wdt.c b/drivers/watchdog/sc1200wdt.c
> index b34d3d5..8e4e2fc 100644
> --- a/drivers/watchdog/sc1200wdt.c
> +++ b/drivers/watchdog/sc1200wdt.c
> @@ -342,7 +342,7 @@ static int __init sc1200wdt_probe(void)
>  
>  #if defined CONFIG_PNP
>  
> -static struct pnp_device_id scl200wdt_pnp_devices[] = {
> +static const struct pnp_device_id scl200wdt_pnp_devices[] = {
>   /* National Semiconductor PC87307/PC97307 watchdog component */
>   {.id = "NSC0800", .driver_data = 0},
>   {.id = ""},

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

[Nadav Amit]

Nadav Amit  wrote:

> Jerome Glisse  wrote:
> 
>> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>>> Jérôme Glisse  wrote:
>>> 
 Replacing all mmu_notifier_invalidate_page() by 
 mmu_notifier_invalidat_range()
 and making sure it is bracketed by call to 
 mmu_notifier_invalidate_range_start/
 end.
 
 Note that because we can not presume the pmd value or pte value we have to
 assume the worse and unconditionaly report an invalidation as happening.
 
 Signed-off-by: Jérôme Glisse 
 Cc: Dan Williams 
 Cc: Ross Zwisler 
 Cc: Linus Torvalds 
 Cc: Bernhard Held 
 Cc: Adam Borowski 
 Cc: Andrea Arcangeli 
 Cc: Radim Krčmář 
 Cc: Wanpeng Li 
 Cc: Paolo Bonzini 
 Cc: Takashi Iwai 
 Cc: Nadav Amit 
 Cc: Mike Galbraith 
 Cc: Kirill A. Shutemov 
 Cc: axie 
 Cc: Andrew Morton 
 ---
 mm/rmap.c | 44 +---
 1 file changed, 41 insertions(+), 3 deletions(-)
 
 diff --git a/mm/rmap.c b/mm/rmap.c
 index c8993c63eb25..da97ed525088 100644
 --- a/mm/rmap.c
 +++ b/mm/rmap.c
 @@ -887,11 +887,21 @@ static bool page_mkclean_one(struct page *page, 
 struct vm_area_struct *vma,
.address = address,
.flags = PVMW_SYNC,
};
 +  unsigned long start = address, end;
int *cleaned = arg;
 
 +  /*
 +   * We have to assume the worse case ie pmd for invalidation. Note that
 +   * the page can not be free from this function.
 +   */
 +  end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
 +  mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
 +
while (page_vma_mapped_walk()) {
 +  unsigned long cstart, cend;
int ret = 0;
 -  address = pvmw.address;
 +
 +  cstart = address = pvmw.address;
if (pvmw.pte) {
pte_t entry;
pte_t *pte = pvmw.pte;
 @@ -904,6 +914,7 @@ static bool page_mkclean_one(struct page *page, struct 
 vm_area_struct *vma,
entry = pte_wrprotect(entry);
entry = pte_mkclean(entry);
set_pte_at(vma->vm_mm, address, pte, entry);
 +  cend = cstart + PAGE_SIZE;
ret = 1;
} else {
 #ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
 @@ -918,6 +929,8 @@ static bool page_mkclean_one(struct page *page, struct 
 vm_area_struct *vma,
entry = pmd_wrprotect(entry);
entry = pmd_mkclean(entry);
set_pmd_at(vma->vm_mm, address, pmd, entry);
 +  cstart &= PMD_MASK;
 +  cend = cstart + PMD_SIZE;
ret = 1;
 #else
/* unexpected pmd-mapped page? */
 @@ -926,11 +939,13 @@ static bool page_mkclean_one(struct page *page, 
 struct vm_area_struct *vma,
}
 
if (ret) {
 -  mmu_notifier_invalidate_page(vma->vm_mm, address);
 +  mmu_notifier_invalidate_range(vma->vm_mm, cstart, cend);
(*cleaned)++;
}
}
 
 +  mmu_notifier_invalidate_range_end(vma->vm_mm, start, end);
 +
return true;
 }
 
 @@ -1324,6 +1339,7 @@ static bool try_to_unmap_one(struct page *page, 
 struct vm_area_struct *vma,
pte_t pteval;
struct page *subpage;
bool ret = true;
 +  unsigned long start = address, end;
enum ttu_flags flags = (enum ttu_flags)arg;
 
/* munlock has nothing to gain from examining un-locked vmas */
 @@ -1335,6 +1351,14 @@ static bool try_to_unmap_one(struct page *page, 
 struct vm_area_struct *vma,
flags & TTU_MIGRATION, page);
}
 
 +  /*
 +   * We have to assume the worse case ie pmd for invalidation. Note that
 +   * the page can not be free in this function as call of try_to_unmap()
 +   * must hold a reference on the page.
 +   */
 +  end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
 +  mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
 +
while (page_vma_mapped_walk()) {
/*
 * If the page is mlock()d, we cannot swap it out.
 @@ -1408,6 +1432,8 @@ static bool try_to_unmap_one(struct page *page, 
 struct 

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

[Nadav Amit]

Nadav Amit  wrote:

> Jerome Glisse  wrote:
> 
>> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>>> Jérôme Glisse  wrote:
>>> 
 Replacing all mmu_notifier_invalidate_page() by 
 mmu_notifier_invalidat_range()
 and making sure it is bracketed by call to 
 mmu_notifier_invalidate_range_start/
 end.
 
 Note that because we can not presume the pmd value or pte value we have to
 assume the worse and unconditionaly report an invalidation as happening.
 
 Signed-off-by: Jérôme Glisse 
 Cc: Dan Williams 
 Cc: Ross Zwisler 
 Cc: Linus Torvalds 
 Cc: Bernhard Held 
 Cc: Adam Borowski 
 Cc: Andrea Arcangeli 
 Cc: Radim Krčmář 
 Cc: Wanpeng Li 
 Cc: Paolo Bonzini 
 Cc: Takashi Iwai 
 Cc: Nadav Amit 
 Cc: Mike Galbraith 
 Cc: Kirill A. Shutemov 
 Cc: axie 
 Cc: Andrew Morton 
 ---
 mm/rmap.c | 44 +---
 1 file changed, 41 insertions(+), 3 deletions(-)
 
 diff --git a/mm/rmap.c b/mm/rmap.c
 index c8993c63eb25..da97ed525088 100644
 --- a/mm/rmap.c
 +++ b/mm/rmap.c
 @@ -887,11 +887,21 @@ static bool page_mkclean_one(struct page *page, 
 struct vm_area_struct *vma,
.address = address,
.flags = PVMW_SYNC,
};
 +  unsigned long start = address, end;
int *cleaned = arg;
 
 +  /*
 +   * We have to assume the worse case ie pmd for invalidation. Note that
 +   * the page can not be free from this function.
 +   */
 +  end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
 +  mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
 +
while (page_vma_mapped_walk()) {
 +  unsigned long cstart, cend;
int ret = 0;
 -  address = pvmw.address;
 +
 +  cstart = address = pvmw.address;
if (pvmw.pte) {
pte_t entry;
pte_t *pte = pvmw.pte;
 @@ -904,6 +914,7 @@ static bool page_mkclean_one(struct page *page, struct 
 vm_area_struct *vma,
entry = pte_wrprotect(entry);
entry = pte_mkclean(entry);
set_pte_at(vma->vm_mm, address, pte, entry);
 +  cend = cstart + PAGE_SIZE;
ret = 1;
} else {
 #ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
 @@ -918,6 +929,8 @@ static bool page_mkclean_one(struct page *page, struct 
 vm_area_struct *vma,
entry = pmd_wrprotect(entry);
entry = pmd_mkclean(entry);
set_pmd_at(vma->vm_mm, address, pmd, entry);
 +  cstart &= PMD_MASK;
 +  cend = cstart + PMD_SIZE;
ret = 1;
 #else
/* unexpected pmd-mapped page? */
 @@ -926,11 +939,13 @@ static bool page_mkclean_one(struct page *page, 
 struct vm_area_struct *vma,
}
 
if (ret) {
 -  mmu_notifier_invalidate_page(vma->vm_mm, address);
 +  mmu_notifier_invalidate_range(vma->vm_mm, cstart, cend);
(*cleaned)++;
}
}
 
 +  mmu_notifier_invalidate_range_end(vma->vm_mm, start, end);
 +
return true;
 }
 
 @@ -1324,6 +1339,7 @@ static bool try_to_unmap_one(struct page *page, 
 struct vm_area_struct *vma,
pte_t pteval;
struct page *subpage;
bool ret = true;
 +  unsigned long start = address, end;
enum ttu_flags flags = (enum ttu_flags)arg;
 
/* munlock has nothing to gain from examining un-locked vmas */
 @@ -1335,6 +1351,14 @@ static bool try_to_unmap_one(struct page *page, 
 struct vm_area_struct *vma,
flags & TTU_MIGRATION, page);
}
 
 +  /*
 +   * We have to assume the worse case ie pmd for invalidation. Note that
 +   * the page can not be free in this function as call of try_to_unmap()
 +   * must hold a reference on the page.
 +   */
 +  end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
 +  mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
 +
while (page_vma_mapped_walk()) {
/*
 * If the page is mlock()d, we cannot swap it out.
 @@ -1408,6 +1432,8 @@ static bool try_to_unmap_one(struct page *page, 
 struct vm_area_struct *vma,
set_huge_swap_pte_at(mm, address,
 pvmw.pte, pteval,
 vma_mmu_pagesize(vma));
 +  mmu_notifier_invalidate_range(mm, address,
 +  address + vma_mmu_pagesize(vma));
>>> 
>>> I don’t think that the 

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

[Nadav Amit]

Jerome Glisse  wrote:

> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>> Jérôme Glisse  wrote:
>> 
>>> Replacing all mmu_notifier_invalidate_page() by 
>>> mmu_notifier_invalidat_range()
>>> and making sure it is bracketed by call to 
>>> mmu_notifier_invalidate_range_start/
>>> end.
>>> 
>>> Note that because we can not presume the pmd value or pte value we have to
>>> assume the worse and unconditionaly report an invalidation as happening.
>>> 
>>> Signed-off-by: Jérôme Glisse 
>>> Cc: Dan Williams 
>>> Cc: Ross Zwisler 
>>> Cc: Linus Torvalds 
>>> Cc: Bernhard Held 
>>> Cc: Adam Borowski 
>>> Cc: Andrea Arcangeli 
>>> Cc: Radim Krčmář 
>>> Cc: Wanpeng Li 
>>> Cc: Paolo Bonzini 
>>> Cc: Takashi Iwai 
>>> Cc: Nadav Amit 
>>> Cc: Mike Galbraith 
>>> Cc: Kirill A. Shutemov 
>>> Cc: axie 
>>> Cc: Andrew Morton 
>>> ---
>>> mm/rmap.c | 44 +---
>>> 1 file changed, 41 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>> index c8993c63eb25..da97ed525088 100644
>>> --- a/mm/rmap.c
>>> +++ b/mm/rmap.c
>>> @@ -887,11 +887,21 @@ static bool page_mkclean_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> .address = address,
>>> .flags = PVMW_SYNC,
>>> };
>>> +   unsigned long start = address, end;
>>> int *cleaned = arg;
>>> 
>>> +   /*
>>> +* We have to assume the worse case ie pmd for invalidation. Note that
>>> +* the page can not be free from this function.
>>> +*/
>>> +   end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
>>> +   mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
>>> +
>>> while (page_vma_mapped_walk()) {
>>> +   unsigned long cstart, cend;
>>> int ret = 0;
>>> -   address = pvmw.address;
>>> +
>>> +   cstart = address = pvmw.address;
>>> if (pvmw.pte) {
>>> pte_t entry;
>>> pte_t *pte = pvmw.pte;
>>> @@ -904,6 +914,7 @@ static bool page_mkclean_one(struct page *page, struct 
>>> vm_area_struct *vma,
>>> entry = pte_wrprotect(entry);
>>> entry = pte_mkclean(entry);
>>> set_pte_at(vma->vm_mm, address, pte, entry);
>>> +   cend = cstart + PAGE_SIZE;
>>> ret = 1;
>>> } else {
>>> #ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
>>> @@ -918,6 +929,8 @@ static bool page_mkclean_one(struct page *page, struct 
>>> vm_area_struct *vma,
>>> entry = pmd_wrprotect(entry);
>>> entry = pmd_mkclean(entry);
>>> set_pmd_at(vma->vm_mm, address, pmd, entry);
>>> +   cstart &= PMD_MASK;
>>> +   cend = cstart + PMD_SIZE;
>>> ret = 1;
>>> #else
>>> /* unexpected pmd-mapped page? */
>>> @@ -926,11 +939,13 @@ static bool page_mkclean_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> }
>>> 
>>> if (ret) {
>>> -   mmu_notifier_invalidate_page(vma->vm_mm, address);
>>> +   mmu_notifier_invalidate_range(vma->vm_mm, cstart, cend);
>>> (*cleaned)++;
>>> }
>>> }
>>> 
>>> +   mmu_notifier_invalidate_range_end(vma->vm_mm, start, end);
>>> +
>>> return true;
>>> }
>>> 
>>> @@ -1324,6 +1339,7 @@ static bool try_to_unmap_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> pte_t pteval;
>>> struct page *subpage;
>>> bool ret = true;
>>> +   unsigned long start = address, end;
>>> enum ttu_flags flags = (enum ttu_flags)arg;
>>> 
>>> /* munlock has nothing to gain from examining un-locked vmas */
>>> @@ -1335,6 +1351,14 @@ static bool try_to_unmap_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> flags & TTU_MIGRATION, page);
>>> }
>>> 
>>> +   /*
>>> +* We have to assume the worse case ie pmd for invalidation. Note that
>>> +* the page can not be free in this function as call of try_to_unmap()
>>> +* must hold a reference on the page.
>>> +*/
>>> +   end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
>>> +   mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
>>> +
>>> while (page_vma_mapped_walk()) {
>>> /*
>>>  * If the page is mlock()d, we cannot swap it out.
>>> @@ -1408,6 +1432,8 @@ static bool try_to_unmap_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> set_huge_swap_pte_at(mm, address,
>>>

Re: [PATCH 02/13] mm/rmap: update to new mmu_notifier semantic

[Nadav Amit]

Jerome Glisse  wrote:

> On Tue, Aug 29, 2017 at 07:46:07PM -0700, Nadav Amit wrote:
>> Jérôme Glisse  wrote:
>> 
>>> Replacing all mmu_notifier_invalidate_page() by 
>>> mmu_notifier_invalidat_range()
>>> and making sure it is bracketed by call to 
>>> mmu_notifier_invalidate_range_start/
>>> end.
>>> 
>>> Note that because we can not presume the pmd value or pte value we have to
>>> assume the worse and unconditionaly report an invalidation as happening.
>>> 
>>> Signed-off-by: Jérôme Glisse 
>>> Cc: Dan Williams 
>>> Cc: Ross Zwisler 
>>> Cc: Linus Torvalds 
>>> Cc: Bernhard Held 
>>> Cc: Adam Borowski 
>>> Cc: Andrea Arcangeli 
>>> Cc: Radim Krčmář 
>>> Cc: Wanpeng Li 
>>> Cc: Paolo Bonzini 
>>> Cc: Takashi Iwai 
>>> Cc: Nadav Amit 
>>> Cc: Mike Galbraith 
>>> Cc: Kirill A. Shutemov 
>>> Cc: axie 
>>> Cc: Andrew Morton 
>>> ---
>>> mm/rmap.c | 44 +---
>>> 1 file changed, 41 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/mm/rmap.c b/mm/rmap.c
>>> index c8993c63eb25..da97ed525088 100644
>>> --- a/mm/rmap.c
>>> +++ b/mm/rmap.c
>>> @@ -887,11 +887,21 @@ static bool page_mkclean_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> .address = address,
>>> .flags = PVMW_SYNC,
>>> };
>>> +   unsigned long start = address, end;
>>> int *cleaned = arg;
>>> 
>>> +   /*
>>> +* We have to assume the worse case ie pmd for invalidation. Note that
>>> +* the page can not be free from this function.
>>> +*/
>>> +   end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
>>> +   mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
>>> +
>>> while (page_vma_mapped_walk()) {
>>> +   unsigned long cstart, cend;
>>> int ret = 0;
>>> -   address = pvmw.address;
>>> +
>>> +   cstart = address = pvmw.address;
>>> if (pvmw.pte) {
>>> pte_t entry;
>>> pte_t *pte = pvmw.pte;
>>> @@ -904,6 +914,7 @@ static bool page_mkclean_one(struct page *page, struct 
>>> vm_area_struct *vma,
>>> entry = pte_wrprotect(entry);
>>> entry = pte_mkclean(entry);
>>> set_pte_at(vma->vm_mm, address, pte, entry);
>>> +   cend = cstart + PAGE_SIZE;
>>> ret = 1;
>>> } else {
>>> #ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
>>> @@ -918,6 +929,8 @@ static bool page_mkclean_one(struct page *page, struct 
>>> vm_area_struct *vma,
>>> entry = pmd_wrprotect(entry);
>>> entry = pmd_mkclean(entry);
>>> set_pmd_at(vma->vm_mm, address, pmd, entry);
>>> +   cstart &= PMD_MASK;
>>> +   cend = cstart + PMD_SIZE;
>>> ret = 1;
>>> #else
>>> /* unexpected pmd-mapped page? */
>>> @@ -926,11 +939,13 @@ static bool page_mkclean_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> }
>>> 
>>> if (ret) {
>>> -   mmu_notifier_invalidate_page(vma->vm_mm, address);
>>> +   mmu_notifier_invalidate_range(vma->vm_mm, cstart, cend);
>>> (*cleaned)++;
>>> }
>>> }
>>> 
>>> +   mmu_notifier_invalidate_range_end(vma->vm_mm, start, end);
>>> +
>>> return true;
>>> }
>>> 
>>> @@ -1324,6 +1339,7 @@ static bool try_to_unmap_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> pte_t pteval;
>>> struct page *subpage;
>>> bool ret = true;
>>> +   unsigned long start = address, end;
>>> enum ttu_flags flags = (enum ttu_flags)arg;
>>> 
>>> /* munlock has nothing to gain from examining un-locked vmas */
>>> @@ -1335,6 +1351,14 @@ static bool try_to_unmap_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> flags & TTU_MIGRATION, page);
>>> }
>>> 
>>> +   /*
>>> +* We have to assume the worse case ie pmd for invalidation. Note that
>>> +* the page can not be free in this function as call of try_to_unmap()
>>> +* must hold a reference on the page.
>>> +*/
>>> +   end = min(vma->vm_end, (start & PMD_MASK) + PMD_SIZE);
>>> +   mmu_notifier_invalidate_range_start(vma->vm_mm, start, end);
>>> +
>>> while (page_vma_mapped_walk()) {
>>> /*
>>>  * If the page is mlock()d, we cannot swap it out.
>>> @@ -1408,6 +1432,8 @@ static bool try_to_unmap_one(struct page *page, 
>>> struct vm_area_struct *vma,
>>> set_huge_swap_pte_at(mm, address,
>>>  pvmw.pte, pteval,
>>>  vma_mmu_pagesize(vma));
>>> +   mmu_notifier_invalidate_range(mm, address,
>>> +   address + vma_mmu_pagesize(vma));
>> 
>> I don’t think that the notifier should be called after the PTE is set, but
>> after the PTE is cleared, PTE 

Re: [PATCH v6 4/4] perf vendor events arm64: Add ThunderX2 implementation defined pmu core events

[Zhangshaokun]

Hi Robert,

Got it and thanks your reply.

Shaokun

On 2017/8/29 20:47, Robert Richter wrote:
> Shaokun,
> 
> On 29.08.17 17:26:00, Zhangshaokun wrote:
>> On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>>> This is not a full event list, but a short list of useful events.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>>>  .../arm64/thunderx2/implementation-defined.json| 62 
>>> ++
>>>  2 files changed, 77 insertions(+)
>>>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>>>  create mode 100644 
>>> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>>>
>>
>> I saw you also used thunderx2 in tools/perf/pmu-events/arch/arm64/, how 
>> about John's suggestion
>> that would use vendor sub-folder?
>> Of course, appreciate maintainer's comments.
> 
> this would just add another level of subdirectories. I rather would
> prefer to have a per platform dir comparable to what is listed in
> 
>  arch/arm64/Kconfig.platforms
> 
> This is the same as Ganapat has implemented it.
> 
> -Robert
> 
> 

Re: [PATCH v6 4/4] perf vendor events arm64: Add ThunderX2 implementation defined pmu core events

[Zhangshaokun]

Hi Robert,

Got it and thanks your reply.

Shaokun

On 2017/8/29 20:47, Robert Richter wrote:
> Shaokun,
> 
> On 29.08.17 17:26:00, Zhangshaokun wrote:
>> On 2017/8/24 20:03, Ganapatrao Kulkarni wrote:
>>> This is not a full event list, but a short list of useful events.
>>>
>>> Signed-off-by: Ganapatrao Kulkarni 
>>> ---
>>>  tools/perf/pmu-events/arch/arm64/mapfile.csv   | 15 ++
>>>  .../arm64/thunderx2/implementation-defined.json| 62 
>>> ++
>>>  2 files changed, 77 insertions(+)
>>>  create mode 100644 tools/perf/pmu-events/arch/arm64/mapfile.csv
>>>  create mode 100644 
>>> tools/perf/pmu-events/arch/arm64/thunderx2/implementation-defined.json
>>>
>>
>> I saw you also used thunderx2 in tools/perf/pmu-events/arch/arm64/, how 
>> about John's suggestion
>> that would use vendor sub-folder?
>> Of course, appreciate maintainer's comments.
> 
> this would just add another level of subdirectories. I rather would
> prefer to have a per platform dir comparable to what is listed in
> 
>  arch/arm64/Kconfig.platforms
> 
> This is the same as Ganapat has implemented it.
> 
> -Robert
> 
> 

[PATCH] i2c: sprd: Fix undefined reference errors

[Baolin Wang]

Since the i2c driver of Spreadtrum can not be build as one module, thus
it should depend on CONFIG_I2C is build in.

Signed-off-by: Baolin Wang 
---
 drivers/i2c/busses/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 64729ac..71036c1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -902,7 +902,7 @@ config I2C_SIRF
 
 config I2C_SPRD
bool "Spreadtrum I2C interface"
-   depends on ARCH_SPRD
+   depends on I2C=y && ARCH_SPRD
help
  If you say yes to this option, support will be included for the
  Spreadtrum I2C interface.
-- 
1.7.9.5

[PATCH] i2c: sprd: Fix undefined reference errors

[Baolin Wang]

Since the i2c driver of Spreadtrum can not be build as one module, thus
it should depend on CONFIG_I2C is build in.

Signed-off-by: Baolin Wang 
---
 drivers/i2c/busses/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 64729ac..71036c1 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -902,7 +902,7 @@ config I2C_SIRF
 
 config I2C_SPRD
bool "Spreadtrum I2C interface"
-   depends on ARCH_SPRD
+   depends on I2C=y && ARCH_SPRD
help
  If you say yes to this option, support will be included for the
  Spreadtrum I2C interface.
-- 
1.7.9.5

[PATCH v2] staging : gdm724x: Rename variable for consistency

[Nick Fox]

v2: Undo the renaming of the dft_eps_id variable in hci_pdn_table_ind
to resolve a compiler error.

Signed-off-by: Nick Fox 
---
 drivers/staging/gdm724x/hci_packet.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gdm724x/hci_packet.h 
b/drivers/staging/gdm724x/hci_packet.h
index 22ce8b9477b6..f8837c7103ac 100644
--- a/drivers/staging/gdm724x/hci_packet.h
+++ b/drivers/staging/gdm724x/hci_packet.h
@@ -50,7 +50,7 @@ struct tlv {
 struct sdu_header {
__dev16 cmd_evt;
__dev16 len;
-   __dev32 dftEpsId;
+   __dev32 dft_eps_ID;
__dev32 bearer_ID;
__dev32 nic_type;
 } __packed;
-- 
2.13.5

[PATCH v2] staging : gdm724x: Rename variable for consistency

[Nick Fox]

v2: Undo the renaming of the dft_eps_id variable in hci_pdn_table_ind
to resolve a compiler error.

Signed-off-by: Nick Fox 
---
 drivers/staging/gdm724x/hci_packet.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/gdm724x/hci_packet.h 
b/drivers/staging/gdm724x/hci_packet.h
index 22ce8b9477b6..f8837c7103ac 100644
--- a/drivers/staging/gdm724x/hci_packet.h
+++ b/drivers/staging/gdm724x/hci_packet.h
@@ -50,7 +50,7 @@ struct tlv {
 struct sdu_header {
__dev16 cmd_evt;
__dev16 len;
-   __dev32 dftEpsId;
+   __dev32 dft_eps_ID;
__dev32 bearer_ID;
__dev32 nic_type;
 } __packed;
-- 
2.13.5

[PATCH 1/7] ARM: dts: sun8i: h3: nanopi-m1: Enable IR controller

[Philipp Rossak]

From: Philipp Rossak 

The Nanopi M1 has an onboard IR receiver.
This enables the onboard IR receiver subnode.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
index ec63d10..3a2ccdb 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -55,6 +55,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH 1/7] ARM: dts: sun8i: h3: nanopi-m1: Enable IR controller

[Philipp Rossak]

From: Philipp Rossak 

The Nanopi M1 has an onboard IR receiver.
This enables the onboard IR receiver subnode.

Signed-off-by: Philipp Rossak 
---
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts 
b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
index ec63d10..3a2ccdb 100644
--- a/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
+++ b/arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts
@@ -55,6 +55,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+};
+
  {
status = "okay";
 };
-- 
2.7.4

[PATCH 0/7] [DTS] enable hardware for Nanopi M1 & Nanopi M1 Plus

[Philipp Rossak]

From: Philipp Rossak 

This Patchseries enables the IR controller and the dwmac-sun8i
on the Friendlyarm Nanopi M1 and Friendlyarm Nanopi M1 Plus boards.
On the Nanopi M1 Plus additionally the BT/Wifi module is activated.

Philipp Rossak (7):
  ARM: dts: sun8i: h3: nanopi-m1: Enable IR controller
  ARM: dts: sun8i: h3: nanopi-m1-plus: Enable IR controller
  ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1 Plus
  ARM: dts: sun8i: h3: Enable AP6212 WiFi on mmc1 on Nanopi M1 Plus
  ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1
  ARM: dts: sun8i: h3: Adding UART3 RTS and CTS Pins
  ARM: dts: sun8i: h3: Enable AP6212 BT on uart3 on Nanopi M1 Plus

 arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 80 +++
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts  | 17 ++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi|  5 ++
 3 files changed, 102 insertions(+)

-- 
2.7.4

[PATCH 0/7] [DTS] enable hardware for Nanopi M1 & Nanopi M1 Plus

[Philipp Rossak]

From: Philipp Rossak 

This Patchseries enables the IR controller and the dwmac-sun8i
on the Friendlyarm Nanopi M1 and Friendlyarm Nanopi M1 Plus boards.
On the Nanopi M1 Plus additionally the BT/Wifi module is activated.

Philipp Rossak (7):
  ARM: dts: sun8i: h3: nanopi-m1: Enable IR controller
  ARM: dts: sun8i: h3: nanopi-m1-plus: Enable IR controller
  ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1 Plus
  ARM: dts: sun8i: h3: Enable AP6212 WiFi on mmc1 on Nanopi M1 Plus
  ARM: dts: sun8i: h3: Enable dwmac-sun8i on the Nanopi M1
  ARM: dts: sun8i: h3: Adding UART3 RTS and CTS Pins
  ARM: dts: sun8i: h3: Enable AP6212 BT on uart3 on Nanopi M1 Plus

 arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts | 80 +++
 arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts  | 17 ++
 arch/arm/boot/dts/sunxi-h3-h5.dtsi|  5 ++
 3 files changed, 102 insertions(+)

-- 
2.7.4