[PATCH] x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc()

[Len Brown]

From: Len Brown 

The Intel Denverton microserver uses a 25 MHz TSC crystal,
so we can derive its exact * TSC frequency
using CPUID and some arithmetic, eg.

TSC: 1800 MHz (2500 Hz * 216 / 3 / 100)

* 'exact' is only as good as the crystal, which should be +/- 20ppm

Signed-off-by: Len Brown 
---
 arch/x86/kernel/tsc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46b2f41f8b05..b3e397a0f29d 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -694,6 +694,7 @@ unsigned long native_calibrate_tsc(void)
crystal_khz = 24000;/* 24.0 MHz */
break;
case INTEL_FAM6_SKYLAKE_X:
+   case INTEL_FAM6_ATOM_DENVERTON:
crystal_khz = 25000;/* 25.0 MHz */
break;
case INTEL_FAM6_ATOM_GOLDMONT:
-- 
2.11.0.161.g6610af872

[PATCH] x86 tsc: Add the Intel Denverton Processor to native_calibrate_tsc()

[Len Brown]

From: Len Brown 

The Intel Denverton microserver uses a 25 MHz TSC crystal,
so we can derive its exact * TSC frequency
using CPUID and some arithmetic, eg.

TSC: 1800 MHz (2500 Hz * 216 / 3 / 100)

* 'exact' is only as good as the crystal, which should be +/- 20ppm

Signed-off-by: Len Brown 
---
 arch/x86/kernel/tsc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 46b2f41f8b05..b3e397a0f29d 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -694,6 +694,7 @@ unsigned long native_calibrate_tsc(void)
crystal_khz = 24000;/* 24.0 MHz */
break;
case INTEL_FAM6_SKYLAKE_X:
+   case INTEL_FAM6_ATOM_DENVERTON:
crystal_khz = 25000;/* 25.0 MHz */
break;
case INTEL_FAM6_ATOM_GOLDMONT:
-- 
2.11.0.161.g6610af872

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

[Chanwoo Choi]

Hi Sylwester,

2017-01-21 16:42 GMT+09:00 Sylwester Nawrocki :
> Hi Chanwoo,
>
> On 01/21/2017 06:08 AM, Chanwoo Choi wrote:
>> I add reveiwed-by tag from this patch. But, on you tree, this patch[1] 
>> doesn’t
>> include the my reviewed-by tag.
>
> My apologies for this omission, I'll make sure I use patchwork in future
> so no tags are lost. It's already pulled and that commit can't be edited.

OK. Thanks for quick reply and explanation.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

[Chanwoo Choi]

Hi Sylwester,

2017-01-21 16:42 GMT+09:00 Sylwester Nawrocki :
> Hi Chanwoo,
>
> On 01/21/2017 06:08 AM, Chanwoo Choi wrote:
>> I add reveiwed-by tag from this patch. But, on you tree, this patch[1] 
>> doesn’t
>> include the my reviewed-by tag.
>
> My apologies for this omission, I'll make sure I use patchwork in future
> so no tags are lost. It's already pulled and that commit can't be edited.

OK. Thanks for quick reply and explanation.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

[Sylwester Nawrocki]

Hi Chanwoo,

On 01/21/2017 06:08 AM, Chanwoo Choi wrote:
> I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t
> include the my reviewed-by tag.

My apologies for this omission, I'll make sure I use patchwork in future
so no tags are lost. It's already pulled and that commit can't be edited.

-- 
Thanks,
Sylwester

Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

[Tetsuo Handa]

Tetsuo Handa wrote:
> And I think that there is a different problem if I tune a reproducer
> like below (i.e. increased the buffer size to write()/fsync() from 4096).
> 
> --
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
>   static char buffer[10485760] = { }; /* or 1048576 */
>   char *buf = NULL;
>   unsigned long size;
>   unsigned long i;
>   for (i = 0; i < 1024; i++) {
>   if (fork() == 0) {
>   int fd = open("/proc/self/oom_score_adj", O_WRONLY);
>   write(fd, "1000", 4);
>   close(fd);
>   sleep(1);
>   snprintf(buffer, sizeof(buffer), "/tmp/file.%u", 
> getpid());
>   fd = open(buffer, O_WRONLY | O_CREAT | O_APPEND, 0600);
>   while (write(fd, buffer, sizeof(buffer)) == 
> sizeof(buffer))
>   fsync(fd);
>   _exit(0);
>   }
>   }
>   for (size = 1048576; size < 512UL * (1 << 30); size <<= 1) {
>   char *cp = realloc(buf, size);
>   if (!cp) {
>   size >>= 1;
>   break;
>   }
>   buf = cp;
>   }
>   sleep(2);
>   /* Will cause OOM due to overcommit */
>   for (i = 0; i < size; i += 4096)
>   buf[i] = 0;
>   pause();
>   return 0;
> }
> --
> 
> Above reproducer sometimes kills all OOM killable processes and the system
> finally panics. I guess that somebody is abusing TIF_MEMDIE for needless
> allocations to the level where GFP_ATOMIC allocations start failing.

I tracked who is abusing TIF_MEMDIE using below patch.


diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ea088e1..d9ac53d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3038,7 +3038,7 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, 
const char *fmt, ...)
static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
  DEFAULT_RATELIMIT_BURST);
 
-   if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs) ||
+   if (1 || (gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs) ||
debug_guardpage_minorder() > 0)
return;
 
@@ -3573,6 +3573,7 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
int no_progress_loops = 0;
unsigned long alloc_start = jiffies;
unsigned int stall_timeout = 10 * HZ;
+   bool victim = false;
 
/*
 * In the slowpath, we sanity check order to avoid ever trying to
@@ -3656,8 +3657,10 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
if (gfp_mask & __GFP_KSWAPD_RECLAIM)
wake_all_kswapds(order, ac);
 
-   if (gfp_pfmemalloc_allowed(gfp_mask))
+   if (gfp_pfmemalloc_allowed(gfp_mask)) {
alloc_flags = ALLOC_NO_WATERMARKS;
+   victim = test_thread_flag(TIF_MEMDIE);
+   }
 
/*
 * Reset the zonelist iterators if memory policies can be ignored.
@@ -3790,6 +3793,11 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
warn_alloc(gfp_mask, ac->nodemask,
"page allocation failure: order:%u", order);
 got_pg:
+   if (page && victim) {
+   pr_warn("%s(%u): TIF_MEMDIE allocation: order=%d 
mode=%#x(%pGg)\n",
+   current->comm, current->pid, order, gfp_mask, 
_mask);
+   dump_stack();
+   }
return page;
 }
 


And I got flood of traces shown below. It seems to be consuming memory reserves
until the size passed to write() request is stored to the page cache even after
OOM-killed.

Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20170121.txt.xz .

[  202.306077] a.out(9789): TIF_MEMDIE allocation: order=0 
mode=0x1c2004a(GFP_NOFS|__GFP_HIGHMEM|__GFP_HARDWALL|__GFP_MOVABLE|__GFP_WRITE)
[  202.309832] CPU: 0 PID: 9789 Comm: a.out Not tainted 
4.10.0-rc4-next-20170120+ #492
[  202.312323] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/02/2015
[  202.315429] Call Trace:
[  202.316902]  dump_stack+0x85/0xc9
[  202.318810]  __alloc_pages_slowpath+0xa99/0xd7c
[  202.320697]  ? node_dirty_ok+0xef/0x130
[  202.322454]  __alloc_pages_nodemask+0x436/0x4d0
[  202.324506]  alloc_pages_current+0x97/0x1b0
[  202.326397]  __page_cache_alloc+0x15d/0x1a0  mm/filemap.c:728
[  202.328209]  pagecache_get_page+0x5a/0x2b0   mm/filemap.c:1331
[  202.329989]  gr

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

[Sylwester Nawrocki]

Hi Chanwoo,

On 01/21/2017 06:08 AM, Chanwoo Choi wrote:
> I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t
> include the my reviewed-by tag.

My apologies for this omission, I'll make sure I use patchwork in future
so no tags are lost. It's already pulled and that commit can't be edited.

-- 
Thanks,
Sylwester

Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone

[Tetsuo Handa]

Tetsuo Handa wrote:
> And I think that there is a different problem if I tune a reproducer
> like below (i.e. increased the buffer size to write()/fsync() from 4096).
> 
> --
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> 
> int main(int argc, char *argv[])
> {
>   static char buffer[10485760] = { }; /* or 1048576 */
>   char *buf = NULL;
>   unsigned long size;
>   unsigned long i;
>   for (i = 0; i < 1024; i++) {
>   if (fork() == 0) {
>   int fd = open("/proc/self/oom_score_adj", O_WRONLY);
>   write(fd, "1000", 4);
>   close(fd);
>   sleep(1);
>   snprintf(buffer, sizeof(buffer), "/tmp/file.%u", 
> getpid());
>   fd = open(buffer, O_WRONLY | O_CREAT | O_APPEND, 0600);
>   while (write(fd, buffer, sizeof(buffer)) == 
> sizeof(buffer))
>   fsync(fd);
>   _exit(0);
>   }
>   }
>   for (size = 1048576; size < 512UL * (1 << 30); size <<= 1) {
>   char *cp = realloc(buf, size);
>   if (!cp) {
>   size >>= 1;
>   break;
>   }
>   buf = cp;
>   }
>   sleep(2);
>   /* Will cause OOM due to overcommit */
>   for (i = 0; i < size; i += 4096)
>   buf[i] = 0;
>   pause();
>   return 0;
> }
> --
> 
> Above reproducer sometimes kills all OOM killable processes and the system
> finally panics. I guess that somebody is abusing TIF_MEMDIE for needless
> allocations to the level where GFP_ATOMIC allocations start failing.

I tracked who is abusing TIF_MEMDIE using below patch.


diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ea088e1..d9ac53d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3038,7 +3038,7 @@ void warn_alloc(gfp_t gfp_mask, nodemask_t *nodemask, 
const char *fmt, ...)
static DEFINE_RATELIMIT_STATE(nopage_rs, DEFAULT_RATELIMIT_INTERVAL,
  DEFAULT_RATELIMIT_BURST);
 
-   if ((gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs) ||
+   if (1 || (gfp_mask & __GFP_NOWARN) || !__ratelimit(_rs) ||
debug_guardpage_minorder() > 0)
return;
 
@@ -3573,6 +3573,7 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
int no_progress_loops = 0;
unsigned long alloc_start = jiffies;
unsigned int stall_timeout = 10 * HZ;
+   bool victim = false;
 
/*
 * In the slowpath, we sanity check order to avoid ever trying to
@@ -3656,8 +3657,10 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
if (gfp_mask & __GFP_KSWAPD_RECLAIM)
wake_all_kswapds(order, ac);
 
-   if (gfp_pfmemalloc_allowed(gfp_mask))
+   if (gfp_pfmemalloc_allowed(gfp_mask)) {
alloc_flags = ALLOC_NO_WATERMARKS;
+   victim = test_thread_flag(TIF_MEMDIE);
+   }
 
/*
 * Reset the zonelist iterators if memory policies can be ignored.
@@ -3790,6 +3793,11 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
warn_alloc(gfp_mask, ac->nodemask,
"page allocation failure: order:%u", order);
 got_pg:
+   if (page && victim) {
+   pr_warn("%s(%u): TIF_MEMDIE allocation: order=%d 
mode=%#x(%pGg)\n",
+   current->comm, current->pid, order, gfp_mask, 
_mask);
+   dump_stack();
+   }
return page;
 }
 


And I got flood of traces shown below. It seems to be consuming memory reserves
until the size passed to write() request is stored to the page cache even after
OOM-killed.

Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20170121.txt.xz .

[  202.306077] a.out(9789): TIF_MEMDIE allocation: order=0 
mode=0x1c2004a(GFP_NOFS|__GFP_HIGHMEM|__GFP_HARDWALL|__GFP_MOVABLE|__GFP_WRITE)
[  202.309832] CPU: 0 PID: 9789 Comm: a.out Not tainted 
4.10.0-rc4-next-20170120+ #492
[  202.312323] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/02/2015
[  202.315429] Call Trace:
[  202.316902]  dump_stack+0x85/0xc9
[  202.318810]  __alloc_pages_slowpath+0xa99/0xd7c
[  202.320697]  ? node_dirty_ok+0xef/0x130
[  202.322454]  __alloc_pages_nodemask+0x436/0x4d0
[  202.324506]  alloc_pages_current+0x97/0x1b0
[  202.326397]  __page_cache_alloc+0x15d/0x1a0  mm/filemap.c:728
[  202.328209]  pagecache_get_page+0x5a/0x2b0   mm/filemap.c:1331
[  202.329989]  gr

Re: [PATCH 07/12] PM / OPP: Update OPP users to put reference

[Chanwoo Choi]

Hi Viresh,

For devfreq part, Looks good to me.

Reviewed-by: Chanwoo Choi 


2016-12-08 13:00 GMT+09:00 Viresh Kumar :
> On 07-12-16, 22:23, Chanwoo Choi wrote:
>> I think that the dev_pm_opp_put(opp) should be called after if statement
>> If dev_pm_opp_find_freq_ceil() return error, I think the calling of
>> dev_pm_opp_put(opp) is not necessary.
>
> During development I had following check in dev_pm_opp_put():
>
> if (IS_ERR(opp))
> return;
>
> But that check isn't there anymore. And so it is also unsafe to call
> dev_pm_opp_put() for invalid OPP pointers.
>
> Thanks for reviewing this properly. devfreq_cooling.c also had the same issue
> which you missed. Here is the new version of the patch:
>
> -8<-
> Subject: [PATCH] PM / OPP: Update OPP users to put reference
>
> This patch updates dev_pm_opp_find_freq_*() routines to get a reference
> to the OPPs returned by them.
>
> Also updates the users of dev_pm_opp_find_freq_*() routines to call
> dev_pm_opp_put() after they are done using the OPPs.
>
> As it is guaranteed the that OPPs wouldn't get freed while being used,
> the RCU read side locking present with the users isn't required anymore.
> Drop it as well.
>
> This patch also updates all users of devfreq_recommended_opp() which was
> returning an OPP received from the OPP core.
>
> Note that some of the OPP core routines have gained
> rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs
> within them.
>
> Signed-off-by: Viresh Kumar 
> ---
>  arch/arm/mach-omap2/pm.c |   5 +-
>  drivers/base/power/opp/core.c| 114 
> +++
>  drivers/base/power/opp/cpu.c |  22 ++-
>  drivers/clk/tegra/clk-dfll.c |  17 ++
>  drivers/cpufreq/exynos5440-cpufreq.c |   5 +-
>  drivers/cpufreq/imx6q-cpufreq.c  |  10 +--
>  drivers/cpufreq/mt8173-cpufreq.c |   8 +--
>  drivers/cpufreq/omap-cpufreq.c   |   4 +-
>  drivers/devfreq/devfreq.c|  14 ++---
>  drivers/devfreq/exynos-bus.c |  14 ++---
>  drivers/devfreq/governor_passive.c   |   4 +-
>  drivers/devfreq/rk3399_dmc.c |  16 ++---
>  drivers/devfreq/tegra-devfreq.c  |   4 +-
>  drivers/thermal/cpu_cooling.c|  11 +---
>  drivers/thermal/devfreq_cooling.c|  15 ++---
>  15 files changed, 110 insertions(+), 153 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 678d2a31dcb8..c5a1d4439202 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -167,17 +167,16 @@ static int __init omap2_set_init_voltage(char 
> *vdd_name, char *clk_name,
> freq = clk_get_rate(clk);
> clk_put(clk);
>
> -   rcu_read_lock();
> opp = dev_pm_opp_find_freq_ceil(dev, );
> if (IS_ERR(opp)) {
> -   rcu_read_unlock();
> pr_err("%s: unable to find boot up OPP for vdd_%s\n",
> __func__, vdd_name);
> goto exit;
> }
>
> bootup_volt = dev_pm_opp_get_voltage(opp);
> -   rcu_read_unlock();
> +   dev_pm_opp_put(opp);
> +
> if (!bootup_volt) {
> pr_err("%s: unable to find voltage corresponding to the 
> bootup OPP for vdd_%s\n",
>__func__, vdd_name);
> diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> index 9870ee54d708..a6efa818029a 100644
> --- a/drivers/base/power/opp/core.c
> +++ b/drivers/base/power/opp/core.c
> @@ -40,6 +40,8 @@ do {
>   \
>  "opp_table_lock protection");  \
>  } while (0)
>
> +static void dev_pm_opp_get(struct dev_pm_opp *opp);
> +
>  static struct opp_device *_find_opp_dev(const struct device *dev,
> struct opp_table *opp_table)
>  {
> @@ -94,21 +96,13 @@ struct opp_table *_find_opp_table(struct device *dev)
>   * return 0
>   *
>   * This is useful only for devices with single power supply.
> - *
> - * Locking: This function must be called under rcu_read_lock(). opp is a rcu
> - * protected pointer. This means that opp which could have been fetched by
> - * opp_find_freq_{exact,ceil,floor} functions is valid as long as we are
> - * under RCU lock. The pointer returned by the opp_find_freq family must be
> - * used in the same section as the usage of this function with the pointer
> - * prior to unlocking with rcu_read_unlock() to maintain the integrity of the
> - * pointer.
>   */
>  unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
>  {
> struct dev_pm_opp *tmp_opp;
> unsigned long v = 0;
>
> -   opp_rcu_lockdep_assert();
> +   rcu_read_lock();
>
> tmp_opp = rcu_dereference(opp);
> if (IS_ERR_OR_NULL(tmp_opp))
> @@ -116,6 +110,7 @@ unsigned long 

Re: [PATCH 07/12] PM / OPP: Update OPP users to put reference

[Chanwoo Choi]

Hi Viresh,

For devfreq part, Looks good to me.

Reviewed-by: Chanwoo Choi 


2016-12-08 13:00 GMT+09:00 Viresh Kumar :
> On 07-12-16, 22:23, Chanwoo Choi wrote:
>> I think that the dev_pm_opp_put(opp) should be called after if statement
>> If dev_pm_opp_find_freq_ceil() return error, I think the calling of
>> dev_pm_opp_put(opp) is not necessary.
>
> During development I had following check in dev_pm_opp_put():
>
> if (IS_ERR(opp))
> return;
>
> But that check isn't there anymore. And so it is also unsafe to call
> dev_pm_opp_put() for invalid OPP pointers.
>
> Thanks for reviewing this properly. devfreq_cooling.c also had the same issue
> which you missed. Here is the new version of the patch:
>
> -8<-
> Subject: [PATCH] PM / OPP: Update OPP users to put reference
>
> This patch updates dev_pm_opp_find_freq_*() routines to get a reference
> to the OPPs returned by them.
>
> Also updates the users of dev_pm_opp_find_freq_*() routines to call
> dev_pm_opp_put() after they are done using the OPPs.
>
> As it is guaranteed the that OPPs wouldn't get freed while being used,
> the RCU read side locking present with the users isn't required anymore.
> Drop it as well.
>
> This patch also updates all users of devfreq_recommended_opp() which was
> returning an OPP received from the OPP core.
>
> Note that some of the OPP core routines have gained
> rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs
> within them.
>
> Signed-off-by: Viresh Kumar 
> ---
>  arch/arm/mach-omap2/pm.c |   5 +-
>  drivers/base/power/opp/core.c| 114 
> +++
>  drivers/base/power/opp/cpu.c |  22 ++-
>  drivers/clk/tegra/clk-dfll.c |  17 ++
>  drivers/cpufreq/exynos5440-cpufreq.c |   5 +-
>  drivers/cpufreq/imx6q-cpufreq.c  |  10 +--
>  drivers/cpufreq/mt8173-cpufreq.c |   8 +--
>  drivers/cpufreq/omap-cpufreq.c   |   4 +-
>  drivers/devfreq/devfreq.c|  14 ++---
>  drivers/devfreq/exynos-bus.c |  14 ++---
>  drivers/devfreq/governor_passive.c   |   4 +-
>  drivers/devfreq/rk3399_dmc.c |  16 ++---
>  drivers/devfreq/tegra-devfreq.c  |   4 +-
>  drivers/thermal/cpu_cooling.c|  11 +---
>  drivers/thermal/devfreq_cooling.c|  15 ++---
>  15 files changed, 110 insertions(+), 153 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 678d2a31dcb8..c5a1d4439202 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -167,17 +167,16 @@ static int __init omap2_set_init_voltage(char 
> *vdd_name, char *clk_name,
> freq = clk_get_rate(clk);
> clk_put(clk);
>
> -   rcu_read_lock();
> opp = dev_pm_opp_find_freq_ceil(dev, );
> if (IS_ERR(opp)) {
> -   rcu_read_unlock();
> pr_err("%s: unable to find boot up OPP for vdd_%s\n",
> __func__, vdd_name);
> goto exit;
> }
>
> bootup_volt = dev_pm_opp_get_voltage(opp);
> -   rcu_read_unlock();
> +   dev_pm_opp_put(opp);
> +
> if (!bootup_volt) {
> pr_err("%s: unable to find voltage corresponding to the 
> bootup OPP for vdd_%s\n",
>__func__, vdd_name);
> diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> index 9870ee54d708..a6efa818029a 100644
> --- a/drivers/base/power/opp/core.c
> +++ b/drivers/base/power/opp/core.c
> @@ -40,6 +40,8 @@ do {
>   \
>  "opp_table_lock protection");  \
>  } while (0)
>
> +static void dev_pm_opp_get(struct dev_pm_opp *opp);
> +
>  static struct opp_device *_find_opp_dev(const struct device *dev,
> struct opp_table *opp_table)
>  {
> @@ -94,21 +96,13 @@ struct opp_table *_find_opp_table(struct device *dev)
>   * return 0
>   *
>   * This is useful only for devices with single power supply.
> - *
> - * Locking: This function must be called under rcu_read_lock(). opp is a rcu
> - * protected pointer. This means that opp which could have been fetched by
> - * opp_find_freq_{exact,ceil,floor} functions is valid as long as we are
> - * under RCU lock. The pointer returned by the opp_find_freq family must be
> - * used in the same section as the usage of this function with the pointer
> - * prior to unlocking with rcu_read_unlock() to maintain the integrity of the
> - * pointer.
>   */
>  unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
>  {
> struct dev_pm_opp *tmp_opp;
> unsigned long v = 0;
>
> -   opp_rcu_lockdep_assert();
> +   rcu_read_lock();
>
> tmp_opp = rcu_dereference(opp);
> if (IS_ERR_OR_NULL(tmp_opp))
> @@ -116,6 +110,7 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp 
> *opp)
> else
>

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Finn Thain]

On Fri, 20 Jan 2017, Michael Schmitz wrote:

> Am 15.01.2017 um 17:42 schrieb Finn Thain:
> 
> >> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
> >> registers) without touching the ST-DMA. The moment we select a FDC or 
> >> SCSI register for read, DMA is terminated no questions asked.
> >>
> > 
> > Perhaps we can convert DMA operations to PDMA (by polling with local 
> > irqs disabled) and avoid the whole problem of interrupt handlers 
> > executing during DMA transfers. The docs suggest that it is doable.
> > 
> > "Poll or service the Disk Driver Controller interrupt on the MK68901 
> > MFP General Purpose I/O Register to detect the completion of a WD1772 
> > FDC command. Do not poll the FDC Busy or DMA Sector Count Zero status 
> > bits." -- ST HW Spec, p. 36. 
> > http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf
> 
> The MFP interrupt in question is the same as the one used by IDE 
> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out 
> where the interrupt originated.

I thought you said the driver you're testing does not use any interrupt -- 
I was assuming that only atari_scsi and ataflop drivers share the 
interupt.

> Polling instead of taking the interrupt does not change that fundamental 
> problem (unless I'm missing something).
> 

Actually, the fundamental problem you are describing is partly solved. By 
polling for DMA completion with local irqs disabled, we mostly avoid the 
need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can 
never interfere with a FDC/SCSI DMA process that might be underway.

> > 
> > On page 18 there is an algorithm for floppy writes which is 
> > interesting.
> 
> That one (and the ACSI algorithm which would apply to SCSI for Falcon) 
> does suggest it won't be possible to peek at the sector count register 
> to detect end of DMA. The addendum (note 841017G) makes it clear that a 
> write to the DMA mode register is required to look at the status 
> register error bit (which might terminate DMA).
> 
> Maybe the DMA address register can be used to check for DMA completion 
> ... it's used to check for residual or lost bytes anyway so that appears 
> to work. And the FDC driver does use the same strategy to check if 
> enough track data have been read.
> 
> Leaves the case where DMA hasn't completed but may have been aborted by 
> a NCR5380 interrupt. I suppose we can detect that by checking for any 
> change in the DMA address while repeatedly reading the DMA address 
> register. No change means the DMA has got stuck. Not exactly pretty but 
> all I can come up with.
> 

We don't have to poll any DMA registers (and I don't believe that it is 
viable to do so). I was talking about polling for end of DMA by polling 
for the interrupt (as per docs) but with local irqs disabled for the 
duration of the transfer (which provides exlusive access to the DMA chip).

> > 
> > I suspect that we will need to keep the FDC idle during SCSI transfers 
> > (and vice versa) much as the present stdma.c lock does.
> > 
> > "The interrupt outputs of the internal floppy disk controller and the 
> > external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP 
> > will read as a '0' if either the FDC or a selected ACSI device 
> > controller is asserting its interrupt request." -- ACSI/DMA 
> > Integration Guide, p.16. 
> > http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf
> 
> On Falcon, the IDE interrupt is also OR'ed to the above two interrupt 
> lines, hence the need for including IDE in the locking scheme there.
> 

I don't think the IDE/ATA driver needs to be included. atari_scsi and 
ataflop would though (if both drivers need DMA transfers).

> > 
> > Polling the logically OR'ed interrupt sources to detect end-of-DMA 
> > will not be reliable unless we disable those sources that aren't 
> > relevant. Otherwise we access the DMA registers too early (which IIUC 
> > would kill the transfer). I'm afraid we shall have to expect that a 
> > few transfers will be interrupted by other devices in this way, and 
> > carefully check for this.
> > 
> > For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> > could affect FDC transfers. If this terminated the polling for DMA 
> > completion, the FDC driver then has to access the FDC registers and 
> > confirm that the transfer was not terminated early.
> > 
> 
> We'll have to make sure FDC and SCSI don't clash in their DMA and 
> interrupt use.
> 

The point I was trying to make above is that stdma lock only gets you so 
far: if SCSI or FDC generate an interrupt that can't be disabled, it could 
mess up the interrupt polling (and the interrupt polling is a necessary 
consequence of IDE operating without stdma lock). This would lead to a 
short transfer (which could be easily detected).

So the chips clash in their interrupt line use (rarely). The drivers need 
not clash at all.

Anyway, we seem to be talking past each other 

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Finn Thain]

On Fri, 20 Jan 2017, Michael Schmitz wrote:

> Am 15.01.2017 um 17:42 schrieb Finn Thain:
> 
> >> No, we can't check either FDC or SCSI interrupts (or indeed any chip 
> >> registers) without touching the ST-DMA. The moment we select a FDC or 
> >> SCSI register for read, DMA is terminated no questions asked.
> >>
> > 
> > Perhaps we can convert DMA operations to PDMA (by polling with local 
> > irqs disabled) and avoid the whole problem of interrupt handlers 
> > executing during DMA transfers. The docs suggest that it is doable.
> > 
> > "Poll or service the Disk Driver Controller interrupt on the MK68901 
> > MFP General Purpose I/O Register to detect the completion of a WD1772 
> > FDC command. Do not poll the FDC Busy or DMA Sector Count Zero status 
> > bits." -- ST HW Spec, p. 36. 
> > http://dev-docs.atariforge.org/files/ST_HW_Spec_1-7-1986.pdf
> 
> The MFP interrupt in question is the same as the one used by IDE 
> (wired-OR of IDE, FDC and SCSI), so we would still have to figure out 
> where the interrupt originated.

I thought you said the driver you're testing does not use any interrupt -- 
I was assuming that only atari_scsi and ataflop drivers share the 
interupt.

> Polling instead of taking the interrupt does not change that fundamental 
> problem (unless I'm missing something).
> 

Actually, the fundamental problem you are describing is partly solved. By 
polling for DMA completion with local irqs disabled, we mostly avoid the 
need for the stdma.c "lock" because FDC/SCSI/IDE interrupt handlers can 
never interfere with a FDC/SCSI DMA process that might be underway.

> > 
> > On page 18 there is an algorithm for floppy writes which is 
> > interesting.
> 
> That one (and the ACSI algorithm which would apply to SCSI for Falcon) 
> does suggest it won't be possible to peek at the sector count register 
> to detect end of DMA. The addendum (note 841017G) makes it clear that a 
> write to the DMA mode register is required to look at the status 
> register error bit (which might terminate DMA).
> 
> Maybe the DMA address register can be used to check for DMA completion 
> ... it's used to check for residual or lost bytes anyway so that appears 
> to work. And the FDC driver does use the same strategy to check if 
> enough track data have been read.
> 
> Leaves the case where DMA hasn't completed but may have been aborted by 
> a NCR5380 interrupt. I suppose we can detect that by checking for any 
> change in the DMA address while repeatedly reading the DMA address 
> register. No change means the DMA has got stuck. Not exactly pretty but 
> all I can come up with.
> 

We don't have to poll any DMA registers (and I don't believe that it is 
viable to do so). I was talking about polling for end of DMA by polling 
for the interrupt (as per docs) but with local irqs disabled for the 
duration of the transfer (which provides exlusive access to the DMA chip).

> > 
> > I suspect that we will need to keep the FDC idle during SCSI transfers 
> > (and vice versa) much as the present stdma.c lock does.
> > 
> > "The interrupt outputs of the internal floppy disk controller and the 
> > external ACSI DMA port are logically OR'ed. The pin of the MFP GPIP 
> > will read as a '0' if either the FDC or a selected ACSI device 
> > controller is asserting its interrupt request." -- ACSI/DMA 
> > Integration Guide, p.16. 
> > http://dev-docs.atariforge.org/files/ACSI_DMA_Guide_6-28-1991.pdf
> 
> On Falcon, the IDE interrupt is also OR'ed to the above two interrupt 
> lines, hence the need for including IDE in the locking scheme there.
> 

I don't think the IDE/ATA driver needs to be included. atari_scsi and 
ataflop would though (if both drivers need DMA transfers).

> > 
> > Polling the logically OR'ed interrupt sources to detect end-of-DMA 
> > will not be reliable unless we disable those sources that aren't 
> > relevant. Otherwise we access the DMA registers too early (which IIUC 
> > would kill the transfer). I'm afraid we shall have to expect that a 
> > few transfers will be interrupted by other devices in this way, and 
> > carefully check for this.
> > 
> > For example, the 5380 SCSI bus reset interrupt is not maskable, which 
> > could affect FDC transfers. If this terminated the polling for DMA 
> > completion, the FDC driver then has to access the FDC registers and 
> > confirm that the transfer was not terminated early.
> > 
> 
> We'll have to make sure FDC and SCSI don't clash in their DMA and 
> interrupt use.
> 

The point I was trying to make above is that stdma lock only gets you so 
far: if SCSI or FDC generate an interrupt that can't be disabled, it could 
mess up the interrupt polling (and the interrupt polling is a necessary 
consequence of IDE operating without stdma lock). This would lead to a 
short transfer (which could be easily detected).

So the chips clash in their interrupt line use (rarely). The drivers need 
not clash at all.

Anyway, we seem to be talking past each other 

Re: [tip:timers/core] x86/timer: Make delay() during early bootup

[Jiri Slaby]

On 01/20/2017, 03:40 PM, tip-bot for Jiri Slaby wrote:
> Commit-ID:  bf3304d996fbb993bad6be09cafde39cc2db72bb
> Gitweb: http://git.kernel.org/tip/bf3304d996fbb993bad6be09cafde39cc2db72bb
> Author: Jiri Slaby 
> AuthorDate: Thu, 19 Jan 2017 12:47:30 +0100
> Committer:  Ingo Molnar 
> CommitDate: Fri, 20 Jan 2017 09:45:22 +0100
> 
> x86/timer: Make delay() during early bootup
> 
> When a panic happens during bootup, "Rebooting in X seconds.." is
> shown, but reboot happens immediatelly. It is because panic() uses mdelay()
> and mdelay() calls __const_udelay() immediately, which is does not
> work while booting.

The 'is' is superfluous after your edit now. But I guess, you cannot
change it given it is in the tree.

> --- a/arch/x86/lib/delay.c
> +++ b/arch/x86/lib/delay.c
> @@ -156,13 +156,13 @@ EXPORT_SYMBOL(__delay);
>  
>  inline void __const_udelay(unsigned long xloops)
>  {
> + unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : 
> loops_per_jiffy;

And thanks for fixing the 'lpf' brain damage :).

-- 
js
suse labs

Re: [tip:timers/core] x86/timer: Make delay() during early bootup

[Jiri Slaby]

On 01/20/2017, 03:40 PM, tip-bot for Jiri Slaby wrote:
> Commit-ID:  bf3304d996fbb993bad6be09cafde39cc2db72bb
> Gitweb: http://git.kernel.org/tip/bf3304d996fbb993bad6be09cafde39cc2db72bb
> Author: Jiri Slaby 
> AuthorDate: Thu, 19 Jan 2017 12:47:30 +0100
> Committer:  Ingo Molnar 
> CommitDate: Fri, 20 Jan 2017 09:45:22 +0100
> 
> x86/timer: Make delay() during early bootup
> 
> When a panic happens during bootup, "Rebooting in X seconds.." is
> shown, but reboot happens immediatelly. It is because panic() uses mdelay()
> and mdelay() calls __const_udelay() immediately, which is does not
> work while booting.

The 'is' is superfluous after your edit now. But I guess, you cannot
change it given it is in the tree.

> --- a/arch/x86/lib/delay.c
> +++ b/arch/x86/lib/delay.c
> @@ -156,13 +156,13 @@ EXPORT_SYMBOL(__delay);
>  
>  inline void __const_udelay(unsigned long xloops)
>  {
> + unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : 
> loops_per_jiffy;

And thanks for fixing the 'lpf' brain damage :).

-- 
js
suse labs

Re: BUG: rcu_sched detected stalls on CPUs

[mitko]

On 2017-01-20 17:19, Steven Rostedt wrote:

On Fri, 20 Jan 2017 10:43:50 +0200
mi...@stz-bg.com wrote:


[1.] One line summary of the problem:

rcu_sched detected stalls on CPUs and few minutes server not respond.


Is this reproducible? Or was this a one time ordeal?


It's happened usual once per day and can't be reproducible. If server 
load average is more then

0.70 it's will happened twice per day.





[2.] Full description of the problem/report:

Load of my server (postgres database) isnt big less then 0.50 and when
error occured rcu_sched detected stalls on CPUs
server freeze and nothing is work for 3-5 minute.
No network, no video signal, no keyboard, no mouse. Nothing is worked.
After these few minutes everything continue normal.
This usual is happend once per day. When I check in google find a lots
of ppl complain of this error, but no solution.
Do any one know can help me to resolve it ? I spoke with few friends 
and

they trying to convince me the problem is in CPU.
I did not believe after a 3 years working CPU suddenly stop working
correctly, but I might be wrong.

[3.] Keywords (i.e., modules, networking, kernel):

kernel

[4.] Kernel information
[4.1.] Kernel version (from /proc/version):

Linux version 4.4.38 (root@hive64) (gcc version 5.4.0 (GCC) ) #2 SMP 
Sun

Dec 11 16:11:02 CST 2016



Have you tried a newer version of the kernel?


No, for the moment I didnt because I can't find new one in slackware 
repos.
My last kernel compile was almost 7 years ago and I do not feel safe 
now, I guess a lot of things have changed.





-- Steve


Regards,
Mitko

Re: BUG: rcu_sched detected stalls on CPUs

[mitko]

On 2017-01-20 17:19, Steven Rostedt wrote:

On Fri, 20 Jan 2017 10:43:50 +0200
mi...@stz-bg.com wrote:


[1.] One line summary of the problem:

rcu_sched detected stalls on CPUs and few minutes server not respond.


Is this reproducible? Or was this a one time ordeal?


It's happened usual once per day and can't be reproducible. If server 
load average is more then

0.70 it's will happened twice per day.





[2.] Full description of the problem/report:

Load of my server (postgres database) isnt big less then 0.50 and when
error occured rcu_sched detected stalls on CPUs
server freeze and nothing is work for 3-5 minute.
No network, no video signal, no keyboard, no mouse. Nothing is worked.
After these few minutes everything continue normal.
This usual is happend once per day. When I check in google find a lots
of ppl complain of this error, but no solution.
Do any one know can help me to resolve it ? I spoke with few friends 
and

they trying to convince me the problem is in CPU.
I did not believe after a 3 years working CPU suddenly stop working
correctly, but I might be wrong.

[3.] Keywords (i.e., modules, networking, kernel):

kernel

[4.] Kernel information
[4.1.] Kernel version (from /proc/version):

Linux version 4.4.38 (root@hive64) (gcc version 5.4.0 (GCC) ) #2 SMP 
Sun

Dec 11 16:11:02 CST 2016



Have you tried a newer version of the kernel?


No, for the moment I didnt because I can't find new one in slackware 
repos.
My last kernel compile was almost 7 years ago and I do not feel safe 
now, I guess a lot of things have changed.





-- Steve


Regards,
Mitko

Re: [PATCH v2] jump_label: reduce the size of struct static_key

[Ingo Molnar]

* Jason Baron  wrote:

> >For example the last line could sure be written as:
> >
> > key->entries = jlm->entries;
> > key->type |= static_key_type(key);
> >
> >right?
> 
> Hi,
> 
> So that is going to over-write the static_key_type(key) in the first
> assignment. If the order is reversed we can't just |= in the pointer type.

Indeed, I missed that.

> How about:
> 
> static void jump_key_set_entries(struct static_key *key, struct jump_entry 
> *entries)
> {
>unsigned long type;
> 
>type = static_key_type(key);
>key->entries = entries;
>key->type |= type;
> }
> 
> and then we can also add:
> 
> void jump_key_set_mod(struct static_key *key, struct static_key_mod *mod)
> 
> doing basically the same thing. That will avoid the casts that you called
> out.
> 
> better?

Yeah - and it should generate the exact same code, right?

I'd also add a short comment to the helper function that points out the 
union/aliasing, in case anyone is wondering.

Thanks,

Ingo

Re: [PATCH v2] jump_label: reduce the size of struct static_key

[Ingo Molnar]

* Jason Baron  wrote:

> >For example the last line could sure be written as:
> >
> > key->entries = jlm->entries;
> > key->type |= static_key_type(key);
> >
> >right?
> 
> Hi,
> 
> So that is going to over-write the static_key_type(key) in the first
> assignment. If the order is reversed we can't just |= in the pointer type.

Indeed, I missed that.

> How about:
> 
> static void jump_key_set_entries(struct static_key *key, struct jump_entry 
> *entries)
> {
>unsigned long type;
> 
>type = static_key_type(key);
>key->entries = entries;
>key->type |= type;
> }
> 
> and then we can also add:
> 
> void jump_key_set_mod(struct static_key *key, struct static_key_mod *mod)
> 
> doing basically the same thing. That will avoid the casts that you called
> out.
> 
> better?

Yeah - and it should generate the exact same code, right?

I'd also add a short comment to the helper function that points out the 
union/aliasing, in case anyone is wondering.

Thanks,

Ingo

[PATCH v2] net: xilinx: constify net_device_ops structure

[Bhumika Goyal]

Declare net_device_ops structure as const as it is only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   6201 744   069451b21 ethernet/xilinx/xilinx_emaclite.o

File size after:
   textdata bss dec hex filename
   6745 192   069371b19 ethernet/xilinx/xilinx_emaclite.o

Signed-off-by: Bhumika Goyal 
---
Changes in v2:
* Corrected the commit message.

 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c 
b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 93dc10b..546f569 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1065,7 +1065,7 @@ static bool get_bool(struct platform_device *ofdev, const 
char *s)
}
 }
 
-static struct net_device_ops xemaclite_netdev_ops;
+static const struct net_device_ops xemaclite_netdev_ops;
 
 /**
  * xemaclite_of_probe - Probe method for the Emaclite device.
@@ -1219,7 +1219,7 @@ static int xemaclite_of_remove(struct platform_device 
*of_dev)
 }
 #endif
 
-static struct net_device_ops xemaclite_netdev_ops = {
+static const struct net_device_ops xemaclite_netdev_ops = {
.ndo_open   = xemaclite_open,
.ndo_stop   = xemaclite_close,
.ndo_start_xmit = xemaclite_send,
-- 
1.9.1

[PATCH v2] net: xilinx: constify net_device_ops structure

[Bhumika Goyal]

Declare net_device_ops structure as const as it is only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   6201 744   069451b21 ethernet/xilinx/xilinx_emaclite.o

File size after:
   textdata bss dec hex filename
   6745 192   069371b19 ethernet/xilinx/xilinx_emaclite.o

Signed-off-by: Bhumika Goyal 
---
Changes in v2:
* Corrected the commit message.

 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c 
b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 93dc10b..546f569 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1065,7 +1065,7 @@ static bool get_bool(struct platform_device *ofdev, const 
char *s)
}
 }
 
-static struct net_device_ops xemaclite_netdev_ops;
+static const struct net_device_ops xemaclite_netdev_ops;
 
 /**
  * xemaclite_of_probe - Probe method for the Emaclite device.
@@ -1219,7 +1219,7 @@ static int xemaclite_of_remove(struct platform_device 
*of_dev)
 }
 #endif
 
-static struct net_device_ops xemaclite_netdev_ops = {
+static const struct net_device_ops xemaclite_netdev_ops = {
.ndo_open   = xemaclite_open,
.ndo_stop   = xemaclite_close,
.ndo_start_xmit = xemaclite_send,
-- 
1.9.1

[PATCH v2] net: moxa: constify net_device_ops structures

[Bhumika Goyal]

Declare net_device_ops structure as const as it is only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   4821 744   0556515bd ethernet/moxa/moxart_ether.o

File size after:
   textdata bss dec hex filename
   5373 192   0556515bd ethernet/moxa/moxart_ether.o

Signed-off-by: Bhumika Goyal 
---
Changes in v2:
* Corrected the commit message.

 drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/moxa/moxart_ether.c 
b/drivers/net/ethernet/moxa/moxart_ether.c
index 9774b50..6a6525f 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -436,7 +436,7 @@ static void moxart_mac_set_rx_mode(struct net_device *ndev)
spin_unlock_irq(>txlock);
 }
 
-static struct net_device_ops moxart_netdev_ops = {
+static const struct net_device_ops moxart_netdev_ops = {
.ndo_open   = moxart_mac_open,
.ndo_stop   = moxart_mac_stop,
.ndo_start_xmit = moxart_mac_start_xmit,
-- 
1.9.1

[PATCH v2] net: moxa: constify net_device_ops structures

[Bhumika Goyal]

Declare net_device_ops structure as const as it is only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   4821 744   0556515bd ethernet/moxa/moxart_ether.o

File size after:
   textdata bss dec hex filename
   5373 192   0556515bd ethernet/moxa/moxart_ether.o

Signed-off-by: Bhumika Goyal 
---
Changes in v2:
* Corrected the commit message.

 drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/moxa/moxart_ether.c 
b/drivers/net/ethernet/moxa/moxart_ether.c
index 9774b50..6a6525f 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -436,7 +436,7 @@ static void moxart_mac_set_rx_mode(struct net_device *ndev)
spin_unlock_irq(>txlock);
 }
 
-static struct net_device_ops moxart_netdev_ops = {
+static const struct net_device_ops moxart_netdev_ops = {
.ndo_open   = moxart_mac_open,
.ndo_stop   = moxart_mac_stop,
.ndo_start_xmit = moxart_mac_start_xmit,
-- 
1.9.1

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

[kbuild test robot]

Hi Markus,

[auto build test ERROR on next-20170119]
[also build test ERROR on v4.10-rc4]
[cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/PowerPC-KVM-Fine-tuning-for-some-function-implementations/20170121-121537
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/book3s_xics.c: In function 'kvmppc_xics_create_ics':
   arch/powerpc/kvm/book3s_xics.c:1035:16: error: incompatible type for 
argument 1 of 'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: expected 'size_t {aka long unsigned int}' 
but argument is of type 'struct kvmppc_ics'
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
   arch/powerpc/kvm/book3s_xics.c:1035:8: error: too few arguments to function 
'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^~~
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: declared here
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
>> arch/powerpc/kvm/book3s_xics.c:1035:21: error: left-hand operand of comma 
>> expression has no effect [-Werror=unused-value]
 ics = kzalloc(*ics), GFP_KERNEL);
^
>> arch/powerpc/kvm/book3s_xics.c:1035:21: error: statement with no effect 
>> [-Werror=unused-value]
   arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected ';' before ')' token
 ics = kzalloc(*ics), GFP_KERNEL);
^
   arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected statement before ')' 
token
   cc1: all warnings being treated as errors

vim +1035 arch/powerpc/kvm/book3s_xics.c

  1029  
  1030  /* ICS already exists - somebody else got here first */
  1031  if (xics->ics[icsid])
  1032  goto out;
  1033  
  1034  /* Create the ICS */
> 1035  ics = kzalloc(*ics), GFP_KERNEL);
  1036  if (!ics)
  1037  goto out;
  1038  

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


.config.gz
Description: application/gzip

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

[kbuild test robot]

Hi Markus,

[auto build test ERROR on next-20170119]
[also build test ERROR on v4.10-rc4]
[cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/PowerPC-KVM-Fine-tuning-for-some-function-implementations/20170121-121537
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/book3s_xics.c: In function 'kvmppc_xics_create_ics':
   arch/powerpc/kvm/book3s_xics.c:1035:16: error: incompatible type for 
argument 1 of 'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: expected 'size_t {aka long unsigned int}' 
but argument is of type 'struct kvmppc_ics'
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
   arch/powerpc/kvm/book3s_xics.c:1035:8: error: too few arguments to function 
'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^~~
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: declared here
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
>> arch/powerpc/kvm/book3s_xics.c:1035:21: error: left-hand operand of comma 
>> expression has no effect [-Werror=unused-value]
 ics = kzalloc(*ics), GFP_KERNEL);
^
>> arch/powerpc/kvm/book3s_xics.c:1035:21: error: statement with no effect 
>> [-Werror=unused-value]
   arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected ';' before ')' token
 ics = kzalloc(*ics), GFP_KERNEL);
^
   arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected statement before ')' 
token
   cc1: all warnings being treated as errors

vim +1035 arch/powerpc/kvm/book3s_xics.c

  1029  
  1030  /* ICS already exists - somebody else got here first */
  1031  if (xics->ics[icsid])
  1032  goto out;
  1033  
  1034  /* Create the ICS */
> 1035  ics = kzalloc(*ics), GFP_KERNEL);
  1036  if (!ics)
  1037  goto out;
  1038  

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

[Theodore Ts'o]

On Sat, Jan 21, 2017 at 01:16:56AM +0100, Jason A. Donenfeld wrote:
> On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o  wrote:
> > But there is a shared pointer, which is used both for the dedicated
> > u32 array and the dedicated u64 array.  So when you increment the
> > pointer for the get_random_u32, the corresponding entry in the u64
> > array is wasted, no?
> 
> No, it is not a shared pointer. It is a different pointer with a
> different batch. The idea is that each function gets its own batch.
> That way there's always perfect alignment. This is why I'm suggesting
> that my approach is faster.

Oh, I see.  What was confusing me was that you used the same data
structure for both, and but you were using different instances of the
structure for get_random_u32 and get_random_u64.  I thought you were
using the same batched_entropy structure for both.  My bad.

I probably would have used different structure definitions for both,
but that's probably because I really am not fund of unions at all if
they can be avoided.  I thought you were using a union because you
were deliberately trying to use one instance of the structure as a per
cpu variable for u32 and u64.

So that's not how I would do things, but it's fine.

- Ted

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

[Theodore Ts'o]

On Sat, Jan 21, 2017 at 01:16:56AM +0100, Jason A. Donenfeld wrote:
> On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o  wrote:
> > But there is a shared pointer, which is used both for the dedicated
> > u32 array and the dedicated u64 array.  So when you increment the
> > pointer for the get_random_u32, the corresponding entry in the u64
> > array is wasted, no?
> 
> No, it is not a shared pointer. It is a different pointer with a
> different batch. The idea is that each function gets its own batch.
> That way there's always perfect alignment. This is why I'm suggesting
> that my approach is faster.

Oh, I see.  What was confusing me was that you used the same data
structure for both, and but you were using different instances of the
structure for get_random_u32 and get_random_u64.  I thought you were
using the same batched_entropy structure for both.  My bad.

I probably would have used different structure definitions for both,
but that's probably because I really am not fund of unions at all if
they can be avoided.  I thought you were using a union because you
were deliberately trying to use one instance of the structure as a per
cpu variable for u32 and u64.

So that's not how I would do things, but it's fine.

- Ted

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

[kbuild test robot]

Hi Markus,

[auto build test ERROR on next-20170119]
[also build test ERROR on v4.10-rc4]
[cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/PowerPC-KVM-Fine-tuning-for-some-function-implementations/20170121-121537
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/book3s_xics.c: In function 'kvmppc_xics_create_ics':
>> arch/powerpc/kvm/book3s_xics.c:1035:16: error: incompatible type for 
>> argument 1 of 'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: expected 'size_t {aka long unsigned int}' 
but argument is of type 'struct kvmppc_ics'
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
>> arch/powerpc/kvm/book3s_xics.c:1035:8: error: too few arguments to function 
>> 'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^~~
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: declared here
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
   arch/powerpc/kvm/book3s_xics.c:1035:21: warning: left-hand operand of comma 
expression has no effect [-Wunused-value]
 ics = kzalloc(*ics), GFP_KERNEL);
^
   arch/powerpc/kvm/book3s_xics.c:1035:21: warning: statement with no effect 
[-Wunused-value]
>> arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected ';' before ')' token
 ics = kzalloc(*ics), GFP_KERNEL);
^
>> arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected statement before ')' 
>> token

vim +/kzalloc +1035 arch/powerpc/kvm/book3s_xics.c

  1029  
  1030  /* ICS already exists - somebody else got here first */
  1031  if (xics->ics[icsid])
  1032  goto out;
  1033  
  1034  /* Create the ICS */
> 1035  ics = kzalloc(*ics), GFP_KERNEL);
  1036  if (!ics)
  1037  goto out;
  1038  

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


.config.gz
Description: application/gzip

Re: [PATCH 09/11] KVM: PPC: Book3S: Improve a size determination in two functions

[kbuild test robot]

Hi Markus,

[auto build test ERROR on next-20170119]
[also build test ERROR on v4.10-rc4]
[cannot apply to v4.9-rc8 v4.9-rc7 v4.9-rc6]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/SF-Markus-Elfring/PowerPC-KVM-Fine-tuning-for-some-function-implementations/20170121-121537
config: powerpc-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

All errors (new ones prefixed by >>):

   arch/powerpc/kvm/book3s_xics.c: In function 'kvmppc_xics_create_ics':
>> arch/powerpc/kvm/book3s_xics.c:1035:16: error: incompatible type for 
>> argument 1 of 'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: expected 'size_t {aka long unsigned int}' 
but argument is of type 'struct kvmppc_ics'
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
>> arch/powerpc/kvm/book3s_xics.c:1035:8: error: too few arguments to function 
>> 'kzalloc'
 ics = kzalloc(*ics), GFP_KERNEL);
   ^~~
   In file included from include/linux/kvm_host.h:21:0,
from arch/powerpc/kvm/book3s_xics.c:11:
   include/linux/slab.h:634:21: note: declared here
static inline void *kzalloc(size_t size, gfp_t flags)
^~~
   arch/powerpc/kvm/book3s_xics.c:1035:21: warning: left-hand operand of comma 
expression has no effect [-Wunused-value]
 ics = kzalloc(*ics), GFP_KERNEL);
^
   arch/powerpc/kvm/book3s_xics.c:1035:21: warning: statement with no effect 
[-Wunused-value]
>> arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected ';' before ')' token
 ics = kzalloc(*ics), GFP_KERNEL);
^
>> arch/powerpc/kvm/book3s_xics.c:1035:33: error: expected statement before ')' 
>> token

vim +/kzalloc +1035 arch/powerpc/kvm/book3s_xics.c

  1029  
  1030  /* ICS already exists - somebody else got here first */
  1031  if (xics->ics[icsid])
  1032  goto out;
  1033  
  1034  /* Create the ICS */
> 1035  ics = kzalloc(*ics), GFP_KERNEL);
  1036  if (!ics)
  1037  goto out;
  1038  

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


.config.gz
Description: application/gzip

Re: [PATCH] omit POSIX timer stuff from task_struct when disabled

[Nicolas Pitre]

On Fri, 20 Jan 2017, John Stultz wrote:

> On Fri, Jan 20, 2017 at 2:46 PM, Nicolas Pitre  
> wrote:
> > Just tell me if you prefer that I respin the patch and I'll do it.
> 
> Yea. I'm not so finicky but I'm sure I'll probably get yelled at if I
> pass it on, so if you don't mind respinning it, I'll get it applied
> for testing here quickly :)

There you go.

- >8
Subject: omit POSIX timer stuff from task_struct when disabled

When CONFIG_POSIX_TIMERS is disabled, it is preferable to remove related
structures from struct task_struct and struct signal_struct as they
won't contain anything useful and shouldn't be relied upon by mistake.
Code still referencing those structures is also disabled here.

Signed-off-by: Nicolas Pitre 

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8e7e61b28f..03deeac1e8 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2179,7 +2179,7 @@ static const struct file_operations 
proc_map_files_operations = {
.llseek = generic_file_llseek,
 };
 
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#if defined(CONFIG_CHECKPOINT_RESTORE) && defined(CONFIG_POSIX_TIMERS)
 struct timers_private {
struct pid *pid;
struct task_struct *task;
@@ -2936,7 +2936,7 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("projid_map", S_IRUGO|S_IWUSR, proc_projid_map_operations),
REG("setgroups",  S_IRUGO|S_IWUSR, proc_setgroups_operations),
 #endif
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#if defined(CONFIG_CHECKPOINT_RESTORE) && defined(CONFIG_POSIX_TIMERS)
REG("timers", S_IRUGO, proc_timers_operations),
 #endif
REG("timerslack_ns", S_IRUGO|S_IWUGO, 
proc_pid_set_timerslack_ns_operations),
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 325f649d77..3a85d61f76 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -42,6 +42,27 @@ extern struct fs_struct init_fs;
 #define INIT_PREV_CPUTIME(x)
 #endif
 
+#ifdef CONFIG_POSIX_TIMERS
+#define INIT_POSIX_TIMERS(s)   \
+   .posix_timers = LIST_HEAD_INIT(s.posix_timers),
+#define INIT_CPU_TIMERS(s) \
+   .cpu_timers = { \
+   LIST_HEAD_INIT(s.cpu_timers[0]),\
+   LIST_HEAD_INIT(s.cpu_timers[1]),\
+   LIST_HEAD_INIT(s.cpu_timers[2]),
\
+   },
+#define INIT_CPUTIMER(s)   \
+   .cputimer   = { \
+   .cputime_atomic = INIT_CPUTIME_ATOMIC,  \
+   .running= false,\
+   .checking_timer = false,\
+   },
+#else
+#define INIT_POSIX_TIMERS(s)
+#define INIT_CPU_TIMERS(s)
+#define INIT_CPUTIMER(s)
+#endif
+
 #define INIT_SIGNALS(sig) {\
.nr_threads = 1,\
.thread_head= LIST_HEAD_INIT(init_task.thread_node),\
@@ -49,14 +70,10 @@ extern struct fs_struct init_fs;
.shared_pending = { \
.list = LIST_HEAD_INIT(sig.shared_pending.list),\
.signal =  {{0}}},  \
-   .posix_timers= LIST_HEAD_INIT(sig.posix_timers),\
-   .cpu_timers = INIT_CPU_TIMERS(sig.cpu_timers),  \
+   INIT_POSIX_TIMERS(sig)  \
+   INIT_CPU_TIMERS(sig)\
.rlim   = INIT_RLIMITS, \
-   .cputimer   = { \
-   .cputime_atomic = INIT_CPUTIME_ATOMIC,  \
-   .running= false,\
-   .checking_timer = false,\
-   },  \
+   INIT_CPUTIMER(sig)  \
INIT_PREV_CPUTIME(sig)  \
.cred_guard_mutex = \
 __MUTEX_INITIALIZER(sig.cred_guard_mutex), \
@@ -247,7 +264,7 @@ extern struct task_group root_task_group;
.blocked= {{0}},\
.alloc_lock = __SPIN_LOCK_UNLOCKED(tsk.alloc_lock), \
.journal_info   = NULL, \
-   .cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers),  \
+   INIT_CPU_TIMERS(tsk)

Re: [PATCH] omit POSIX timer stuff from task_struct when disabled

[Nicolas Pitre]

On Fri, 20 Jan 2017, John Stultz wrote:

> On Fri, Jan 20, 2017 at 2:46 PM, Nicolas Pitre  
> wrote:
> > Just tell me if you prefer that I respin the patch and I'll do it.
> 
> Yea. I'm not so finicky but I'm sure I'll probably get yelled at if I
> pass it on, so if you don't mind respinning it, I'll get it applied
> for testing here quickly :)

There you go.

- >8
Subject: omit POSIX timer stuff from task_struct when disabled

When CONFIG_POSIX_TIMERS is disabled, it is preferable to remove related
structures from struct task_struct and struct signal_struct as they
won't contain anything useful and shouldn't be relied upon by mistake.
Code still referencing those structures is also disabled here.

Signed-off-by: Nicolas Pitre 

diff --git a/fs/proc/base.c b/fs/proc/base.c
index 8e7e61b28f..03deeac1e8 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -2179,7 +2179,7 @@ static const struct file_operations 
proc_map_files_operations = {
.llseek = generic_file_llseek,
 };
 
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#if defined(CONFIG_CHECKPOINT_RESTORE) && defined(CONFIG_POSIX_TIMERS)
 struct timers_private {
struct pid *pid;
struct task_struct *task;
@@ -2936,7 +2936,7 @@ static const struct pid_entry tgid_base_stuff[] = {
REG("projid_map", S_IRUGO|S_IWUSR, proc_projid_map_operations),
REG("setgroups",  S_IRUGO|S_IWUSR, proc_setgroups_operations),
 #endif
-#ifdef CONFIG_CHECKPOINT_RESTORE
+#if defined(CONFIG_CHECKPOINT_RESTORE) && defined(CONFIG_POSIX_TIMERS)
REG("timers", S_IRUGO, proc_timers_operations),
 #endif
REG("timerslack_ns", S_IRUGO|S_IWUGO, 
proc_pid_set_timerslack_ns_operations),
diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 325f649d77..3a85d61f76 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -42,6 +42,27 @@ extern struct fs_struct init_fs;
 #define INIT_PREV_CPUTIME(x)
 #endif
 
+#ifdef CONFIG_POSIX_TIMERS
+#define INIT_POSIX_TIMERS(s)   \
+   .posix_timers = LIST_HEAD_INIT(s.posix_timers),
+#define INIT_CPU_TIMERS(s) \
+   .cpu_timers = { \
+   LIST_HEAD_INIT(s.cpu_timers[0]),\
+   LIST_HEAD_INIT(s.cpu_timers[1]),\
+   LIST_HEAD_INIT(s.cpu_timers[2]),
\
+   },
+#define INIT_CPUTIMER(s)   \
+   .cputimer   = { \
+   .cputime_atomic = INIT_CPUTIME_ATOMIC,  \
+   .running= false,\
+   .checking_timer = false,\
+   },
+#else
+#define INIT_POSIX_TIMERS(s)
+#define INIT_CPU_TIMERS(s)
+#define INIT_CPUTIMER(s)
+#endif
+
 #define INIT_SIGNALS(sig) {\
.nr_threads = 1,\
.thread_head= LIST_HEAD_INIT(init_task.thread_node),\
@@ -49,14 +70,10 @@ extern struct fs_struct init_fs;
.shared_pending = { \
.list = LIST_HEAD_INIT(sig.shared_pending.list),\
.signal =  {{0}}},  \
-   .posix_timers= LIST_HEAD_INIT(sig.posix_timers),\
-   .cpu_timers = INIT_CPU_TIMERS(sig.cpu_timers),  \
+   INIT_POSIX_TIMERS(sig)  \
+   INIT_CPU_TIMERS(sig)\
.rlim   = INIT_RLIMITS, \
-   .cputimer   = { \
-   .cputime_atomic = INIT_CPUTIME_ATOMIC,  \
-   .running= false,\
-   .checking_timer = false,\
-   },  \
+   INIT_CPUTIMER(sig)  \
INIT_PREV_CPUTIME(sig)  \
.cred_guard_mutex = \
 __MUTEX_INITIALIZER(sig.cred_guard_mutex), \
@@ -247,7 +264,7 @@ extern struct task_group root_task_group;
.blocked= {{0}},\
.alloc_lock = __SPIN_LOCK_UNLOCKED(tsk.alloc_lock), \
.journal_info   = NULL, \
-   .cpu_timers = INIT_CPU_TIMERS(tsk.cpu_timers),  \
+   INIT_CPU_TIMERS(tsk)\
.pi_lock= 

[PATCH] net: moxa: constify net_device_ops structures

[Bhumika Goyal]

Declare net_device_ops structures as const as they are only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   4821 744   0556515bd ethernet/moxa/moxart_ether.o

File size after:
   textdata bss dec hex filename
   5373 192   0556515bd ethernet/moxa/moxart_ether.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/moxa/moxart_ether.c 
b/drivers/net/ethernet/moxa/moxart_ether.c
index 9774b50..6a6525f 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -436,7 +436,7 @@ static void moxart_mac_set_rx_mode(struct net_device *ndev)
spin_unlock_irq(>txlock);
 }
 
-static struct net_device_ops moxart_netdev_ops = {
+static const struct net_device_ops moxart_netdev_ops = {
.ndo_open   = moxart_mac_open,
.ndo_stop   = moxart_mac_stop,
.ndo_start_xmit = moxart_mac_start_xmit,
-- 
1.9.1

[PATCH] net: moxa: constify net_device_ops structures

[Bhumika Goyal]

Declare net_device_ops structures as const as they are only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   4821 744   0556515bd ethernet/moxa/moxart_ether.o

File size after:
   textdata bss dec hex filename
   5373 192   0556515bd ethernet/moxa/moxart_ether.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/moxa/moxart_ether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/moxa/moxart_ether.c 
b/drivers/net/ethernet/moxa/moxart_ether.c
index 9774b50..6a6525f 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -436,7 +436,7 @@ static void moxart_mac_set_rx_mode(struct net_device *ndev)
spin_unlock_irq(>txlock);
 }
 
-static struct net_device_ops moxart_netdev_ops = {
+static const struct net_device_ops moxart_netdev_ops = {
.ndo_open   = moxart_mac_open,
.ndo_stop   = moxart_mac_stop,
.ndo_start_xmit = moxart_mac_start_xmit,
-- 
1.9.1

[PATCH] net: xilinx: constify net_device_ops structures

[Bhumika Goyal]

Declare net_device_ops structures as const as they are only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   6201 744   069451b21 ethernet/xilinx/xilinx_emaclite.o

File size after:
   textdata bss dec hex filename
   6745 192   069371b19 ethernet/xilinx/xilinx_emaclite.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c 
b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 93dc10b..546f569 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1065,7 +1065,7 @@ static bool get_bool(struct platform_device *ofdev, const 
char *s)
}
 }
 
-static struct net_device_ops xemaclite_netdev_ops;
+static const struct net_device_ops xemaclite_netdev_ops;
 
 /**
  * xemaclite_of_probe - Probe method for the Emaclite device.
@@ -1219,7 +1219,7 @@ static int xemaclite_of_remove(struct platform_device 
*of_dev)
 }
 #endif
 
-static struct net_device_ops xemaclite_netdev_ops = {
+static const struct net_device_ops xemaclite_netdev_ops = {
.ndo_open   = xemaclite_open,
.ndo_stop   = xemaclite_close,
.ndo_start_xmit = xemaclite_send,
-- 
1.9.1

[PATCH] net: xilinx: constify net_device_ops structures

[Bhumika Goyal]

Declare net_device_ops structures as const as they are only stored in
the netdev_ops field of a net_device structure. This field is of type
const, so net_device_ops structures having same properties can be made
const too.
Done using Coccinelle:

@r1 disable optional_qualifier@
identifier i;
position p;
@@
static struct net_device_ops i@p={...};

@ok1@
identifier r1.i;
position p;
struct net_device ndev;
@@
ndev.netdev_ops=@p

@bad@
position p!={r1.p,ok1.p};
identifier r1.i;
@@
i@p

@depends on !bad disable optional_qualifier@
identifier r1.i;
@@
+const
struct net_device_ops i;

File size before:
   textdata bss dec hex filename
   6201 744   069451b21 ethernet/xilinx/xilinx_emaclite.o

File size after:
   textdata bss dec hex filename
   6745 192   069371b19 ethernet/xilinx/xilinx_emaclite.o

Signed-off-by: Bhumika Goyal 
---
 drivers/net/ethernet/xilinx/xilinx_emaclite.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c 
b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
index 93dc10b..546f569 100644
--- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
+++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
@@ -1065,7 +1065,7 @@ static bool get_bool(struct platform_device *ofdev, const 
char *s)
}
 }
 
-static struct net_device_ops xemaclite_netdev_ops;
+static const struct net_device_ops xemaclite_netdev_ops;
 
 /**
  * xemaclite_of_probe - Probe method for the Emaclite device.
@@ -1219,7 +1219,7 @@ static int xemaclite_of_remove(struct platform_device 
*of_dev)
 }
 #endif
 
-static struct net_device_ops xemaclite_netdev_ops = {
+static const struct net_device_ops xemaclite_netdev_ops = {
.ndo_open   = xemaclite_open,
.ndo_stop   = xemaclite_close,
.ndo_start_xmit = xemaclite_send,
-- 
1.9.1

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren 
Cc: Ulf Hansson 
Signed-off-by: Matt Ranostay 
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..1a21e14458d3
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay 
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev = dev;
+   pwrseq->pwrseq.ops = _pwrseq_sd8787_ops;
+   pwrseq->pwrseq.owner = THIS_MODULE;
+   platform_set_drvdata(pdev, pwrseq);

[PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren 
Cc: Ulf Hansson 
Signed-off-by: Matt Ranostay 
---
 drivers/mmc/core/Kconfig |  10 
 drivers/mmc/core/Makefile|   1 +
 drivers/mmc/core/pwrseq_sd8787.c | 117 +++
 3 files changed, 128 insertions(+)
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
  This driver can also be built as a module. If so, the module
  will be called pwrseq_emmc.
 
+config PWRSEQ_SD8787
+   tristate "HW reset support for SD8787 BT + Wifi module"
+   depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+   help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
 config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y:= core.o bus.o host.o \
   quirks.o slot-gpio.o
 mmc_core-$(CONFIG_OF)  += pwrseq.o
 obj-$(CONFIG_PWRSEQ_SIMPLE)+= pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787)+= pwrseq_sd8787.o
 obj-$(CONFIG_PWRSEQ_EMMC)  += pwrseq_emmc.o
 mmc_core-$(CONFIG_DEBUG_FS)+= debugfs.o
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index ..1a21e14458d3
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay 
+ *
+ * Based on the original work pwrseq_simple.c
+ *  Copyright (C) 2014 Linaro Ltd
+ *  Author: Ulf Hansson 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+   struct mmc_pwrseq pwrseq;
+   struct gpio_desc *reset_gpio;
+   struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+   msleep(300);
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+   gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+   gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+   .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+   .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+   { .compatible = "mmc-pwrseq-sd8787",},
+   {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+   struct mmc_pwrseq_sd8787 *pwrseq;
+   struct device *dev = >dev;
+
+   pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+   if (!pwrseq)
+   return -ENOMEM;
+
+   pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->pwrdn_gpio))
+   return PTR_ERR(pwrseq->pwrdn_gpio);
+
+   pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+   if (IS_ERR(pwrseq->reset_gpio))
+   return PTR_ERR(pwrseq->reset_gpio);
+
+   pwrseq->pwrseq.dev = dev;
+   pwrseq->pwrseq.ops = _pwrseq_sd8787_ops;
+   pwrseq->pwrseq.owner = THIS_MODULE;
+   platform_set_drvdata(pdev, pwrseq);
+
+   return mmc_pwrseq_register(>pwrseq);
+}
+
+static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay 
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..4bb56766982e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- powerdown-gpio: contains a power down GPIO specifier with active state
+- reset-gpio: contains a reset GPIO specifier with active state
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   powerdown-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options

[Matt Ranostay]

Cc: devicet...@vger.kernel.org
Signed-off-by: Matt Ranostay 
---
 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  | 14 ++
 .../devicetree/bindings/net/wireless/marvell-8xxx.txt  |  7 ++-
 2 files changed, 20 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt

diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt 
b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index ..4bb56766982e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- powerdown-gpio: contains a power down GPIO specifier with active state
+- reset-gpio: contains a reset GPIO specifier with active state
+
+Example:
+
+   wifi_pwrseq: wifi_pwrseq {
+   compatible = "mmc-pwrseq-sd8787";
+   powerdown-gpio = <_gpio 0 GPIO_ACTIVE_LOW>;
+   reset-gpio = <_gpio 1 GPIO_ACTIVE_LOW>;
+   }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt 
b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
 --
 
 This node provides properties for controlling the Marvell SDIO/PCIE wireless 
device.
@@ -8,6 +8,7 @@ connects the device to the system.
 Required properties:
 
   - compatible : should be one of the following:
+   * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
 so that the wifi chip can wakeup host platform under certain 
condition.
 during system resume, the irq will be disabled to make sure
 unnecessary interrupt is not received.
+  - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+  - mmc-pwrseq:  phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+for documentation of MMC power sequence bindings.
 
 Example:
 
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
  {
status = "okay";
vmmc-supply = <_en_reg>;
+   mmc-pwrseq = <_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* update device tree bindings to powerdown-gpios and document
  active state

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

[PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip

[Matt Ranostay]

Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset

Changes from v2:
* update device tree bindings to powerdown-gpios and document
  active state

Matt Ranostay (2):
  devicetree: document new marvell-8xxx and pwrseq-sd8787 options
  mmc: pwrseq: add support for Marvell SD8787 chip

 .../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt  |  14 +++
 .../bindings/net/wireless/marvell-8xxx.txt |   7 +-
 drivers/mmc/core/Kconfig   |  10 ++
 drivers/mmc/core/Makefile  |   1 +
 drivers/mmc/core/pwrseq_sd8787.c   | 117 +
 5 files changed, 148 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
 create mode 100644 drivers/mmc/core/pwrseq_sd8787.c

-- 
2.10.2

Re: [PATCH 1/2] nilfs2: use i_blocksize()

[kbuild test robot]

Hi Geliang,

[auto build test ERROR on v4.9-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Geliang-Tang/nilfs2-use-i_blocksize/20170121-114142
config: x86_64-randconfig-n0-01211226 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs/nilfs2/btree.c: In function 'nilfs_btree_node_size':
>> fs/nilfs2/btree.c:122:2: error: implicit declaration of function 
>> 'i_blocksize' [-Werror=implicit-function-declaration]
 return i_blocksize(btree->b_inode);
 ^
   cc1: some warnings being treated as errors
--
   fs/nilfs2/alloc.c: In function 'nilfs_palloc_groups_per_desc_block':
>> fs/nilfs2/alloc.c:37:2: error: implicit declaration of function 
>> 'i_blocksize' [-Werror=implicit-function-declaration]
 return i_blocksize(inode) /
 ^
   cc1: some warnings being treated as errors

vim +/i_blocksize +122 fs/nilfs2/btree.c

   116  {
   117  node->bn_nchildren = cpu_to_le16(nchildren);
   118  }
   119  
   120  static int nilfs_btree_node_size(const struct nilfs_bmap *btree)
   121  {
 > 122  return i_blocksize(btree->b_inode);
   123  }
   124  
   125  static int nilfs_btree_nchildren_per_block(const struct nilfs_bmap 
*btree)

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] nilfs2: use i_blocksize()

[kbuild test robot]

Hi Geliang,

[auto build test ERROR on v4.9-rc8]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Geliang-Tang/nilfs2-use-i_blocksize/20170121-114142
config: x86_64-randconfig-n0-01211226 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   fs/nilfs2/btree.c: In function 'nilfs_btree_node_size':
>> fs/nilfs2/btree.c:122:2: error: implicit declaration of function 
>> 'i_blocksize' [-Werror=implicit-function-declaration]
 return i_blocksize(btree->b_inode);
 ^
   cc1: some warnings being treated as errors
--
   fs/nilfs2/alloc.c: In function 'nilfs_palloc_groups_per_desc_block':
>> fs/nilfs2/alloc.c:37:2: error: implicit declaration of function 
>> 'i_blocksize' [-Werror=implicit-function-declaration]
 return i_blocksize(inode) /
 ^
   cc1: some warnings being treated as errors

vim +/i_blocksize +122 fs/nilfs2/btree.c

   116  {
   117  node->bn_nchildren = cpu_to_le16(nchildren);
   118  }
   119  
   120  static int nilfs_btree_node_size(const struct nilfs_bmap *btree)
   121  {
 > 122  return i_blocksize(btree->b_inode);
   123  }
   124  
   125  static int nilfs_btree_nchildren_per_block(const struct nilfs_bmap 
*btree)

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


.config.gz
Description: application/gzip

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

[Chanwoo Choi]

Hi Sylwester,

I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t
include the my reviewed-by tag.

[1] 
https://git.linuxtv.org/snawrocki/samsung.git/commit/?h=for-v4.11/clk/next=cb4ac949ea14416a2d57b7a343bc4b571074e3bd

2017-01-16 19:32 GMT+09:00 Sylwester Nawrocki :
> On 01/14/2017 01:36 PM, Krzysztof Kozlowski wrote:
>> Support for Exynos4415 is going away because there are no internal nor
>> external users.
>>
>> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
>> the platform cannot be instantiated so remove also the drivers.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>
> Applied, thanks.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH 2/4] clk: samsung: Remove Exynos4415 driver (SoC not supported anymore)

[Chanwoo Choi]

Hi Sylwester,

I add reveiwed-by tag from this patch. But, on you tree, this patch[1] doesn’t
include the my reviewed-by tag.

[1] 
https://git.linuxtv.org/snawrocki/samsung.git/commit/?h=for-v4.11/clk/next=cb4ac949ea14416a2d57b7a343bc4b571074e3bd

2017-01-16 19:32 GMT+09:00 Sylwester Nawrocki :
> On 01/14/2017 01:36 PM, Krzysztof Kozlowski wrote:
>> Support for Exynos4415 is going away because there are no internal nor
>> external users.
>>
>> Since commit 46dcf0ff0de3 ("ARM: dts: exynos: Remove exynos4415.dtsi"),
>> the platform cannot be instantiated so remove also the drivers.
>>
>> Signed-off-by: Krzysztof Kozlowski 
>
> Applied, thanks.
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[patch] orangefs: silence harmless integer overflow warning

[Dan Carpenter]

The issue here is that in orangefs_bufmap_alloc() we do:

bufmap->buffer_index_array =
kzalloc(DIV_ROUND_UP(bufmap->desc_count, BITS_PER_LONG), 
GFP_KERNEL);

If we choose a bufmap->desc_count like -31 then it means the
DIV_ROUND_UP ends up having an integer overflow.   The result is that
kzalloc() returns the ZERO_SIZE_PTR and there is a static checker
warning.

But this bug is harmless because on the next lines we use ->desc_count
to do a kcalloc().  That has integer overflow checking built in so the
kcalloc() fails and we return an error code.

Anyway, it doesn't make sense to talk about negative sizes and blocking
them silences the static checker warning.

Signed-off-by: Dan Carpenter 

diff --git a/fs/orangefs/orangefs-bufmap.c b/fs/orangefs/orangefs-bufmap.c
index 75375e9..6333cbb 100644
--- a/fs/orangefs/orangefs-bufmap.c
+++ b/fs/orangefs/orangefs-bufmap.c
@@ -344,6 +344,11 @@ int orangefs_bufmap_initialize(struct 
ORANGEFS_dev_map_desc *user_desc)
 user_desc->size,
 user_desc->count);
 
+   if (user_desc->total_size < 0 ||
+   user_desc->size < 0 ||
+   user_desc->count < 0)
+   goto out;
+
/*
 * sanity check alignment and size of buffer that caller wants to
 * work with

[patch] orangefs: silence harmless integer overflow warning

[Dan Carpenter]

The issue here is that in orangefs_bufmap_alloc() we do:

bufmap->buffer_index_array =
kzalloc(DIV_ROUND_UP(bufmap->desc_count, BITS_PER_LONG), 
GFP_KERNEL);

If we choose a bufmap->desc_count like -31 then it means the
DIV_ROUND_UP ends up having an integer overflow.   The result is that
kzalloc() returns the ZERO_SIZE_PTR and there is a static checker
warning.

But this bug is harmless because on the next lines we use ->desc_count
to do a kcalloc().  That has integer overflow checking built in so the
kcalloc() fails and we return an error code.

Anyway, it doesn't make sense to talk about negative sizes and blocking
them silences the static checker warning.

Signed-off-by: Dan Carpenter 

diff --git a/fs/orangefs/orangefs-bufmap.c b/fs/orangefs/orangefs-bufmap.c
index 75375e9..6333cbb 100644
--- a/fs/orangefs/orangefs-bufmap.c
+++ b/fs/orangefs/orangefs-bufmap.c
@@ -344,6 +344,11 @@ int orangefs_bufmap_initialize(struct 
ORANGEFS_dev_map_desc *user_desc)
 user_desc->size,
 user_desc->count);
 
+   if (user_desc->total_size < 0 ||
+   user_desc->size < 0 ||
+   user_desc->count < 0)
+   goto out;
+
/*
 * sanity check alignment and size of buffer that caller wants to
 * work with

[patch] samples/bpf: silence shift wrapping warning

[Dan Carpenter]

max_key is a value in the 0-63 range, so on 32 bit systems the shift
could wrap.

Signed-off-by: Dan Carpenter 

diff --git a/samples/bpf/lwt_len_hist_user.c b/samples/bpf/lwt_len_hist_user.c
index ec8f3bb..bd06eef 100644
--- a/samples/bpf/lwt_len_hist_user.c
+++ b/samples/bpf/lwt_len_hist_user.c
@@ -68,7 +68,7 @@ int main(int argc, char **argv)
for (i = 1; i <= max_key + 1; i++) {
stars(starstr, data[i - 1], max_value, MAX_STARS);
printf("%8ld -> %-8ld : %-8ld |%-*s|\n",
-  (1l << i) >> 1, (1l << i) - 1, data[i - 1],
+  (1ULL << i) >> 1, (1ULL << i) - 1, data[i - 1],
   MAX_STARS, starstr);
}
 

[patch] samples/bpf: silence shift wrapping warning

[Dan Carpenter]

max_key is a value in the 0-63 range, so on 32 bit systems the shift
could wrap.

Signed-off-by: Dan Carpenter 

diff --git a/samples/bpf/lwt_len_hist_user.c b/samples/bpf/lwt_len_hist_user.c
index ec8f3bb..bd06eef 100644
--- a/samples/bpf/lwt_len_hist_user.c
+++ b/samples/bpf/lwt_len_hist_user.c
@@ -68,7 +68,7 @@ int main(int argc, char **argv)
for (i = 1; i <= max_key + 1; i++) {
stars(starstr, data[i - 1], max_value, MAX_STARS);
printf("%8ld -> %-8ld : %-8ld |%-*s|\n",
-  (1l << i) >> 1, (1l << i) - 1, data[i - 1],
+  (1ULL << i) >> 1, (1ULL << i) - 1, data[i - 1],
   MAX_STARS, starstr);
}
 

Re: [PATCH RESEND 2/2] ARM: da850: add the nand dev_id to the clock lookup table

[Sekhar Nori]

On Friday 13 January 2017 03:30 PM, Bartosz Golaszewski wrote:
> The aemif driver can now access struct of_dev_auxdata (using platform
> data).
> 
> Add the device id to the clock lookup table for the nand clock and
> create a separate lookup table for aemif subnodes.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied to v4.11/soc

Thanks,
Sekhar

Re: [PATCH RESEND 2/2] ARM: da850: add the nand dev_id to the clock lookup table

[Sekhar Nori]

On Friday 13 January 2017 03:30 PM, Bartosz Golaszewski wrote:
> The aemif driver can now access struct of_dev_auxdata (using platform
> data).
> 
> Add the device id to the clock lookup table for the nand clock and
> create a separate lookup table for aemif subnodes.
> 
> Signed-off-by: Bartosz Golaszewski 

Applied to v4.11/soc

Thanks,
Sekhar

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: x86_64-randconfig-x008-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> arch/x86/mm/dump_pagetables.c:85:4: error: 'MODULES_VADDR' undeclared here 
>> (not in a function)
 { MODULES_VADDR,"Modules" },
   ^
>> arch/x86/mm/dump_pagetables.c:86:4: error: 'MODULES_END' undeclared here 
>> (not in a function)
 { MODULES_END,  "End Modules" },
   ^~~

vim +/MODULES_VADDR +85 arch/x86/mm/dump_pagetables.c

3891a04aa H. Peter Anvin 2014-04-29  79 { ESPFIX_BASE_ADDR, "ESPfix 
Area", 16 },
8a5a5d153 Mathias Krause 2014-09-07  80  # endif
8266e31ed Mathias Krause 2014-09-21  81  # ifdef CONFIG_EFI
8266e31ed Mathias Krause 2014-09-21  82 { EFI_VA_END,   "EFI 
Runtime Services" },
8266e31ed Mathias Krause 2014-09-21  83  # endif
fe770bf03 H. Peter Anvin 2008-04-17  84 { __START_KERNEL_map,   "High 
Kernel Mapping" },
9a79cf9c1 Yinghai Lu 2008-03-07 @85 { MODULES_VADDR,
"Modules" },
9a79cf9c1 Yinghai Lu 2008-03-07 @86 { MODULES_END,  "End 
Modules" },
fe770bf03 H. Peter Anvin 2008-04-17  87  #else
fe770bf03 H. Peter Anvin 2008-04-17  88 { PAGE_OFFSET,  "Kernel 
Mapping" },
fe770bf03 H. Peter Anvin 2008-04-17  89 { 0/* VMALLOC_START */, 
"vmalloc() Area" },

:: The code at line 85 was first introduced by commit
:: 9a79cf9c1aa671325fa5ba37576c2cee23823d04 x86: sort address_markers for 
dump_pagetables

:: TO: Yinghai Lu <yhlu.ker...@gmail.com>
:: CC: Ingo Molnar <mi...@elte.hu>

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: x86_64-randconfig-x008-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> arch/x86/mm/dump_pagetables.c:85:4: error: 'MODULES_VADDR' undeclared here 
>> (not in a function)
 { MODULES_VADDR,"Modules" },
   ^
>> arch/x86/mm/dump_pagetables.c:86:4: error: 'MODULES_END' undeclared here 
>> (not in a function)
 { MODULES_END,  "End Modules" },
   ^~~

vim +/MODULES_VADDR +85 arch/x86/mm/dump_pagetables.c

3891a04aa H. Peter Anvin 2014-04-29  79 { ESPFIX_BASE_ADDR, "ESPfix 
Area", 16 },
8a5a5d153 Mathias Krause 2014-09-07  80  # endif
8266e31ed Mathias Krause 2014-09-21  81  # ifdef CONFIG_EFI
8266e31ed Mathias Krause 2014-09-21  82 { EFI_VA_END,   "EFI 
Runtime Services" },
8266e31ed Mathias Krause 2014-09-21  83  # endif
fe770bf03 H. Peter Anvin 2008-04-17  84 { __START_KERNEL_map,   "High 
Kernel Mapping" },
9a79cf9c1 Yinghai Lu 2008-03-07 @85 { MODULES_VADDR,
"Modules" },
9a79cf9c1 Yinghai Lu 2008-03-07 @86 { MODULES_END,  "End 
Modules" },
fe770bf03 H. Peter Anvin 2008-04-17  87  #else
fe770bf03 H. Peter Anvin 2008-04-17  88 { PAGE_OFFSET,  "Kernel 
Mapping" },
fe770bf03 H. Peter Anvin 2008-04-17  89 { 0/* VMALLOC_START */, 
"vmalloc() Area" },

:: The code at line 85 was first introduced by commit
:: 9a79cf9c1aa671325fa5ba37576c2cee23823d04 x86: sort address_markers for 
dump_pagetables

:: TO: Yinghai Lu 
:: CC: Ingo Molnar 

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: x86_64-randconfig-x002-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/mm/kasan_init_64.c: In function 'kasan_init':
>> arch/x86/mm/kasan_init_64.c:120:57: error: 'MODULES_END' undeclared (first 
>> use in this function)
 kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)MODULES_END),
^~~
   arch/x86/mm/kasan_init_64.c:120:57: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/MODULES_END +120 arch/x86/mm/kasan_init_64.c

c420f167d Andrey Ryabinin 2015-02-13  114   
kasan_mem_to_shadow((void *)__START_KERNEL_map));
c420f167d Andrey Ryabinin 2015-02-13  115  
c420f167d Andrey Ryabinin 2015-02-13  116   vmemmap_populate((unsigned 
long)kasan_mem_to_shadow(_stext),
c420f167d Andrey Ryabinin 2015-02-13  117   (unsigned 
long)kasan_mem_to_shadow(_end),
c420f167d Andrey Ryabinin 2015-02-13  118   NUMA_NO_NODE);
c420f167d Andrey Ryabinin 2015-02-13  119  
69786cdb3 Andrey Ryabinin 2015-08-13 @120   
kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)MODULES_END),
ef7f0d6a6 Andrey Ryabinin 2015-02-13  121   (void 
*)KASAN_SHADOW_END);
ef7f0d6a6 Andrey Ryabinin 2015-02-13  122  
ef7f0d6a6 Andrey Ryabinin 2015-02-13  123   load_cr3(init_level4_pgt);

:: The code at line 120 was first introduced by commit
:: 69786cdb379bbc6eab14cf2393c1abd879316e85 x86/kasan, mm: Introduce 
generic kasan_populate_zero_shadow()

:: TO: Andrey Ryabinin <ryabinin@gmail.com>
:: CC: Ingo Molnar <mi...@kernel.org>

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/3] x86/mm: Adapt MODULES_END based on Fixmap section size

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: x86_64-randconfig-x002-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/mm/kasan_init_64.c: In function 'kasan_init':
>> arch/x86/mm/kasan_init_64.c:120:57: error: 'MODULES_END' undeclared (first 
>> use in this function)
 kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)MODULES_END),
^~~
   arch/x86/mm/kasan_init_64.c:120:57: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/MODULES_END +120 arch/x86/mm/kasan_init_64.c

c420f167d Andrey Ryabinin 2015-02-13  114   
kasan_mem_to_shadow((void *)__START_KERNEL_map));
c420f167d Andrey Ryabinin 2015-02-13  115  
c420f167d Andrey Ryabinin 2015-02-13  116   vmemmap_populate((unsigned 
long)kasan_mem_to_shadow(_stext),
c420f167d Andrey Ryabinin 2015-02-13  117   (unsigned 
long)kasan_mem_to_shadow(_end),
c420f167d Andrey Ryabinin 2015-02-13  118   NUMA_NO_NODE);
c420f167d Andrey Ryabinin 2015-02-13  119  
69786cdb3 Andrey Ryabinin 2015-08-13 @120   
kasan_populate_zero_shadow(kasan_mem_to_shadow((void *)MODULES_END),
ef7f0d6a6 Andrey Ryabinin 2015-02-13  121   (void 
*)KASAN_SHADOW_END);
ef7f0d6a6 Andrey Ryabinin 2015-02-13  122  
ef7f0d6a6 Andrey Ryabinin 2015-02-13  123   load_cr3(init_level4_pgt);

:: The code at line 120 was first introduced by commit
:: 69786cdb379bbc6eab14cf2393c1abd879316e85 x86/kasan, mm: Introduce 
generic kasan_populate_zero_shadow()

:: TO: Andrey Ryabinin 
:: CC: Ingo Molnar 

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


.config.gz
Description: application/gzip

Re: [PATCH 0/4] HID: wacom: fixes for next

[Jason Gerecke]

Patches 1/3 look reasonable to me, though I've not run into the bugs
they aim to fix. For those:

Acked-by: Jason Gerecke 

As for patch 4, I have some additional reservations about hiding the
message... We can discuss that further in its thread.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours



On Fri, Jan 20, 2017 at 7:20 AM, Benjamin Tissoires
 wrote:
> Hi,
>
> well, these are non critical but nonetheless interesting fixes for
> Wacom I was working on last week. I was waiting for the current v4.10
> fix to be sent by Jason before pushing those out.
>
> Cheers,
> Benjamin
>
> Benjamin Tissoires (4):
>   HID: wacom: release the resources before leaving despite devm
>   HID: wacom: remove warning while disconnecting devices
>   HID: wacom: do not attempt to switch mode while in probe
>   HID: wacom: do not shout an error on LED control
>
>  drivers/hid/wacom.h |  1 +
>  drivers/hid/wacom_sys.c | 42 ++
>  2 files changed, 31 insertions(+), 12 deletions(-)
>
> --
> 2.9.3
>

Re: [PATCH 0/4] HID: wacom: fixes for next

[Jason Gerecke]

Patches 1/3 look reasonable to me, though I've not run into the bugs
they aim to fix. For those:

Acked-by: Jason Gerecke 

As for patch 4, I have some additional reservations about hiding the
message... We can discuss that further in its thread.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours



On Fri, Jan 20, 2017 at 7:20 AM, Benjamin Tissoires
 wrote:
> Hi,
>
> well, these are non critical but nonetheless interesting fixes for
> Wacom I was working on last week. I was waiting for the current v4.10
> fix to be sent by Jason before pushing those out.
>
> Cheers,
> Benjamin
>
> Benjamin Tissoires (4):
>   HID: wacom: release the resources before leaving despite devm
>   HID: wacom: remove warning while disconnecting devices
>   HID: wacom: do not attempt to switch mode while in probe
>   HID: wacom: do not shout an error on LED control
>
>  drivers/hid/wacom.h |  1 +
>  drivers/hid/wacom_sys.c | 42 ++
>  2 files changed, 31 insertions(+), 12 deletions(-)
>
> --
> 2.9.3
>

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: i386-randconfig-x003-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/signal.h:4,
from arch/x86/mm/init_32.c:8:
   arch/x86/mm/init_32.c: In function 'mem_init':
>> include/linux/compiler.h:518:38: error: call to '__compiletime_assert_805' 
>> declared with attribute error: BUILD_BUG_ON failed: 
>> __fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:501:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
>> arch/x86/mm/init_32.c:805:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END);
 ^~~~

vim +/__compiletime_assert_805 +518 include/linux/compiler.h

9a8ab1c3 Daniel Santos  2013-02-21  512   *
9a8ab1c3 Daniel Santos  2013-02-21  513   * In tradition of POSIX assert, this 
macro will break the build if the
9a8ab1c3 Daniel Santos  2013-02-21  514   * supplied condition is *false*, 
emitting the supplied error message if the
9a8ab1c3 Daniel Santos  2013-02-21  515   * compiler has support to do so.
9a8ab1c3 Daniel Santos  2013-02-21  516   */
9a8ab1c3 Daniel Santos  2013-02-21  517  #define compiletime_assert(condition, 
msg) \
9a8ab1c3 Daniel Santos  2013-02-21 @518 _compiletime_assert(condition, 
msg, __compiletime_assert_, __LINE__)
9a8ab1c3 Daniel Santos  2013-02-21  519  
47933ad4 Peter Zijlstra 2013-11-06  520  #define 
compiletime_assert_atomic_type(t)  \
47933ad4 Peter Zijlstra 2013-11-06  521 
compiletime_assert(__native_word(t),\

:: The code at line 518 was first introduced by commit
:: 9a8ab1c39970a4938a72d94e6fd13be88a797590 bug.h, compiler.h: introduce 
compiletime_assert & BUILD_BUG_ON_MSG

:: TO: Daniel Santos <daniel.san...@pobox.com>
:: CC: Linus Torvalds <torva...@linux-foundation.org>

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


.config.gz
Description: application/gzip

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: i386-randconfig-x003-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/signal.h:4,
from arch/x86/mm/init_32.c:8:
   arch/x86/mm/init_32.c: In function 'mem_init':
>> include/linux/compiler.h:518:38: error: call to '__compiletime_assert_805' 
>> declared with attribute error: BUILD_BUG_ON failed: 
>> __fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:501:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
>> arch/x86/mm/init_32.c:805:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END);
 ^~~~

vim +/__compiletime_assert_805 +518 include/linux/compiler.h

9a8ab1c3 Daniel Santos  2013-02-21  512   *
9a8ab1c3 Daniel Santos  2013-02-21  513   * In tradition of POSIX assert, this 
macro will break the build if the
9a8ab1c3 Daniel Santos  2013-02-21  514   * supplied condition is *false*, 
emitting the supplied error message if the
9a8ab1c3 Daniel Santos  2013-02-21  515   * compiler has support to do so.
9a8ab1c3 Daniel Santos  2013-02-21  516   */
9a8ab1c3 Daniel Santos  2013-02-21  517  #define compiletime_assert(condition, 
msg) \
9a8ab1c3 Daniel Santos  2013-02-21 @518 _compiletime_assert(condition, 
msg, __compiletime_assert_, __LINE__)
9a8ab1c3 Daniel Santos  2013-02-21  519  
47933ad4 Peter Zijlstra 2013-11-06  520  #define 
compiletime_assert_atomic_type(t)  \
47933ad4 Peter Zijlstra 2013-11-06  521 
compiletime_assert(__native_word(t),\

:: The code at line 518 was first introduced by commit
:: 9a8ab1c39970a4938a72d94e6fd13be88a797590 bug.h, compiler.h: introduce 
compiletime_assert & BUILD_BUG_ON_MSG

:: TO: Daniel Santos 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [PATCH 4/4] HID: wacom: do not shout an error on LED control

[Jason Gerecke]

I'm not super comfortable with hiding this error. If the tablet reacts
appropriately, I wouldn't think we'd get an EPIPE. Although its not
fatal, it still might be a symptom of something deeper...

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours



On Fri, Jan 20, 2017 at 7:20 AM, Benjamin Tissoires
 wrote:
> At plug, the tablet seems to output a -EPIPE when first accessing the
> LED. The weird part is that the command is taken into account by the
> tablet, but we shout an error in the dmesg.
>
> Cut off the error so that users are happier.
>
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/hid/wacom_sys.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 6acb422..6acf3a3 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -803,8 +803,12 @@ static int wacom_led_control(struct wacom *wacom)
> buf[4] = wacom->led.img_lum;
> }
>
> -   retval = wacom_set_report(wacom->hdev, HID_FEATURE_REPORT, buf, 
> buf_size,
> - WAC_CMD_RETRIES);
> +   /*
> +* we do not use wacom_set_report because -EPIPE happens but is
> +* not fatal, so do not shout something at the user.
> +*/
> +   retval = hid_hw_raw_request(wacom->hdev, buf[0], buf, buf_size,
> +   HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
> kfree(buf);
>
> return retval;
> --
> 2.9.3
>

Re: [PATCH 4/4] HID: wacom: do not shout an error on LED control

[Jason Gerecke]

I'm not super comfortable with hiding this error. If the tablet reacts
appropriately, I wouldn't think we'd get an EPIPE. Although its not
fatal, it still might be a symptom of something deeper...

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two, /
But you can’t take seven from three,/
So you look at the sixty-fours



On Fri, Jan 20, 2017 at 7:20 AM, Benjamin Tissoires
 wrote:
> At plug, the tablet seems to output a -EPIPE when first accessing the
> LED. The weird part is that the command is taken into account by the
> tablet, but we shout an error in the dmesg.
>
> Cut off the error so that users are happier.
>
> Signed-off-by: Benjamin Tissoires 
> ---
>  drivers/hid/wacom_sys.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
> index 6acb422..6acf3a3 100644
> --- a/drivers/hid/wacom_sys.c
> +++ b/drivers/hid/wacom_sys.c
> @@ -803,8 +803,12 @@ static int wacom_led_control(struct wacom *wacom)
> buf[4] = wacom->led.img_lum;
> }
>
> -   retval = wacom_set_report(wacom->hdev, HID_FEATURE_REPORT, buf, 
> buf_size,
> - WAC_CMD_RETRIES);
> +   /*
> +* we do not use wacom_set_report because -EPIPE happens but is
> +* not fatal, so do not shout something at the user.
> +*/
> +   retval = hid_hw_raw_request(wacom->hdev, buf[0], buf, buf_size,
> +   HID_FEATURE_REPORT, HID_REQ_SET_REPORT);
> kfree(buf);
>
> return retval;
> --
> 2.9.3
>

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

[Namhyung Kim]

On Fri, Jan 20, 2017 at 09:13:17PM -0500, Steven Rostedt wrote:
> On Sat, 21 Jan 2017 09:27:06 +0900
> Namhyung Kim  wrote:
> 
> 
> > > Note, I had to modify this patch and move this declaration outside of
> > > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when
> > > function graph wasn't enabled. Function tracer uses this too.  
> > 
> > Oops, my bad.
> > 
> > Did you modify it in your tree?  Or do you want me to resend v2?
> 
> No, it's a trivial change and I made the modification and noted it in
> the change log. You can see the change in my tree under the ftrace/core
> branch. I'm taking off next week and I wanted to get this series tested
> before I go. The tests are still running.

Thanks for doing that!
Namhyung

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

[Namhyung Kim]

On Fri, Jan 20, 2017 at 09:13:17PM -0500, Steven Rostedt wrote:
> On Sat, 21 Jan 2017 09:27:06 +0900
> Namhyung Kim  wrote:
> 
> 
> > > Note, I had to modify this patch and move this declaration outside of
> > > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when
> > > function graph wasn't enabled. Function tracer uses this too.  
> > 
> > Oops, my bad.
> > 
> > Did you modify it in your tree?  Or do you want me to resend v2?
> 
> No, it's a trivial change and I made the modification and noted it in
> the change log. You can see the change in my tree under the ftrace/core
> branch. I'm taking off next week and I wanted to get this series tested
> before I go. The tests are still running.

Thanks for doing that!
Namhyung

[PATCH v2] clk: hisilicon: fix lock assignment

[Leo Yan]

In clock driver initialize phase the spinlock is missed to assignment
to struct clkgate_separated, finally there have no locking to protect
exclusive accessing for clock registers.

This bug introduces the console has no output after enable coresight
driver on 96boards Hikey; this is because console using UART3, which
has shared the same register with coresight clock enabling bit. After
applied this patch it can assign lock properly to protect exclusive
accessing, and console can work well after enabled coresight modules.

Fixes: 0aa0c95f743a ("clk: hisilicon: add common clock support")
Signed-off-by: Leo Yan 
---
 drivers/clk/hisilicon/clkgate-separated.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/hisilicon/clkgate-separated.c 
b/drivers/clk/hisilicon/clkgate-separated.c
index a47812f..7908bc3 100644
--- a/drivers/clk/hisilicon/clkgate-separated.c
+++ b/drivers/clk/hisilicon/clkgate-separated.c
@@ -120,6 +120,7 @@ struct clk *hisi_register_clkgate_sep(struct device *dev, 
const char *name,
sclk->bit_idx = bit_idx;
sclk->flags = clk_gate_flags;
sclk->hw.init = 
+   sclk->lock = lock;
 
clk = clk_register(dev, >hw);
if (IS_ERR(clk))
-- 
2.7.4

[PATCH v2] clk: hisilicon: fix lock assignment

[Leo Yan]

In clock driver initialize phase the spinlock is missed to assignment
to struct clkgate_separated, finally there have no locking to protect
exclusive accessing for clock registers.

This bug introduces the console has no output after enable coresight
driver on 96boards Hikey; this is because console using UART3, which
has shared the same register with coresight clock enabling bit. After
applied this patch it can assign lock properly to protect exclusive
accessing, and console can work well after enabled coresight modules.

Fixes: 0aa0c95f743a ("clk: hisilicon: add common clock support")
Signed-off-by: Leo Yan 
---
 drivers/clk/hisilicon/clkgate-separated.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/hisilicon/clkgate-separated.c 
b/drivers/clk/hisilicon/clkgate-separated.c
index a47812f..7908bc3 100644
--- a/drivers/clk/hisilicon/clkgate-separated.c
+++ b/drivers/clk/hisilicon/clkgate-separated.c
@@ -120,6 +120,7 @@ struct clk *hisi_register_clkgate_sep(struct device *dev, 
const char *name,
sclk->bit_idx = bit_idx;
sclk->flags = clk_gate_flags;
sclk->hw.init = 
+   sclk->lock = lock;
 
clk = clk_register(dev, >hw);
if (IS_ERR(clk))
-- 
2.7.4

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: i386-randconfig-x004-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/signal.h:4,
from arch/x86/mm/init_32.c:8:
   arch/x86/mm/init_32.c: In function 'mem_init':
>> include/linux/compiler.h:518:38: error: call to '__compiletime_assert_801' 
>> declared with attribute error: BUILD_BUG_ON failed: 
>> __fix_to_virt(__end_of_fixed_addresses) <= PKMAP_BASE + LAST_PKMAP*PAGE_SIZE
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:501:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
   arch/x86/mm/init_32.c:801:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= PKMAP_BASE + 
LAST_PKMAP*PAGE_SIZE);
 ^~~~
   include/linux/compiler.h:518:38: error: call to '__compiletime_assert_805' 
declared with attribute error: BUILD_BUG_ON failed: 
__fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:501:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
   arch/x86/mm/init_32.c:805:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END);
 ^~~~

vim +/__compiletime_assert_801 +518 include/linux/compiler.h

9a8ab1c3 Daniel Santos  2013-02-21  512   *
9a8ab1c3 Daniel Santos  2013-02-21  513   * In tradition of POSIX assert, this 
macro will break the build if the
9a8ab1c3 Daniel Santos  2013-02-21  514   * supplied condition is *false*, 
emitting the supplied error message if the
9a8ab1c3 Daniel Santos  2013-02-21  515   * compiler has support to do so.
9a8ab1c3 Daniel Santos  2013-02-21  516   */
9a8ab1c3 Daniel Santos  2013-02-21  517  #define compiletime_assert(condition, 
msg) \
9a8ab1c3 Daniel Santos  2013-02-21 @518 _compiletime_assert(condition, 
msg, __compiletime_assert_, __LINE__)
9a8ab1c3 Daniel Santos  2013-02-21  519  
47933ad4 Peter Zijlstra 2013-11-06  520  #define 
compiletime_assert_atomic_type(t)  \
47933ad4 Peter Zijlstra 2013-11-06  521 
compiletime_assert(__native_word(t),\

:: The code at line 518 was first introduced by commit
:: 9a8ab1c39970a4938a72d94e6fd13be88a797590 bug.h, compiler.h: introduce 
compiletime_assert & BUILD_BUG_ON_MSG

:: TO: Daniel Santos <daniel.san...@pobox.com>
:: CC: Linus Torvalds <torva...@linux-foundation.org>

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


.config.gz
Description: application/gzip

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[kbuild test robot]

Hi Thomas,

[auto build test ERROR on tip/auto-latest]
[also build test ERROR on v4.10-rc4 next-20170120]
[cannot apply to tip/x86/core]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Thomas-Garnier/x86-mm-Adapt-MODULES_END-based-on-Fixmap-section-size/20170121-094756
config: i386-randconfig-x004-201703 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/linux/signal.h:4,
from arch/x86/mm/init_32.c:8:
   arch/x86/mm/init_32.c: In function 'mem_init':
>> include/linux/compiler.h:518:38: error: call to '__compiletime_assert_801' 
>> declared with attribute error: BUILD_BUG_ON failed: 
>> __fix_to_virt(__end_of_fixed_addresses) <= PKMAP_BASE + LAST_PKMAP*PAGE_SIZE
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:501:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
   arch/x86/mm/init_32.c:801:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= PKMAP_BASE + 
LAST_PKMAP*PAGE_SIZE);
 ^~~~
   include/linux/compiler.h:518:38: error: call to '__compiletime_assert_805' 
declared with attribute error: BUILD_BUG_ON failed: 
__fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^
   include/linux/compiler.h:501:4: note: in definition of macro 
'__compiletime_assert'
   prefix ## suffix();\
   ^~
   include/linux/compiler.h:518:2: note: in expansion of macro 
'_compiletime_assert'
 _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
 ^~~
   include/linux/bug.h:54:37: note: in expansion of macro 'compiletime_assert'
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^~
   include/linux/bug.h:78:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
 BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
 ^~~~
   arch/x86/mm/init_32.c:805:2: note: in expansion of macro 'BUILD_BUG_ON'
 BUILD_BUG_ON(__fix_to_virt(__end_of_fixed_addresses) <= VMALLOC_END);
 ^~~~

vim +/__compiletime_assert_801 +518 include/linux/compiler.h

9a8ab1c3 Daniel Santos  2013-02-21  512   *
9a8ab1c3 Daniel Santos  2013-02-21  513   * In tradition of POSIX assert, this 
macro will break the build if the
9a8ab1c3 Daniel Santos  2013-02-21  514   * supplied condition is *false*, 
emitting the supplied error message if the
9a8ab1c3 Daniel Santos  2013-02-21  515   * compiler has support to do so.
9a8ab1c3 Daniel Santos  2013-02-21  516   */
9a8ab1c3 Daniel Santos  2013-02-21  517  #define compiletime_assert(condition, 
msg) \
9a8ab1c3 Daniel Santos  2013-02-21 @518 _compiletime_assert(condition, 
msg, __compiletime_assert_, __LINE__)
9a8ab1c3 Daniel Santos  2013-02-21  519  
47933ad4 Peter Zijlstra 2013-11-06  520  #define 
compiletime_assert_atomic_type(t)  \
47933ad4 Peter Zijlstra 2013-11-06  521 
compiletime_assert(__native_word(t),\

:: The code at line 518 was first introduced by commit
:: 9a8ab1c39970a4938a72d94e6fd13be88a797590 bug.h, compiler.h: introduce 
compiletime_assert & BUILD_BUG_ON_MSG

:: TO: Daniel Santos 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

Re: [PATCH] clk: hisilicon: fix lock assignment

[Leo Yan]

On Fri, Jan 20, 2017 at 02:58:27PM -0800, Stephen Boyd wrote:
> On 01/18, Leo Yan wrote:
> > In clock driver initialize phase the spinlock is missed to assignment
> > to struct clkgate_separated, finally there have no locking to protect
> > exclusive accessing for clock registers.
> > 
> > This bug introduces the console has no output after enable coresight
> > driver on 96borads Hikey; this is because console using UART3, which
> 
> s/borads/boards/
> 
> > has shared the same register with coresight clock enabling bit. After
> > applied this patch it can assign lock properly to protect exclusive
> > accessing, and console can work well after enabled coresight modules.
> > 
> > Signed-off-by: Leo Yan 
> 
> Is there a Fixes: tag needed?

Thanks for reviewing, will send new patch for upper comments.

> Is coresight support merged into Linus' tree? I want to know if
> this needs to be applied for v4.10 or can wait until v4.11.

No, Coresight patch has not been merged. Should meantion one thing is:
this issue impacts all gate clocks if they share same register, there
have many such kind clocks for Hi6220. So it's not only for coresight
and uart clocks.

Thanks,
Leo Yan

Re: [PATCH] clk: hisilicon: fix lock assignment

[Leo Yan]

On Fri, Jan 20, 2017 at 02:58:27PM -0800, Stephen Boyd wrote:
> On 01/18, Leo Yan wrote:
> > In clock driver initialize phase the spinlock is missed to assignment
> > to struct clkgate_separated, finally there have no locking to protect
> > exclusive accessing for clock registers.
> > 
> > This bug introduces the console has no output after enable coresight
> > driver on 96borads Hikey; this is because console using UART3, which
> 
> s/borads/boards/
> 
> > has shared the same register with coresight clock enabling bit. After
> > applied this patch it can assign lock properly to protect exclusive
> > accessing, and console can work well after enabled coresight modules.
> > 
> > Signed-off-by: Leo Yan 
> 
> Is there a Fixes: tag needed?

Thanks for reviewing, will send new patch for upper comments.

> Is coresight support merged into Linus' tree? I want to know if
> this needs to be applied for v4.10 or can wait until v4.11.

No, Coresight patch has not been merged. Should meantion one thing is:
this issue impacts all gate clocks if they share same register, there
have many such kind clocks for Hi6220. So it's not only for coresight
and uart clocks.

Thanks,
Leo Yan

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

[Steven Rostedt]

On Sat, 21 Jan 2017 09:27:06 +0900
Namhyung Kim  wrote:


> > Note, I had to modify this patch and move this declaration outside of
> > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when
> > function graph wasn't enabled. Function tracer uses this too.  
> 
> Oops, my bad.
> 
> Did you modify it in your tree?  Or do you want me to resend v2?

No, it's a trivial change and I made the modification and noted it in
the change log. You can see the change in my tree under the ftrace/core
branch. I'm taking off next week and I wanted to get this series tested
before I go. The tests are still running.

-- Steve

Re: [PATCH 2/3] ftrace: Expose ftrace_hash_empty and ftrace_lookup_ip

[Steven Rostedt]

On Sat, 21 Jan 2017 09:27:06 +0900
Namhyung Kim  wrote:


> > Note, I had to modify this patch and move this declaration outside of
> > the #ifdef CONFIG_FUNCTION_GRAPH_TRACER, as it failed to build when
> > function graph wasn't enabled. Function tracer uses this too.  
> 
> Oops, my bad.
> 
> Did you modify it in your tree?  Or do you want me to resend v2?

No, it's a trivial change and I made the modification and noted it in
the change log. You can see the change in my tree under the ftrace/core
branch. I'm taking off next week and I wanted to get this series tested
before I go. The tests are still running.

-- Steve

Re: [PATCH v7] tpm: Check size of response before accessing data

[Stefan Berger]

On 01/20/2017 03:14 PM, Jarkko Sakkinen wrote:

On Fri, Jan 20, 2017 at 07:55:22PM +0200, Jarkko Sakkinen wrote:

On Fri, Jan 20, 2017 at 06:21:58PM +0200, Jarkko Sakkinen wrote:

On Fri, Jan 20, 2017 at 03:36:30PM +0200, Jarkko Sakkinen wrote:

On Thu, Jan 19, 2017 at 07:19:12AM -0500, Stefan Berger wrote:

Make sure that we have not received less bytes than what is indicated
in the header of the TPM response. Also, check the number of bytes in
the response before accessing its data.

Signed-off-by: Stefan Berger 

Reviewed-by: Jarkko Sakkinen 

Oops. I found some odd stuff after all so hold on for a moment.
I could do these updates myself probably...


  ssize_t tpm_transmit_cmd(struct tpm_chip *chip, const void *cmd,
-int len, unsigned int flags, const char *desc)
+size_t len, size_t min_rsp_body_length,
+unsigned int flags, const char *desc)

BTW, maybe the cmd_length would be actually a better idea because
it gets mixes witht local variable.


  {
const struct tpm_output_header *header;
int err;
+   ssize_t length;

Maybe it would make sense to name this as rsp_length.

  
-	len = tpm_transmit(chip, (const u8 *)cmd, len, flags);

-   if (len <  0)
-   return len;
-   else if (len < TPM_HEADER_SIZE)
+   length = tpm_transmit(chip, (const u8 *)cmd, len, flags);
+   if (length <  0)
+   return length;
+   else if (length < TPM_HEADER_SIZE)
return -EFAULT;
  
  	header = cmd;

+   if (length < be32_to_cpu(header->length))
+   return -EFAULT;

Why '<' and not '!='? In what legit case length would be larger?

  
  	err = be32_to_cpu(header->return_code);

if (err != 0 && desc)
dev_err(>dev, "A TPM error (%d) occurred %s\n", err,
desc);
+   if (err)
+   return err;
  
-	return err;

+   if (be32_to_cpu(header->length) <
+   min_rsp_body_length + TPM_HEADER_SIZE)
+   return -EFAULT;

Why couldn't you use 'length' here?

/Jarkko

Anyway,

Tested-by: Jarkko Sakkinen 

Stefan, I updated the patch by doing '!=' check and renaming parameters
to 'buf' and 'bufsiz' as they are in tpm_transmit(). The current namesd
did not make sense because you pass a buffer that will also will store
the response.

Can you check that after my updates it looks OK to you?


LGTM.

The != you introduced is correct (and stricter).

Re: [PATCH v7] tpm: Check size of response before accessing data

[Stefan Berger]

On 01/20/2017 03:14 PM, Jarkko Sakkinen wrote:

On Fri, Jan 20, 2017 at 07:55:22PM +0200, Jarkko Sakkinen wrote:

On Fri, Jan 20, 2017 at 06:21:58PM +0200, Jarkko Sakkinen wrote:

On Fri, Jan 20, 2017 at 03:36:30PM +0200, Jarkko Sakkinen wrote:

On Thu, Jan 19, 2017 at 07:19:12AM -0500, Stefan Berger wrote:

Make sure that we have not received less bytes than what is indicated
in the header of the TPM response. Also, check the number of bytes in
the response before accessing its data.

Signed-off-by: Stefan Berger 

Reviewed-by: Jarkko Sakkinen 

Oops. I found some odd stuff after all so hold on for a moment.
I could do these updates myself probably...


  ssize_t tpm_transmit_cmd(struct tpm_chip *chip, const void *cmd,
-int len, unsigned int flags, const char *desc)
+size_t len, size_t min_rsp_body_length,
+unsigned int flags, const char *desc)

BTW, maybe the cmd_length would be actually a better idea because
it gets mixes witht local variable.


  {
const struct tpm_output_header *header;
int err;
+   ssize_t length;

Maybe it would make sense to name this as rsp_length.

  
-	len = tpm_transmit(chip, (const u8 *)cmd, len, flags);

-   if (len <  0)
-   return len;
-   else if (len < TPM_HEADER_SIZE)
+   length = tpm_transmit(chip, (const u8 *)cmd, len, flags);
+   if (length <  0)
+   return length;
+   else if (length < TPM_HEADER_SIZE)
return -EFAULT;
  
  	header = cmd;

+   if (length < be32_to_cpu(header->length))
+   return -EFAULT;

Why '<' and not '!='? In what legit case length would be larger?

  
  	err = be32_to_cpu(header->return_code);

if (err != 0 && desc)
dev_err(>dev, "A TPM error (%d) occurred %s\n", err,
desc);
+   if (err)
+   return err;
  
-	return err;

+   if (be32_to_cpu(header->length) <
+   min_rsp_body_length + TPM_HEADER_SIZE)
+   return -EFAULT;

Why couldn't you use 'length' here?

/Jarkko

Anyway,

Tested-by: Jarkko Sakkinen 

Stefan, I updated the patch by doing '!=' check and renaming parameters
to 'buf' and 'bufsiz' as they are in tpm_transmit(). The current namesd
did not make sense because you pass a buffer that will also will store
the response.

Can you check that after my updates it looks OK to you?


LGTM.

The != you introduced is correct (and stricter).

Re: [PATCH v3 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

Hey Arnaldo,

On Thu, Jan 05, 2017 at 10:23:31PM -0800, Krister Johansen wrote:
> If dso__load_kcore frees all of the existing maps, but one has already
> been attached to a callchain cursor node, then we can get a SIGSEGV in
> any function that happens to try to use this invalid cursor.  Use the
> existing map refcount mechanism to forestall cleanup of a map until the
> cursor iterates past the node.

It's been a couple of weeks since I sent you the v3 of this patch.  Last
time I fiddled with it, I was able to reproduce your 'perf top' core,
and was able to verify that the latest patch I sent out could survive
running 'perf top' through the course of a full kernel build.

Is there anything else I can do to help with this one?

Thanks,

-K

Re: [PATCH v3 perf/core] perf script: fix a use after free crash.

[Krister Johansen]

Hey Arnaldo,

On Thu, Jan 05, 2017 at 10:23:31PM -0800, Krister Johansen wrote:
> If dso__load_kcore frees all of the existing maps, but one has already
> been attached to a callchain cursor node, then we can get a SIGSEGV in
> any function that happens to try to use this invalid cursor.  Use the
> existing map refcount mechanism to forestall cleanup of a map until the
> cursor iterates past the node.

It's been a couple of weeks since I sent you the v3 of this patch.  Last
time I fiddled with it, I was able to reproduce your 'perf top' core,
and was able to verify that the latest patch I sent out could survive
running 'perf top' through the course of a full kernel build.

Is there anything else I can do to help with this one?

Thanks,

-K

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[Thomas Garnier]

On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski  wrote:
> On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
>> Each processor holds a GDT in its per-cpu structure. The sgdt
>> instruction gives the base address of the current GDT. This address can
>> be used to bypass KASLR memory randomization. With another bug, an
>> attacker could target other per-cpu structures or deduce the base of
>> the main memory section (PAGE_OFFSET).
>>
>> This patch relocates the GDT table for each processor inside the
>> Fixmap section. The space is reserved based on number of supported
>> cpus.
>>
>> For consistency, the remapping is done by default on 32 and 64 bit.
>>
>> Each processor switches to its remapped GDT at the end of
>> initialization. For hibernation, the main processor returns with the
>> original GDT and switches back to the remapping at completion.
>>
>> On 32 bit, the maximum number of processors is now 256. The Fixmap
>> section cannot handle the original 512. Additional asserts ensure that
>> the Fixmap section cannot grow beyond the space available.
>>
>> This patch was tested on both architectures. Hibernation and KVM were
>> both tested specially for their usage of the GDT.
>>
>> Signed-off-by: Thomas Garnier 
>> ---
>> Based on next-20170119
>> ---
>>  arch/x86/Kconfig |  1 +
>>  arch/x86/include/asm/fixmap.h|  4 
>>  arch/x86/include/asm/processor.h |  1 +
>>  arch/x86/kernel/cpu/common.c | 18 +-
>>  arch/x86/mm/init_32.c|  2 ++
>>  arch/x86/power/cpu.c |  3 +++
>>  6 files changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index f1d4e8f2131f..b4ed35db10a8 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -912,6 +912,7 @@ config MAXSMP
>>  config NR_CPUS
>> int "Maximum number of CPUs" if SMP && !MAXSMP
>> range 2 8 if SMP && X86_32 && !X86_BIGSMP
>> +   range 2 256 if SMP && X86_32 && X86_BIGSMP
>> range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
>> range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
>> default "1" if !SMP
>> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
>> index c46289799b02..8b913b5e9383 100644
>> --- a/arch/x86/include/asm/fixmap.h
>> +++ b/arch/x86/include/asm/fixmap.h
>> @@ -100,6 +100,10 @@ enum fixed_addresses {
>>  #ifdef CONFIG_X86_INTEL_MID
>> FIX_LNW_VRTC,
>>  #endif
>> +   /* Fixmap entries to remap the GDTs, one per processor. */
>> +   FIX_GDT_REMAP_BEGIN,
>> +   FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
>> +
>> __end_of_permanent_fixed_addresses,
>>
>> /*
>> diff --git a/arch/x86/include/asm/processor.h 
>> b/arch/x86/include/asm/processor.h
>> index 1be64da0384e..280211ad8be9 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -705,6 +705,7 @@ extern struct desc_ptr  early_gdt_descr;
>>
>>  extern void cpu_set_gdt(int);
>>  extern void switch_to_new_gdt(int);
>> +extern void load_remapped_gdt(int);
>>  extern void load_percpu_segment(int);
>>  extern void cpu_init(void);
>>
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index e97ffc8d29f4..7d940b0e805a 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -443,6 +443,19 @@ void load_percpu_segment(int cpu)
>> load_stack_canary_segment();
>>  }
>>
>> +/* Load a fixmap remapping of the per-cpu GDT */
>> +void load_remapped_gdt(int cpu)
>> +{
>> +   struct desc_ptr gdt_descr;
>> +   unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
>> +
>> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
>> +
>> +   gdt_descr.address = (long)__fix_to_virt(idx);
>> +   gdt_descr.size = GDT_SIZE - 1;
>> +   load_gdt(_descr);
>> +}
>
> IMO this should be split into two functions, one to set up the fixmap
> entry and one to load the GDT.
>

That make sense.

> Also, would it be possible to rename the various gdt helpers so that
> their functionality is more obvious?  For example, get_cpu_gdt_table()
> could be get_cpu_direct_gdt_table() and the function to load the gdt
> could be load_fixmap_gdt().
>

Sure no problem.

> --Andy



-- 
Thomas

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[Thomas Garnier]

On Fri, Jan 20, 2017 at 4:57 PM, Andy Lutomirski  wrote:
> On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
>> Each processor holds a GDT in its per-cpu structure. The sgdt
>> instruction gives the base address of the current GDT. This address can
>> be used to bypass KASLR memory randomization. With another bug, an
>> attacker could target other per-cpu structures or deduce the base of
>> the main memory section (PAGE_OFFSET).
>>
>> This patch relocates the GDT table for each processor inside the
>> Fixmap section. The space is reserved based on number of supported
>> cpus.
>>
>> For consistency, the remapping is done by default on 32 and 64 bit.
>>
>> Each processor switches to its remapped GDT at the end of
>> initialization. For hibernation, the main processor returns with the
>> original GDT and switches back to the remapping at completion.
>>
>> On 32 bit, the maximum number of processors is now 256. The Fixmap
>> section cannot handle the original 512. Additional asserts ensure that
>> the Fixmap section cannot grow beyond the space available.
>>
>> This patch was tested on both architectures. Hibernation and KVM were
>> both tested specially for their usage of the GDT.
>>
>> Signed-off-by: Thomas Garnier 
>> ---
>> Based on next-20170119
>> ---
>>  arch/x86/Kconfig |  1 +
>>  arch/x86/include/asm/fixmap.h|  4 
>>  arch/x86/include/asm/processor.h |  1 +
>>  arch/x86/kernel/cpu/common.c | 18 +-
>>  arch/x86/mm/init_32.c|  2 ++
>>  arch/x86/power/cpu.c |  3 +++
>>  6 files changed, 28 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index f1d4e8f2131f..b4ed35db10a8 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -912,6 +912,7 @@ config MAXSMP
>>  config NR_CPUS
>> int "Maximum number of CPUs" if SMP && !MAXSMP
>> range 2 8 if SMP && X86_32 && !X86_BIGSMP
>> +   range 2 256 if SMP && X86_32 && X86_BIGSMP
>> range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
>> range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
>> default "1" if !SMP
>> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
>> index c46289799b02..8b913b5e9383 100644
>> --- a/arch/x86/include/asm/fixmap.h
>> +++ b/arch/x86/include/asm/fixmap.h
>> @@ -100,6 +100,10 @@ enum fixed_addresses {
>>  #ifdef CONFIG_X86_INTEL_MID
>> FIX_LNW_VRTC,
>>  #endif
>> +   /* Fixmap entries to remap the GDTs, one per processor. */
>> +   FIX_GDT_REMAP_BEGIN,
>> +   FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
>> +
>> __end_of_permanent_fixed_addresses,
>>
>> /*
>> diff --git a/arch/x86/include/asm/processor.h 
>> b/arch/x86/include/asm/processor.h
>> index 1be64da0384e..280211ad8be9 100644
>> --- a/arch/x86/include/asm/processor.h
>> +++ b/arch/x86/include/asm/processor.h
>> @@ -705,6 +705,7 @@ extern struct desc_ptr  early_gdt_descr;
>>
>>  extern void cpu_set_gdt(int);
>>  extern void switch_to_new_gdt(int);
>> +extern void load_remapped_gdt(int);
>>  extern void load_percpu_segment(int);
>>  extern void cpu_init(void);
>>
>> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
>> index e97ffc8d29f4..7d940b0e805a 100644
>> --- a/arch/x86/kernel/cpu/common.c
>> +++ b/arch/x86/kernel/cpu/common.c
>> @@ -443,6 +443,19 @@ void load_percpu_segment(int cpu)
>> load_stack_canary_segment();
>>  }
>>
>> +/* Load a fixmap remapping of the per-cpu GDT */
>> +void load_remapped_gdt(int cpu)
>> +{
>> +   struct desc_ptr gdt_descr;
>> +   unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
>> +
>> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
>> +
>> +   gdt_descr.address = (long)__fix_to_virt(idx);
>> +   gdt_descr.size = GDT_SIZE - 1;
>> +   load_gdt(_descr);
>> +}
>
> IMO this should be split into two functions, one to set up the fixmap
> entry and one to load the GDT.
>

That make sense.

> Also, would it be possible to rename the various gdt helpers so that
> their functionality is more obvious?  For example, get_cpu_gdt_table()
> could be get_cpu_direct_gdt_table() and the function to load the gdt
> could be load_fixmap_gdt().
>

Sure no problem.

> --Andy



-- 
Thomas

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

[Thomas Garnier]

On Fri, Jan 20, 2017 at 5:06 PM, Andy Lutomirski  wrote:
> On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
>> This patch makes the GDT remapped pages read-only to prevent corruption.
>> This change is done only on 64 bit.
>>
>> The native_load_tr_desc function was adapted to correctly handle a
>> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
>> This generates a page fault if the GDT is read-only. This change checks
>> if the current GDT is a remap and swap GDTs as needed. This function was
>> tested by booting multiple machines and checking hibernation works
>> properly.
>>
>> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the GDT
>> description and writeble address were put in two per-cpu variables for
>> convenience. For testing, VMs were started and restored on multiple
>> configurations.
>>
>> Signed-off-by: Thomas Garnier 
>> ---
>> Based on next-20170119
>> ---
>>  arch/x86/include/asm/desc.h  | 44 
>> +++-
>>  arch/x86/include/asm/processor.h |  1 +
>>  arch/x86/kernel/cpu/common.c | 36 ++--
>>  arch/x86/kvm/svm.c   |  5 ++---
>>  arch/x86/kvm/vmx.c   | 23 +
>>  5 files changed, 86 insertions(+), 23 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
>> index 12080d87da3b..6ed68d449c7b 100644
>> --- a/arch/x86/include/asm/desc.h
>> +++ b/arch/x86/include/asm/desc.h
>> @@ -50,6 +50,13 @@ static inline struct desc_struct 
>> *get_cpu_gdt_table(unsigned int cpu)
>> return per_cpu(gdt_page, cpu).gdt;
>>  }
>>
>> +static inline struct desc_struct *get_current_gdt_table(void)
>> +{
>> +   return get_cpu_var(gdt_page).gdt;
>> +}
>
> This function is poorly named IMO.  Which GDT address does it return?
> Can we call it get_current_direct_gdt()?  Also, IIRC
> this_cpu_read(gdt_page.gdt) generates better code.
>

I agree. I will use this_cpu_read and rename the function.

>> +
>> +struct desc_struct *get_remapped_gdt(int cpu);
>
> And get_current_fixmap_gdt(void) perhaps?  And why isn't it inline?
> It's very simple.
>

I was not sure about the KVM dependencies on fixmap. It should be
alright, I will add it to desc.h.

>> +/*
>> + * The LTR instruction marks the TSS GDT entry as busy. In 64bit, the GDT is
>> + * a read-only remapping. To prevent a page fault, the GDT is switched to 
>> the
>> + * original writeable version when needed.
>> + */
>> +#ifdef CONFIG_X86_64
>> +static inline void native_load_tr_desc(void)
>> +{
>> +   struct desc_ptr gdt;
>> +   int cpu = raw_smp_processor_id();
>> +   bool restore = false;
>> +   struct desc_struct *remapped_gdt;
>> +
>> +   native_store_gdt();
>> +   remapped_gdt = get_remapped_gdt(cpu);
>> +
>> +   /* Swap and restore only if the current GDT is the remap. */
>> +   if (gdt.address == (unsigned long)remapped_gdt) {
>> +   load_percpu_gdt(cpu);
>
> This line (load_percpu_gdt(cpu)) is hard to understand because of the
> poorly named function.
>

It should make more sense with direct/fixmap naming.

>>  /* Load a fixmap remapping of the per-cpu GDT */
>>  void load_remapped_gdt(int cpu)
>>  {
>> struct desc_ptr gdt_descr;
>> unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
>>
>> -   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
>> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), GDT_REMAP_PROT);
>
> How about PAGE_FIXMAP_GDT instead of GDT_REMAP_PROT?
>

Sure.

>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index d0414f054bdf..da261f231017 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -741,7 +741,6 @@ static int svm_hardware_enable(void)
>>
>> struct svm_cpu_data *sd;
>> uint64_t efer;
>> -   struct desc_ptr gdt_descr;
>> struct desc_struct *gdt;
>> int me = raw_smp_processor_id();
>>
>> @@ -763,8 +762,7 @@ static int svm_hardware_enable(void)
>> sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
>> sd->next_asid = sd->max_asid + 1;
>>
>> -   native_store_gdt(_descr);
>> -   gdt = (struct desc_struct *)gdt_descr.address;
>> +   gdt = get_current_gdt_table();
>> sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
>>
>> wrmsrl(MSR_EFER, efer | EFER_SVME);
>> @@ -4251,6 +4249,7 @@ static void reload_tss(struct kvm_vcpu *vcpu)
>>
>> struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
>> sd->tss_desc->type = 9; /* available 32/64-bit TSS */
>> +
>> load_TR_desc();
>>  }
>
> Paulo, are you okay with the performance hit here?  Is there any easy
> way to avoid it?
>
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index d2fe3a51876c..acbf78c962d0 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -935,7 +935,8 @@ static DEFINE_PER_CPU(struct 

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

[Andy Lutomirski]

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64 bit.
>
> The native_load_tr_desc function was adapted to correctly handle a
> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
> This generates a page fault if the GDT is read-only. This change checks
> if the current GDT is a remap and swap GDTs as needed. This function was
> tested by booting multiple machines and checking hibernation works
> properly.
>
> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the GDT
> description and writeble address were put in two per-cpu variables for
> convenience. For testing, VMs were started and restored on multiple
> configurations.
>
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20170119
> ---
>  arch/x86/include/asm/desc.h  | 44 
> +++-
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/common.c | 36 ++--
>  arch/x86/kvm/svm.c   |  5 ++---
>  arch/x86/kvm/vmx.c   | 23 +
>  5 files changed, 86 insertions(+), 23 deletions(-)
>
> diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
> index 12080d87da3b..6ed68d449c7b 100644
> --- a/arch/x86/include/asm/desc.h
> +++ b/arch/x86/include/asm/desc.h
> @@ -50,6 +50,13 @@ static inline struct desc_struct 
> *get_cpu_gdt_table(unsigned int cpu)
> return per_cpu(gdt_page, cpu).gdt;
>  }
>
> +static inline struct desc_struct *get_current_gdt_table(void)
> +{
> +   return get_cpu_var(gdt_page).gdt;
> +}

This function is poorly named IMO.  Which GDT address does it return?
Can we call it get_current_direct_gdt()?  Also, IIRC
this_cpu_read(gdt_page.gdt) generates better code.

> +
> +struct desc_struct *get_remapped_gdt(int cpu);

And get_current_fixmap_gdt(void) perhaps?  And why isn't it inline?
It's very simple.

> +/*
> + * The LTR instruction marks the TSS GDT entry as busy. In 64bit, the GDT is
> + * a read-only remapping. To prevent a page fault, the GDT is switched to the
> + * original writeable version when needed.
> + */
> +#ifdef CONFIG_X86_64
> +static inline void native_load_tr_desc(void)
> +{
> +   struct desc_ptr gdt;
> +   int cpu = raw_smp_processor_id();
> +   bool restore = false;
> +   struct desc_struct *remapped_gdt;
> +
> +   native_store_gdt();
> +   remapped_gdt = get_remapped_gdt(cpu);
> +
> +   /* Swap and restore only if the current GDT is the remap. */
> +   if (gdt.address == (unsigned long)remapped_gdt) {
> +   load_percpu_gdt(cpu);

This line (load_percpu_gdt(cpu)) is hard to understand because of the
poorly named function.

>  /* Load a fixmap remapping of the per-cpu GDT */
>  void load_remapped_gdt(int cpu)
>  {
> struct desc_ptr gdt_descr;
> unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
>
> -   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), GDT_REMAP_PROT);

How about PAGE_FIXMAP_GDT instead of GDT_REMAP_PROT?

> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index d0414f054bdf..da261f231017 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -741,7 +741,6 @@ static int svm_hardware_enable(void)
>
> struct svm_cpu_data *sd;
> uint64_t efer;
> -   struct desc_ptr gdt_descr;
> struct desc_struct *gdt;
> int me = raw_smp_processor_id();
>
> @@ -763,8 +762,7 @@ static int svm_hardware_enable(void)
> sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
> sd->next_asid = sd->max_asid + 1;
>
> -   native_store_gdt(_descr);
> -   gdt = (struct desc_struct *)gdt_descr.address;
> +   gdt = get_current_gdt_table();
> sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
>
> wrmsrl(MSR_EFER, efer | EFER_SVME);
> @@ -4251,6 +4249,7 @@ static void reload_tss(struct kvm_vcpu *vcpu)
>
> struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
> sd->tss_desc->type = 9; /* available 32/64-bit TSS */
> +
> load_TR_desc();
>  }

Paulo, are you okay with the performance hit here?  Is there any easy
way to avoid it?

>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index d2fe3a51876c..acbf78c962d0 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -935,7 +935,8 @@ static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
>   * when a CPU is brought down, and we need to VMCLEAR all VMCSs loaded on it.
>   */
>  static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
> -static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
> +static DEFINE_PER_CPU(struct desc_ptr, host_gdt_desc);
> +static DEFINE_PER_CPU(unsigned long, host_gdt);

This pair of variables is inscrutible IMO.  It should at least have a
comment, but better names would help 

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

[Thomas Garnier]

On Fri, Jan 20, 2017 at 5:06 PM, Andy Lutomirski  wrote:
> On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
>> This patch makes the GDT remapped pages read-only to prevent corruption.
>> This change is done only on 64 bit.
>>
>> The native_load_tr_desc function was adapted to correctly handle a
>> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
>> This generates a page fault if the GDT is read-only. This change checks
>> if the current GDT is a remap and swap GDTs as needed. This function was
>> tested by booting multiple machines and checking hibernation works
>> properly.
>>
>> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the GDT
>> description and writeble address were put in two per-cpu variables for
>> convenience. For testing, VMs were started and restored on multiple
>> configurations.
>>
>> Signed-off-by: Thomas Garnier 
>> ---
>> Based on next-20170119
>> ---
>>  arch/x86/include/asm/desc.h  | 44 
>> +++-
>>  arch/x86/include/asm/processor.h |  1 +
>>  arch/x86/kernel/cpu/common.c | 36 ++--
>>  arch/x86/kvm/svm.c   |  5 ++---
>>  arch/x86/kvm/vmx.c   | 23 +
>>  5 files changed, 86 insertions(+), 23 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
>> index 12080d87da3b..6ed68d449c7b 100644
>> --- a/arch/x86/include/asm/desc.h
>> +++ b/arch/x86/include/asm/desc.h
>> @@ -50,6 +50,13 @@ static inline struct desc_struct 
>> *get_cpu_gdt_table(unsigned int cpu)
>> return per_cpu(gdt_page, cpu).gdt;
>>  }
>>
>> +static inline struct desc_struct *get_current_gdt_table(void)
>> +{
>> +   return get_cpu_var(gdt_page).gdt;
>> +}
>
> This function is poorly named IMO.  Which GDT address does it return?
> Can we call it get_current_direct_gdt()?  Also, IIRC
> this_cpu_read(gdt_page.gdt) generates better code.
>

I agree. I will use this_cpu_read and rename the function.

>> +
>> +struct desc_struct *get_remapped_gdt(int cpu);
>
> And get_current_fixmap_gdt(void) perhaps?  And why isn't it inline?
> It's very simple.
>

I was not sure about the KVM dependencies on fixmap. It should be
alright, I will add it to desc.h.

>> +/*
>> + * The LTR instruction marks the TSS GDT entry as busy. In 64bit, the GDT is
>> + * a read-only remapping. To prevent a page fault, the GDT is switched to 
>> the
>> + * original writeable version when needed.
>> + */
>> +#ifdef CONFIG_X86_64
>> +static inline void native_load_tr_desc(void)
>> +{
>> +   struct desc_ptr gdt;
>> +   int cpu = raw_smp_processor_id();
>> +   bool restore = false;
>> +   struct desc_struct *remapped_gdt;
>> +
>> +   native_store_gdt();
>> +   remapped_gdt = get_remapped_gdt(cpu);
>> +
>> +   /* Swap and restore only if the current GDT is the remap. */
>> +   if (gdt.address == (unsigned long)remapped_gdt) {
>> +   load_percpu_gdt(cpu);
>
> This line (load_percpu_gdt(cpu)) is hard to understand because of the
> poorly named function.
>

It should make more sense with direct/fixmap naming.

>>  /* Load a fixmap remapping of the per-cpu GDT */
>>  void load_remapped_gdt(int cpu)
>>  {
>> struct desc_ptr gdt_descr;
>> unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
>>
>> -   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
>> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), GDT_REMAP_PROT);
>
> How about PAGE_FIXMAP_GDT instead of GDT_REMAP_PROT?
>

Sure.

>> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
>> index d0414f054bdf..da261f231017 100644
>> --- a/arch/x86/kvm/svm.c
>> +++ b/arch/x86/kvm/svm.c
>> @@ -741,7 +741,6 @@ static int svm_hardware_enable(void)
>>
>> struct svm_cpu_data *sd;
>> uint64_t efer;
>> -   struct desc_ptr gdt_descr;
>> struct desc_struct *gdt;
>> int me = raw_smp_processor_id();
>>
>> @@ -763,8 +762,7 @@ static int svm_hardware_enable(void)
>> sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
>> sd->next_asid = sd->max_asid + 1;
>>
>> -   native_store_gdt(_descr);
>> -   gdt = (struct desc_struct *)gdt_descr.address;
>> +   gdt = get_current_gdt_table();
>> sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
>>
>> wrmsrl(MSR_EFER, efer | EFER_SVME);
>> @@ -4251,6 +4249,7 @@ static void reload_tss(struct kvm_vcpu *vcpu)
>>
>> struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
>> sd->tss_desc->type = 9; /* available 32/64-bit TSS */
>> +
>> load_TR_desc();
>>  }
>
> Paulo, are you okay with the performance hit here?  Is there any easy
> way to avoid it?
>
>>
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index d2fe3a51876c..acbf78c962d0 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -935,7 +935,8 @@ static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
>>   * when a CPU is brought down, and we 

Re: [PATCH v1 3/3] x86: Make the GDT remapping read-only on 64 bit

[Andy Lutomirski]

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64 bit.
>
> The native_load_tr_desc function was adapted to correctly handle a
> read-only GDT. The LTR instruction always writes to the GDT TSS entry.
> This generates a page fault if the GDT is read-only. This change checks
> if the current GDT is a remap and swap GDTs as needed. This function was
> tested by booting multiple machines and checking hibernation works
> properly.
>
> KVM SVM and VMX were adapted to use the writeable GDT. On VMX, the GDT
> description and writeble address were put in two per-cpu variables for
> convenience. For testing, VMs were started and restored on multiple
> configurations.
>
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20170119
> ---
>  arch/x86/include/asm/desc.h  | 44 
> +++-
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/common.c | 36 ++--
>  arch/x86/kvm/svm.c   |  5 ++---
>  arch/x86/kvm/vmx.c   | 23 +
>  5 files changed, 86 insertions(+), 23 deletions(-)
>
> diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
> index 12080d87da3b..6ed68d449c7b 100644
> --- a/arch/x86/include/asm/desc.h
> +++ b/arch/x86/include/asm/desc.h
> @@ -50,6 +50,13 @@ static inline struct desc_struct 
> *get_cpu_gdt_table(unsigned int cpu)
> return per_cpu(gdt_page, cpu).gdt;
>  }
>
> +static inline struct desc_struct *get_current_gdt_table(void)
> +{
> +   return get_cpu_var(gdt_page).gdt;
> +}

This function is poorly named IMO.  Which GDT address does it return?
Can we call it get_current_direct_gdt()?  Also, IIRC
this_cpu_read(gdt_page.gdt) generates better code.

> +
> +struct desc_struct *get_remapped_gdt(int cpu);

And get_current_fixmap_gdt(void) perhaps?  And why isn't it inline?
It's very simple.

> +/*
> + * The LTR instruction marks the TSS GDT entry as busy. In 64bit, the GDT is
> + * a read-only remapping. To prevent a page fault, the GDT is switched to the
> + * original writeable version when needed.
> + */
> +#ifdef CONFIG_X86_64
> +static inline void native_load_tr_desc(void)
> +{
> +   struct desc_ptr gdt;
> +   int cpu = raw_smp_processor_id();
> +   bool restore = false;
> +   struct desc_struct *remapped_gdt;
> +
> +   native_store_gdt();
> +   remapped_gdt = get_remapped_gdt(cpu);
> +
> +   /* Swap and restore only if the current GDT is the remap. */
> +   if (gdt.address == (unsigned long)remapped_gdt) {
> +   load_percpu_gdt(cpu);

This line (load_percpu_gdt(cpu)) is hard to understand because of the
poorly named function.

>  /* Load a fixmap remapping of the per-cpu GDT */
>  void load_remapped_gdt(int cpu)
>  {
> struct desc_ptr gdt_descr;
> unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
>
> -   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), GDT_REMAP_PROT);

How about PAGE_FIXMAP_GDT instead of GDT_REMAP_PROT?

> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index d0414f054bdf..da261f231017 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -741,7 +741,6 @@ static int svm_hardware_enable(void)
>
> struct svm_cpu_data *sd;
> uint64_t efer;
> -   struct desc_ptr gdt_descr;
> struct desc_struct *gdt;
> int me = raw_smp_processor_id();
>
> @@ -763,8 +762,7 @@ static int svm_hardware_enable(void)
> sd->max_asid = cpuid_ebx(SVM_CPUID_FUNC) - 1;
> sd->next_asid = sd->max_asid + 1;
>
> -   native_store_gdt(_descr);
> -   gdt = (struct desc_struct *)gdt_descr.address;
> +   gdt = get_current_gdt_table();
> sd->tss_desc = (struct kvm_ldttss_desc *)(gdt + GDT_ENTRY_TSS);
>
> wrmsrl(MSR_EFER, efer | EFER_SVME);
> @@ -4251,6 +4249,7 @@ static void reload_tss(struct kvm_vcpu *vcpu)
>
> struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
> sd->tss_desc->type = 9; /* available 32/64-bit TSS */
> +
> load_TR_desc();
>  }

Paulo, are you okay with the performance hit here?  Is there any easy
way to avoid it?

>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index d2fe3a51876c..acbf78c962d0 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -935,7 +935,8 @@ static DEFINE_PER_CPU(struct vmcs *, current_vmcs);
>   * when a CPU is brought down, and we need to VMCLEAR all VMCSs loaded on it.
>   */
>  static DEFINE_PER_CPU(struct list_head, loaded_vmcss_on_cpu);
> -static DEFINE_PER_CPU(struct desc_ptr, host_gdt);
> +static DEFINE_PER_CPU(struct desc_ptr, host_gdt_desc);
> +static DEFINE_PER_CPU(unsigned long, host_gdt);

This pair of variables is inscrutible IMO.  It should at least have a
comment, but better names would help even more.

>
>  /*
>   * We maintian a 

Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs

[Chen-Yu Tsai]

Hi,

On Thu, Jan 12, 2017 at 5:28 PM, Maxime Ripard
 wrote:
> On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote:
>> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
>> VBUS power supply for both max current and min voltage supplied. This
>> series of patch adds the possibility to set these limits from sysfs.
>>
>> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
>> the former can set the VBUS power supply max current to 100mA, unlike
>> the latter. The AXP223 VBUS power supply driver used to probe on the
>> AXP221 compatible. This series of patch introduces a new compatible for
>> the AXP223 to be able to set the current max limit to 100mA.
>>
>> With that new compatible, boards having the AXP223 see their DT updated
>> to use the VBUS power supply driver with the correct compatible.
>>
>> This series of patch also migrates from of_device_is_compatible function
>> to the data field of of_device_id to identify the compatible used to
>> probe. This improves the code readability.
>>
>> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
>> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
>
> Applied all the DT patches. I also fixed all the prefixes. Please make
> sure to look at what prefixes are used by a given subsystem next time.

I'm not seeing the DT patches. FYI the old DT does not work with the
new kernel driver updates. Because of the new AXP223 specific compatible
for the usb-power-supply, the updated mfd driver cannot match the old
device node, and the probe will fail at

if (!of_device_is_available(pdev->dev.of_node))
return -ENODEV;

I don't see an easy way out of this though. The mfd_cell structure only
takes one compatible string.

Regards
ChenYu

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

Re: [PATCH v2 00/11] add support for VBUS max current and min voltage limits AXP20X and AXP22X PMICs

[Chen-Yu Tsai]

Hi,

On Thu, Jan 12, 2017 at 5:28 PM, Maxime Ripard
 wrote:
> On Fri, Dec 09, 2016 at 12:04:08PM +0100, Quentin Schulz wrote:
>> The X-Powers AXP209 and AXP20X PMICs are able to set a limit for the
>> VBUS power supply for both max current and min voltage supplied. This
>> series of patch adds the possibility to set these limits from sysfs.
>>
>> Also, the AXP223 PMIC shares most of its behaviour with the AXP221 but
>> the former can set the VBUS power supply max current to 100mA, unlike
>> the latter. The AXP223 VBUS power supply driver used to probe on the
>> AXP221 compatible. This series of patch introduces a new compatible for
>> the AXP223 to be able to set the current max limit to 100mA.
>>
>> With that new compatible, boards having the AXP223 see their DT updated
>> to use the VBUS power supply driver with the correct compatible.
>>
>> This series of patch also migrates from of_device_is_compatible function
>> to the data field of of_device_id to identify the compatible used to
>> probe. This improves the code readability.
>>
>> Mostly cosmetic changes in v2 and adding volatile and writeable regs to
>> AXP20X and AXP22X MFD cells for the VBUS power supply driver.
>
> Applied all the DT patches. I also fixed all the prefixes. Please make
> sure to look at what prefixes are used by a given subsystem next time.

I'm not seeing the DT patches. FYI the old DT does not work with the
new kernel driver updates. Because of the new AXP223 specific compatible
for the usb-power-supply, the updated mfd driver cannot match the old
device node, and the probe will fail at

if (!of_device_is_available(pdev->dev.of_node))
return -ENODEV;

I don't see an easy way out of this though. The mfd_cell structure only
takes one compatible string.

Regards
ChenYu

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

[PATCH RESEND] staging: media: lirc: use new parport device model

[Sudip Mukherjee]

From: Sudip Mukherjee 

Modify lirc_parallel driver to use the new parallel port device model.

Signed-off-by: Sudip Mukherjee 
---

Resending after more than one year.
Prevoius patch is at https://patchwork.kernel.org/patch/7883591/

 drivers/staging/media/lirc/lirc_parallel.c | 93 --
 1 file changed, 62 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index bfb76a4..0a43bac2b 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -626,41 +626,26 @@ static void kf(void *handle)
 
 /*** module initialization and cleanup ***/
 
-static int __init lirc_parallel_init(void)
+static void lirc_parallel_attach(struct parport *port)
 {
-   int result;
-
-   result = platform_driver_register(_parallel_driver);
-   if (result) {
-   pr_notice("platform_driver_register returned %d\n", result);
-   return result;
-   }
+   struct pardev_cb lirc_parallel_cb;
 
-   lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
-   if (!lirc_parallel_dev) {
-   result = -ENOMEM;
-   goto exit_driver_unregister;
-   }
+   if (port->base != io)
+   return;
 
-   result = platform_device_add(lirc_parallel_dev);
-   if (result)
-   goto exit_device_put;
+   pport = port;
+   memset(_parallel_cb, 0, sizeof(lirc_parallel_cb));
+   lirc_parallel_cb.preempt = pf;
+   lirc_parallel_cb.wakeup = kf;
+   lirc_parallel_cb.irq_func = lirc_lirc_irq_handler;
 
-   pport = parport_find_base(io);
-   if (!pport) {
-   pr_notice("no port at %x found\n", io);
-   result = -ENXIO;
-   goto exit_device_del;
-   }
-   ppdevice = parport_register_device(pport, LIRC_DRIVER_NAME,
-  pf, kf, lirc_lirc_irq_handler, 0,
-  NULL);
-   parport_put_port(pport);
+   ppdevice = parport_register_dev_model(port, LIRC_DRIVER_NAME,
+ _parallel_cb, 0);
if (!ppdevice) {
pr_notice("parport_register_device() failed\n");
-   result = -ENXIO;
-   goto exit_device_del;
+   return;
}
+
if (parport_claim(ppdevice) != 0)
goto skip_init;
is_claimed = 1;
@@ -688,18 +673,64 @@ static int __init lirc_parallel_init(void)
 
is_claimed = 0;
parport_release(ppdevice);
+
  skip_init:
+   return;
+}
+
+static void lirc_parallel_detach(struct parport *port)
+{
+   if (port->base != io)
+   return;
+
+   parport_unregister_device(ppdevice);
+}
+
+static struct parport_driver lirc_parport_driver = {
+   .name = LIRC_DRIVER_NAME,
+   .match_port = lirc_parallel_attach,
+   .detach = lirc_parallel_detach,
+   .devmodel = true,
+};
+
+static int __init lirc_parallel_init(void)
+{
+   int result;
+
+   result = platform_driver_register(_parallel_driver);
+   if (result) {
+   pr_notice("platform_driver_register returned %d\n", result);
+   return result;
+   }
+
+   lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
+   if (!lirc_parallel_dev) {
+   result = -ENOMEM;
+   goto exit_driver_unregister;
+   }
+
+   result = platform_device_add(lirc_parallel_dev);
+   if (result)
+   goto exit_device_put;
+
+   result = parport_register_driver(_parport_driver);
+   if (result) {
+   pr_notice("parport_register_driver returned %d\n", result);
+   goto exit_device_del;
+   }
+
driver.dev = _parallel_dev->dev;
driver.minor = lirc_register_driver();
if (driver.minor < 0) {
pr_notice("register_chrdev() failed\n");
-   parport_unregister_device(ppdevice);
result = -EIO;
-   goto exit_device_del;
+   goto exit_unregister;
}
pr_info("installed using port 0x%04x irq %d\n", io, irq);
return 0;
 
+exit_unregister:
+   parport_unregister_driver(_parport_driver);
 exit_device_del:
platform_device_del(lirc_parallel_dev);
 exit_device_put:
@@ -711,9 +742,9 @@ static int __init lirc_parallel_init(void)
 
 static void __exit lirc_parallel_exit(void)
 {
-   parport_unregister_device(ppdevice);
lirc_unregister_driver(driver.minor);
 
+   parport_unregister_driver(_parport_driver);
platform_device_unregister(lirc_parallel_dev);
platform_driver_unregister(_parallel_driver);
 }
-- 
1.9.1

[PATCH RESEND] staging: media: lirc: use new parport device model

[Sudip Mukherjee]

From: Sudip Mukherjee 

Modify lirc_parallel driver to use the new parallel port device model.

Signed-off-by: Sudip Mukherjee 
---

Resending after more than one year.
Prevoius patch is at https://patchwork.kernel.org/patch/7883591/

 drivers/staging/media/lirc/lirc_parallel.c | 93 --
 1 file changed, 62 insertions(+), 31 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index bfb76a4..0a43bac2b 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -626,41 +626,26 @@ static void kf(void *handle)
 
 /*** module initialization and cleanup ***/
 
-static int __init lirc_parallel_init(void)
+static void lirc_parallel_attach(struct parport *port)
 {
-   int result;
-
-   result = platform_driver_register(_parallel_driver);
-   if (result) {
-   pr_notice("platform_driver_register returned %d\n", result);
-   return result;
-   }
+   struct pardev_cb lirc_parallel_cb;
 
-   lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
-   if (!lirc_parallel_dev) {
-   result = -ENOMEM;
-   goto exit_driver_unregister;
-   }
+   if (port->base != io)
+   return;
 
-   result = platform_device_add(lirc_parallel_dev);
-   if (result)
-   goto exit_device_put;
+   pport = port;
+   memset(_parallel_cb, 0, sizeof(lirc_parallel_cb));
+   lirc_parallel_cb.preempt = pf;
+   lirc_parallel_cb.wakeup = kf;
+   lirc_parallel_cb.irq_func = lirc_lirc_irq_handler;
 
-   pport = parport_find_base(io);
-   if (!pport) {
-   pr_notice("no port at %x found\n", io);
-   result = -ENXIO;
-   goto exit_device_del;
-   }
-   ppdevice = parport_register_device(pport, LIRC_DRIVER_NAME,
-  pf, kf, lirc_lirc_irq_handler, 0,
-  NULL);
-   parport_put_port(pport);
+   ppdevice = parport_register_dev_model(port, LIRC_DRIVER_NAME,
+ _parallel_cb, 0);
if (!ppdevice) {
pr_notice("parport_register_device() failed\n");
-   result = -ENXIO;
-   goto exit_device_del;
+   return;
}
+
if (parport_claim(ppdevice) != 0)
goto skip_init;
is_claimed = 1;
@@ -688,18 +673,64 @@ static int __init lirc_parallel_init(void)
 
is_claimed = 0;
parport_release(ppdevice);
+
  skip_init:
+   return;
+}
+
+static void lirc_parallel_detach(struct parport *port)
+{
+   if (port->base != io)
+   return;
+
+   parport_unregister_device(ppdevice);
+}
+
+static struct parport_driver lirc_parport_driver = {
+   .name = LIRC_DRIVER_NAME,
+   .match_port = lirc_parallel_attach,
+   .detach = lirc_parallel_detach,
+   .devmodel = true,
+};
+
+static int __init lirc_parallel_init(void)
+{
+   int result;
+
+   result = platform_driver_register(_parallel_driver);
+   if (result) {
+   pr_notice("platform_driver_register returned %d\n", result);
+   return result;
+   }
+
+   lirc_parallel_dev = platform_device_alloc(LIRC_DRIVER_NAME, 0);
+   if (!lirc_parallel_dev) {
+   result = -ENOMEM;
+   goto exit_driver_unregister;
+   }
+
+   result = platform_device_add(lirc_parallel_dev);
+   if (result)
+   goto exit_device_put;
+
+   result = parport_register_driver(_parport_driver);
+   if (result) {
+   pr_notice("parport_register_driver returned %d\n", result);
+   goto exit_device_del;
+   }
+
driver.dev = _parallel_dev->dev;
driver.minor = lirc_register_driver();
if (driver.minor < 0) {
pr_notice("register_chrdev() failed\n");
-   parport_unregister_device(ppdevice);
result = -EIO;
-   goto exit_device_del;
+   goto exit_unregister;
}
pr_info("installed using port 0x%04x irq %d\n", io, irq);
return 0;
 
+exit_unregister:
+   parport_unregister_driver(_parport_driver);
 exit_device_del:
platform_device_del(lirc_parallel_dev);
 exit_device_put:
@@ -711,9 +742,9 @@ static int __init lirc_parallel_init(void)
 
 static void __exit lirc_parallel_exit(void)
 {
-   parport_unregister_device(ppdevice);
lirc_unregister_driver(driver.minor);
 
+   parport_unregister_driver(_parport_driver);
platform_device_unregister(lirc_parallel_dev);
platform_driver_unregister(_parallel_driver);
 }
-- 
1.9.1

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[Andy Lutomirski]

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> cpus.
>
> For consistency, the remapping is done by default on 32 and 64 bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> On 32 bit, the maximum number of processors is now 256. The Fixmap
> section cannot handle the original 512. Additional asserts ensure that
> the Fixmap section cannot grow beyond the space available.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.
>
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20170119
> ---
>  arch/x86/Kconfig |  1 +
>  arch/x86/include/asm/fixmap.h|  4 
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/common.c | 18 +-
>  arch/x86/mm/init_32.c|  2 ++
>  arch/x86/power/cpu.c |  3 +++
>  6 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f1d4e8f2131f..b4ed35db10a8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -912,6 +912,7 @@ config MAXSMP
>  config NR_CPUS
> int "Maximum number of CPUs" if SMP && !MAXSMP
> range 2 8 if SMP && X86_32 && !X86_BIGSMP
> +   range 2 256 if SMP && X86_32 && X86_BIGSMP
> range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
> range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
> default "1" if !SMP
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index c46289799b02..8b913b5e9383 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -100,6 +100,10 @@ enum fixed_addresses {
>  #ifdef CONFIG_X86_INTEL_MID
> FIX_LNW_VRTC,
>  #endif
> +   /* Fixmap entries to remap the GDTs, one per processor. */
> +   FIX_GDT_REMAP_BEGIN,
> +   FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
> +
> __end_of_permanent_fixed_addresses,
>
> /*
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 1be64da0384e..280211ad8be9 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -705,6 +705,7 @@ extern struct desc_ptr  early_gdt_descr;
>
>  extern void cpu_set_gdt(int);
>  extern void switch_to_new_gdt(int);
> +extern void load_remapped_gdt(int);
>  extern void load_percpu_segment(int);
>  extern void cpu_init(void);
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e97ffc8d29f4..7d940b0e805a 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -443,6 +443,19 @@ void load_percpu_segment(int cpu)
> load_stack_canary_segment();
>  }
>
> +/* Load a fixmap remapping of the per-cpu GDT */
> +void load_remapped_gdt(int cpu)
> +{
> +   struct desc_ptr gdt_descr;
> +   unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
> +
> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
> +
> +   gdt_descr.address = (long)__fix_to_virt(idx);
> +   gdt_descr.size = GDT_SIZE - 1;
> +   load_gdt(_descr);
> +}

IMO this should be split into two functions, one to set up the fixmap
entry and one to load the GDT.

Also, would it be possible to rename the various gdt helpers so that
their functionality is more obvious?  For example, get_cpu_gdt_table()
could be get_cpu_direct_gdt_table() and the function to load the gdt
could be load_fixmap_gdt().

--Andy

Re: [PATCH v1 2/3] x86: Remap GDT tables in the Fixmap section

[Andy Lutomirski]

On Fri, Jan 20, 2017 at 8:41 AM, Thomas Garnier  wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu structures or deduce the base of
> the main memory section (PAGE_OFFSET).
>
> This patch relocates the GDT table for each processor inside the
> Fixmap section. The space is reserved based on number of supported
> cpus.
>
> For consistency, the remapping is done by default on 32 and 64 bit.
>
> Each processor switches to its remapped GDT at the end of
> initialization. For hibernation, the main processor returns with the
> original GDT and switches back to the remapping at completion.
>
> On 32 bit, the maximum number of processors is now 256. The Fixmap
> section cannot handle the original 512. Additional asserts ensure that
> the Fixmap section cannot grow beyond the space available.
>
> This patch was tested on both architectures. Hibernation and KVM were
> both tested specially for their usage of the GDT.
>
> Signed-off-by: Thomas Garnier 
> ---
> Based on next-20170119
> ---
>  arch/x86/Kconfig |  1 +
>  arch/x86/include/asm/fixmap.h|  4 
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/common.c | 18 +-
>  arch/x86/mm/init_32.c|  2 ++
>  arch/x86/power/cpu.c |  3 +++
>  6 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f1d4e8f2131f..b4ed35db10a8 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -912,6 +912,7 @@ config MAXSMP
>  config NR_CPUS
> int "Maximum number of CPUs" if SMP && !MAXSMP
> range 2 8 if SMP && X86_32 && !X86_BIGSMP
> +   range 2 256 if SMP && X86_32 && X86_BIGSMP
> range 2 512 if SMP && !MAXSMP && !CPUMASK_OFFSTACK
> range 2 8192 if SMP && !MAXSMP && CPUMASK_OFFSTACK && X86_64
> default "1" if !SMP
> diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
> index c46289799b02..8b913b5e9383 100644
> --- a/arch/x86/include/asm/fixmap.h
> +++ b/arch/x86/include/asm/fixmap.h
> @@ -100,6 +100,10 @@ enum fixed_addresses {
>  #ifdef CONFIG_X86_INTEL_MID
> FIX_LNW_VRTC,
>  #endif
> +   /* Fixmap entries to remap the GDTs, one per processor. */
> +   FIX_GDT_REMAP_BEGIN,
> +   FIX_GDT_REMAP_END = FIX_GDT_REMAP_BEGIN + NR_CPUS - 1,
> +
> __end_of_permanent_fixed_addresses,
>
> /*
> diff --git a/arch/x86/include/asm/processor.h 
> b/arch/x86/include/asm/processor.h
> index 1be64da0384e..280211ad8be9 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -705,6 +705,7 @@ extern struct desc_ptr  early_gdt_descr;
>
>  extern void cpu_set_gdt(int);
>  extern void switch_to_new_gdt(int);
> +extern void load_remapped_gdt(int);
>  extern void load_percpu_segment(int);
>  extern void cpu_init(void);
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index e97ffc8d29f4..7d940b0e805a 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -443,6 +443,19 @@ void load_percpu_segment(int cpu)
> load_stack_canary_segment();
>  }
>
> +/* Load a fixmap remapping of the per-cpu GDT */
> +void load_remapped_gdt(int cpu)
> +{
> +   struct desc_ptr gdt_descr;
> +   unsigned long idx = FIX_GDT_REMAP_BEGIN + cpu;
> +
> +   __set_fixmap(idx, __pa(get_cpu_gdt_table(cpu)), PAGE_KERNEL);
> +
> +   gdt_descr.address = (long)__fix_to_virt(idx);
> +   gdt_descr.size = GDT_SIZE - 1;
> +   load_gdt(_descr);
> +}

IMO this should be split into two functions, one to set up the fixmap
entry and one to load the GDT.

Also, would it be possible to rename the various gdt helpers so that
their functionality is more obvious?  For example, get_cpu_gdt_table()
could be get_cpu_direct_gdt_table() and the function to load the gdt
could be load_fixmap_gdt().

--Andy

Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

[Andy Lutomirski]

On Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni  wrote:
> On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski  wrote:
>> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni  wrote:
> [...]
>>> Sure, the hidepid mount option is old enough, and this per-task
>>> hidepid is clearly defined only for procfs and per task, we can't add
>>> another switch that's relate to both a filesystem and pid namespaces,
>>> it will be a bit complicated and not really useful for cases that are
>>> in *same* pidns where *each* one have to mount its procfs, it will
>>> propagate. Also as noted by Lafcadio, the gid thing is a bit hard to
>>> use now.
>>
>> What I'm trying to say is that I want to understand a complete,
>> real-world use case.  Adding a security-related per-task flag is can
>> be quite messy and requires a lot of careful thought to get right, and
>> I'd rather avoid it if at all possible.
>
> I do agree, but that's not what we are proposing here. This use case
> is limited we do not manipulate the creds of the task, there are no
> security transitions. The task does not change, its only related to
> procfs and pid entries there. Also the flag applies only to current
> task and not on remote ones... Nothing new here it's an extension of
> procfs hidepid.
>
>> I'm imaging something like a new RestrictPidVisisbility= option in
>> systemd.  I agree that this is currently a mess to do.  But maybe a
>
> Yes that's one use case, If we manage to land this I'll follow up with
> it... plus there is, I've a use case related to kubernetes where I do
> want to reduce the number of processes inside containers per pod to
> minimal. Some other cases are: lock down children where being
> unprivileged. Also as noted in other replies on today's desktop
> systems, under a normal user session, the user should see all
> processes of the system where the media player, browser etc have no
> business to see the process tree. This can be easily implemented when
> launching apps without the need to regain privileges...
>
>> simpler solution would be to add a new mount option local_hidepid to
>> procfs.  If you set that option, then it overrides hidepid for that
>> instance.  Most of these semi-sandboxed daemon processes already have
>> their own mount namespace, so the overhead should be minimal.
>
> Andy If that could work :-/we have to re-write or adapt lot of
> things inside procfs... plus:
> Procfs is a miror to the current pid namespace. Mount options are not
> procfs but rather pid namespace. That would not work.

I agree that the kernel change to do it per task is very simple.  But
this is an unfortunate slippery slope.  What if you want to block off
everything in /proc that isn't associated with a PID?  What if you
want to suppress /sys access?  What if you want ot block *all*
non-current PIDs from being revealed in /proc?  What if you want to
hide /proc/PID/cmdline?

I think that the right solution here is to fix procfs to understand
per-superblock mount options.

--Andy

Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

[Andy Lutomirski]

On Fri, Jan 20, 2017 at 8:33 AM, Djalal Harouni  wrote:
> On Thu, Jan 19, 2017 at 8:52 PM, Andy Lutomirski  wrote:
>> On Thu, Jan 19, 2017 at 5:53 AM, Djalal Harouni  wrote:
> [...]
>>> Sure, the hidepid mount option is old enough, and this per-task
>>> hidepid is clearly defined only for procfs and per task, we can't add
>>> another switch that's relate to both a filesystem and pid namespaces,
>>> it will be a bit complicated and not really useful for cases that are
>>> in *same* pidns where *each* one have to mount its procfs, it will
>>> propagate. Also as noted by Lafcadio, the gid thing is a bit hard to
>>> use now.
>>
>> What I'm trying to say is that I want to understand a complete,
>> real-world use case.  Adding a security-related per-task flag is can
>> be quite messy and requires a lot of careful thought to get right, and
>> I'd rather avoid it if at all possible.
>
> I do agree, but that's not what we are proposing here. This use case
> is limited we do not manipulate the creds of the task, there are no
> security transitions. The task does not change, its only related to
> procfs and pid entries there. Also the flag applies only to current
> task and not on remote ones... Nothing new here it's an extension of
> procfs hidepid.
>
>> I'm imaging something like a new RestrictPidVisisbility= option in
>> systemd.  I agree that this is currently a mess to do.  But maybe a
>
> Yes that's one use case, If we manage to land this I'll follow up with
> it... plus there is, I've a use case related to kubernetes where I do
> want to reduce the number of processes inside containers per pod to
> minimal. Some other cases are: lock down children where being
> unprivileged. Also as noted in other replies on today's desktop
> systems, under a normal user session, the user should see all
> processes of the system where the media player, browser etc have no
> business to see the process tree. This can be easily implemented when
> launching apps without the need to regain privileges...
>
>> simpler solution would be to add a new mount option local_hidepid to
>> procfs.  If you set that option, then it overrides hidepid for that
>> instance.  Most of these semi-sandboxed daemon processes already have
>> their own mount namespace, so the overhead should be minimal.
>
> Andy If that could work :-/we have to re-write or adapt lot of
> things inside procfs... plus:
> Procfs is a miror to the current pid namespace. Mount options are not
> procfs but rather pid namespace. That would not work.

I agree that the kernel change to do it per task is very simple.  But
this is an unfortunate slippery slope.  What if you want to block off
everything in /proc that isn't associated with a PID?  What if you
want to suppress /sys access?  What if you want ot block *all*
non-current PIDs from being revealed in /proc?  What if you want to
hide /proc/PID/cmdline?

I think that the right solution here is to fix procfs to understand
per-superblock mount options.

--Andy

Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div

[Stephen Boyd]

On 01/18, Markus Mayer wrote:
> diff --git 
> a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt 
> b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> new file mode 100644
> index 000..c4acb53
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,27 @@
> +The CPU divider node serves as the sole clock for the CPU complex. It 
> supports
> +power-of-2 clock division, with a divider of "1" as the default highest-speed
> +setting.
> +
> +Required properties:
> +- compatible: shall be "brcm,brcmstb-cpu-clk-div"
> +- reg: address and width of the divider configuration register
> +- #clock-cells: shall be set to 0
> +- clocks: phandle of clock provider which provides the source clock
> +  (this would typically be a "fixed-clock" type PLL)
> +- div-table: list of (raw_value,divider) ordered pairs that correspond to the
> + allowed clock divider settings
> +- div-shift-width: least-significant bit position and width of divider value

Are these properties used? Please don't put these types of
details in DT.

> +
> +Optional properties:
> +- clock-names: the clock may be named
> +
> +Example:
> + cpuclkdiv: cpu-clk-div@f03e257c {
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;

This register really looks like some offset in something larger.
Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.

> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
> + #clock-cells = <0>;
> + clocks = <>;
> + clock-names = "cpupll";
> + };
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div

[Stephen Boyd]

On 01/18, Markus Mayer wrote:
> diff --git 
> a/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt 
> b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> new file mode 100644
> index 000..c4acb53
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
> @@ -0,0 +1,27 @@
> +The CPU divider node serves as the sole clock for the CPU complex. It 
> supports
> +power-of-2 clock division, with a divider of "1" as the default highest-speed
> +setting.
> +
> +Required properties:
> +- compatible: shall be "brcm,brcmstb-cpu-clk-div"
> +- reg: address and width of the divider configuration register
> +- #clock-cells: shall be set to 0
> +- clocks: phandle of clock provider which provides the source clock
> +  (this would typically be a "fixed-clock" type PLL)
> +- div-table: list of (raw_value,divider) ordered pairs that correspond to the
> + allowed clock divider settings
> +- div-shift-width: least-significant bit position and width of divider value

Are these properties used? Please don't put these types of
details in DT.

> +
> +Optional properties:
> +- clock-names: the clock may be named
> +
> +Example:
> + cpuclkdiv: cpu-clk-div@f03e257c {
> + compatible = "brcm,brcmstb-cpu-clk-div";
> + reg = <0xf03e257c 0x4>;

This register really looks like some offset in something larger.
Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.

> + div-table = <0x00 1>;
> + div-shift-width = <0 5>;
> + #clock-cells = <0>;
> + clocks = <>;
> + clock-names = "cpupll";
> + };
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC

[Stephen Boyd]

On 01/13, Chris Packham wrote:
> @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = {
>   .num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
>  };
>  
> +static const struct coreclk_soc_desc mv98dx3236_coreclks = {
> + .get_tclk_freq = mv98dx3236_get_tclk_freq,
> + .get_cpu_freq = mv98dx3236_get_cpu_freq,
> + .get_clk_ratio = NULL,
> + .ratios = NULL,
> + .num_ratios = 0,

Are these intentionally initialized to 0 explicitly? Otherwise we
could leave them out and it's all the same.

> +};
> +
>  /*
>   * Clock Gating Control
>   */
[..]
> @@ -243,5 +245,30 @@ static void __init of_cpu_clk_setup(struct device_node 
> *node)
>   iounmap(clock_complex_base);
>  }
>  
> +/* Use this function to call the generic setup with the correct
> + * clock operation
> + */
> +static void __init of_cpu_clk_setup(struct device_node *node)
> +{
> + _of_cpu_clk_setup(node, _ops);
> +}
> +
>  CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
>of_cpu_clk_setup);
> +
> +/* Define the clock and operations for the mv98dx3236 - it cannot perform
> + * any operations.
> + */
> +static const struct clk_ops mv98dx3236_cpu_ops = {
> + .recalc_rate = NULL,
> + .round_rate = NULL,
> + .set_rate = NULL,

But clk_set_rate() works silently? Why not just register a clk
provider that returns a NULL pointer? Then there isn't any
structure to maintain?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC

[Stephen Boyd]

On 01/13, Chris Packham wrote:
> @@ -158,6 +170,14 @@ static const struct coreclk_soc_desc axp_coreclks = {
>   .num_ratios = ARRAY_SIZE(axp_coreclk_ratios),
>  };
>  
> +static const struct coreclk_soc_desc mv98dx3236_coreclks = {
> + .get_tclk_freq = mv98dx3236_get_tclk_freq,
> + .get_cpu_freq = mv98dx3236_get_cpu_freq,
> + .get_clk_ratio = NULL,
> + .ratios = NULL,
> + .num_ratios = 0,

Are these intentionally initialized to 0 explicitly? Otherwise we
could leave them out and it's all the same.

> +};
> +
>  /*
>   * Clock Gating Control
>   */
[..]
> @@ -243,5 +245,30 @@ static void __init of_cpu_clk_setup(struct device_node 
> *node)
>   iounmap(clock_complex_base);
>  }
>  
> +/* Use this function to call the generic setup with the correct
> + * clock operation
> + */
> +static void __init of_cpu_clk_setup(struct device_node *node)
> +{
> + _of_cpu_clk_setup(node, _ops);
> +}
> +
>  CLK_OF_DECLARE(armada_xp_cpu_clock, "marvell,armada-xp-cpu-clock",
>of_cpu_clk_setup);
> +
> +/* Define the clock and operations for the mv98dx3236 - it cannot perform
> + * any operations.
> + */
> +static const struct clk_ops mv98dx3236_cpu_ops = {
> + .recalc_rate = NULL,
> + .round_rate = NULL,
> + .set_rate = NULL,

But clk_set_rate() works silently? Why not just register a clk
provider that returns a NULL pointer? Then there isn't any
structure to maintain?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro

[Stephen Boyd]

On 01/09, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> Macro to select a clock was not correct.
> 
> Offset of enable register starts at 0x30, then calculation to select a bit is:
> (@enable_reg - 0x30) / 4 * 32 + bit_to_select
> 
> Signed-off-by: Gabriel Fernandez 
> Tested-by: M'boumba Cedric Madianga 
> ---

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 1/3] dt-bindings: mfd: stm32f4: Fix STM32F4_X_CLOCK() macro

[Stephen Boyd]

On 01/09, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> Macro to select a clock was not correct.
> 
> Offset of enable register starts at 0x30, then calculation to select a bit is:
> (@enable_reg - 0x30) / 4 * 32 + bit_to_select
> 
> Signed-off-by: Gabriel Fernandez 
> Tested-by: M'boumba Cedric Madianga 
> ---

Acked-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

[Jason A. Donenfeld]

On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o  wrote:
> But there is a shared pointer, which is used both for the dedicated
> u32 array and the dedicated u64 array.  So when you increment the
> pointer for the get_random_u32, the corresponding entry in the u64
> array is wasted, no?

No, it is not a shared pointer. It is a different pointer with a
different batch. The idea is that each function gets its own batch.
That way there's always perfect alignment. This is why I'm suggesting
that my approach is faster.

Would you like me to roll your (slower) bitshifting idea as v2, or can
we stick with my v1?

Jason

Re: [PATCH 1/2] random: use chacha20 for get_random_int/long

[Jason A. Donenfeld]

On Sat, Jan 21, 2017 at 1:15 AM, Theodore Ts'o  wrote:
> But there is a shared pointer, which is used both for the dedicated
> u32 array and the dedicated u64 array.  So when you increment the
> pointer for the get_random_u32, the corresponding entry in the u64
> array is wasted, no?

No, it is not a shared pointer. It is a different pointer with a
different batch. The idea is that each function gets its own batch.
That way there's always perfect alignment. This is why I'm suggesting
that my approach is faster.

Would you like me to roll your (slower) bitshifting idea as v2, or can
we stick with my v1?

Jason

Re: [PATCH 2/4] clk: stm32f7: Introduce stm32f7 clocks for STM32F746 boards

[Stephen Boyd]

On 01/06, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> This patch enables clocks for STM32F746 boards.
> 
> Signed-off-by: Gabriel Fernandez 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/4] clk: stm32f7: Introduce stm32f7 clocks for STM32F746 boards

[Stephen Boyd]

On 01/06, gabriel.fernan...@st.com wrote:
> From: Gabriel Fernandez 
> 
> This patch enables clocks for STM32F746 boards.
> 
> Signed-off-by: Gabriel Fernandez 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[GIT PULL] libnvdimm fixes for 4.10-rc5

[Dan Williams]

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

...to receive:

* A regression fix for the multiple-pmem-namespace-per-region support
added in 4.9. Even if an existing environment is not using that
feature the act of creating and a destroying a single namespace with
the ndctl utility will lead to the proliferation of extra unwanted
namespace devices.

* A fix for the error code returned from the pmem driver when the
memcpy_mcsafe() routine returns -EFAULT. Btrfs seems to be the only
block I/O consumer that tries to parse the meaning of the error code
when it is non-zero.

Neither of these fixes are critical, the namespace leak is awkward in
that it can cause device naming to change and complicates debugging
namespace initialization issues. The error code fix is included out of
caution for what other consumers might be expecting -EIO for block I/O
errors.

---

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

for you to fetch changes up to 1f19b983a8877f81763fab3e693c6befe212736d:

  libnvdimm, namespace: fix pmem namespace leak, delete when size set
to zero (2017-01-13 09:50:33 -0800)


Dan Williams (1):
  libnvdimm, namespace: fix pmem namespace leak, delete when size
set to zero

Stefan Hajnoczi (1):
  pmem: return EIO on read_pmem() failure

 drivers/nvdimm/namespace_devs.c | 23 ++-
 drivers/nvdimm/pmem.c   |  4 +++-
 2 files changed, 13 insertions(+), 14 deletions(-)

commit d47d1d27fd6206c18806440f6ebddf51a806be4f
Author: Stefan Hajnoczi 
Date:   Thu Jan 5 10:05:46 2017 +

pmem: return EIO on read_pmem() failure

The read_pmem() function uses memcpy_mcsafe() on x86 where an EFAULT
error code indicates a failed read.  Block I/O should use EIO to
indicate failure.  Other pmem code paths (like bad blocks) already use
EIO so let's be consistent.

This fixes compatibility with consumers like btrfs that try to parse the
specific error code rather than treat all errors the same.

Reviewed-by: Jeff Moyer 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: Dan Williams 

commit 1f19b983a8877f81763fab3e693c6befe212736d
Author: Dan Williams 
Date:   Mon Jan 9 17:30:49 2017 -0800

libnvdimm, namespace: fix pmem namespace leak, delete when size set to zero

Commit 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple
pmem-namespaces per region") added support for establishing additional
pmem namespace beyond the seed device, similar to blk namespaces.
However, it neglected to delete the namespace when the size is set to
zero.

Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of
multiple pmem-namespaces per region")
Cc: 
Signed-off-by: Dan Williams 

[GIT PULL] libnvdimm fixes for 4.10-rc5

[Dan Williams]

Hi Linus, please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

...to receive:

* A regression fix for the multiple-pmem-namespace-per-region support
added in 4.9. Even if an existing environment is not using that
feature the act of creating and a destroying a single namespace with
the ndctl utility will lead to the proliferation of extra unwanted
namespace devices.

* A fix for the error code returned from the pmem driver when the
memcpy_mcsafe() routine returns -EFAULT. Btrfs seems to be the only
block I/O consumer that tries to parse the meaning of the error code
when it is non-zero.

Neither of these fixes are critical, the namespace leak is awkward in
that it can cause device naming to change and complicates debugging
namespace initialization issues. The error code fix is included out of
caution for what other consumers might be expecting -EIO for block I/O
errors.

---

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm libnvdimm-fixes

for you to fetch changes up to 1f19b983a8877f81763fab3e693c6befe212736d:

  libnvdimm, namespace: fix pmem namespace leak, delete when size set
to zero (2017-01-13 09:50:33 -0800)


Dan Williams (1):
  libnvdimm, namespace: fix pmem namespace leak, delete when size
set to zero

Stefan Hajnoczi (1):
  pmem: return EIO on read_pmem() failure

 drivers/nvdimm/namespace_devs.c | 23 ++-
 drivers/nvdimm/pmem.c   |  4 +++-
 2 files changed, 13 insertions(+), 14 deletions(-)

commit d47d1d27fd6206c18806440f6ebddf51a806be4f
Author: Stefan Hajnoczi 
Date:   Thu Jan 5 10:05:46 2017 +

pmem: return EIO on read_pmem() failure

The read_pmem() function uses memcpy_mcsafe() on x86 where an EFAULT
error code indicates a failed read.  Block I/O should use EIO to
indicate failure.  Other pmem code paths (like bad blocks) already use
EIO so let's be consistent.

This fixes compatibility with consumers like btrfs that try to parse the
specific error code rather than treat all errors the same.

Reviewed-by: Jeff Moyer 
Signed-off-by: Stefan Hajnoczi 
Signed-off-by: Dan Williams 

commit 1f19b983a8877f81763fab3e693c6befe212736d
Author: Dan Williams 
Date:   Mon Jan 9 17:30:49 2017 -0800

libnvdimm, namespace: fix pmem namespace leak, delete when size set to zero

Commit 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple
pmem-namespaces per region") added support for establishing additional
pmem namespace beyond the seed device, similar to blk namespaces.
However, it neglected to delete the namespace when the size is set to
zero.

Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of
multiple pmem-namespaces per region")
Cc: 
Signed-off-by: Dan Williams