Re: 3.13 i915 brightness settings broken when going from docked -> undocked

[Paul Bolle]

On Wed, 2014-02-19 at 21:20 -0500, Josh Boyer wrote:
> We've had a rather weird report[1] of the brightness adjustments being
> broken in a specific case with Thinkpad x220 hardware (SandyBridge
> based).  If you boot the machine with it in a dock and then undock,
> the brightness adjustments do not work.  That is with either the FN
> keys or the GNOME brightness slider.

On an (rather old) ThinkPad X41, which also uses i915, brightness
adjustments stopped working altogether in v3.14-rc1 (I haven't used its
docking station in the v3.14 release cycle). In v3.13.y things behave as
expected. So perhaps there's actually a more general problem here.

> I can see that the value of
> /sys/class/backlight/acpi_video0/brightness

On the X41 I check /proc/acpi/ibm/brightness ...

>  increases/decreases but
> /sys/class/backlight/intel_backlight/brightness doesn't reflect any
> changes.

but otherwise things look similar.

>  With 3.12 this works, and oddly with 3.14-rc1 it works
> (specifically, it starts working around v3.13-10231-g53d8ab2 which is
> right after the first DRM merge for 3.14).  With 3.13, if I undock and
> echo a higher value in the intel_backlight_brightness sysfs entry, the
> brightness will actually increase so it can be done manually, but it
> does not work as you'd expect.

Echoing values into /sys/class/backlight/intel_backlight/brightness
works too (that's a new trick for me!). But, again, no docking station
is required, so the problem looks less odd than the problem on that
x220.

> I'm in the middle of trying to do a reverse bisect for which patch
> fixes it in the 3.14-rcX series, but that's taking a while.  I thought
> I'd email and see if anyone already knows about this situation, what
> patch in 3.13 broke this, and which one then fixed it again.  Thus far
> all I've gathered is that backlight handling is confusing.

I haven't yet tried bisecting.

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071


Paul Bolle

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

Re: [PATCH] clocksource: timer-keystone: Delete unnecessary variable

[Daniel Lezcano]

On 02/18/2014 07:29 PM, Matthias Brugger wrote:

Commit 438e0bff5257 added the timer-keystone device driver but make use
of an unnecessary variable in the init function.
This patch delets this variable.

Signed-off-by: Matthias Brugger 


Applied to my tree for 3.15.

Thanks
  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH] sched/deadline: Fix overflow to handle period==0 and deadline!=0

[Juri Lelli]

On 02/19/2014 07:53 PM, Steven Rostedt wrote:
> While debugging the crash with the bad nr_running accounting, I hit
> another bug where, after running my sched deadline test, I was getting
> failures to take a CPU offline. It was giving me a -EBUSY error.
> 
> Adding a bunch of trace_printk()s around, I found that the cpu
> notifier that called sched_cpu_inactive() was returning a failure. The
> overflow value was coming up negative?
> 
> Talking this over with Juri, the problem is that the total_bw update was
> suppose to be made by dl_overflow() which, during my tests, seemed to
> not be called. Adding more trace_printk()s, it wasn't that it wasn't
> called, but it exited out right away with the check of new_bw being
> equal to p->dl.dl_bw. The new_bw calculates the ratio between period and
> runtime. The bug is that if you set a deadline, you do not need to set
> a period if you plan on the period being equal to the deadline. That
> is, if period is zero and deadline is not, then the system call should
> set the period to be equal to the deadline. This is done elsewhere in
> the code.
> 
> The fix is easy, check if period is set, and if it is not, then use the
> deadline.
> 
> Signed-off-by: Steven Rostedt 
> ---
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index b46131e..2491448 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1952,7 +1952,7 @@ static int dl_overflow(struct task_struct *p, int 
> policy,
>  {
>  
>   struct dl_bw *dl_b = dl_bw_of(task_cpu(p));
> - u64 period = attr->sched_period;
> + u64 period = attr->sched_period ?: attr->sched_deadline;
>   u64 runtime = attr->sched_runtime;
>   u64 new_bw = dl_policy(policy) ? to_ratio(period, runtime) : 0;
>   int cpus, err = -1;
> 

Thanks!

- Juri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: qcom: Add missing clock at index GCC_XO_CLK for MSM8974

[Ivan T. Ivanov]

On Wed, 2014-02-19 at 12:17 -0800, Stephen Boyd wrote: 
> On 02/19, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov" 
> > 
> > Accessing GCC on MSM8974 trough < GCC_XO_CLK> lead to NULL
> 
> s/trough/through/
> 
> > pointer dereference. Fix this.
> > 
> 
> I think you want to get the XO clock from the not yet upstreamed
> RPM clock driver. This #define is for a gate that is internal to
> the SoC sitting between the pin for XO and all downstream users
> of the XO clock within the SoC. Futhermore, linux is not allowed
> to control this gate because it's essential to the entire system.
> 
> This patch will work for now but we'll need to change the DTS in
> the future to get the clock from the RPM node and then revert
> this patch.
> 
> It may be better to just move the XO and sleep_clk_src clocks to
> DT and make them fixed-rate clocks that get added by
> of_clk_init(). Then when the RPM node is added we can remove the
> XO node and update the usb node at the same time.


I see. I'll leave you to decide what is the right solution here,

Regards,
Ivan


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

Re: [PATCH 3.10 00/26] 3.10.31-stable review

[Xishi Qiu]

On 2014/2/20 8:29, Shuah Khan wrote:

> On 02/18/2014 03:46 PM, Greg Kroah-Hartman wrote:
>> This is the start of the stable review cycle for the 3.10.31 release.
>> There are 26 patches in this series, all will be posted as a response
>> to this one.  If anyone has any issues with these being applied, please
>> let me know.
>>
>> Responses should be made by Thu Feb 20 22:45:20 UTC 2014.
>> Anything received after that time might be too late.
>>
>> The whole patch series can be found in one patch at:
>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.31-rc1.gz
>> and the diffstat can be found below.
>>
>> thanks,
>>
>> greg k-h
>>
> 
> Compile and boot tests passed on AMD system. Boot failed on Intel systems. I 
> think the following changes are the suspect, so far by process of elimination 
> - these two aren't in 3.12 and 3.13
> 
> #modified:   mm/hugetlb.c
> #modified:   mm/memory-failure.c
> 
> However, my strong suspect is the following:
> 
> Xishi Qiu 
> mm: fix process accidentally killed by mce because of huge page migration
> 
> I don't see how this could cause problems, none the less, I will test without 
> these changes and let you know.
> 
> 
> Naoya Horiguchi 
> mm/memory-failure.c: fix memory leak in successful soft offlining
> 
> I will test without these changes and let you know.
> 
> -- Shuah
> 

Hi Shuah

I tested on my system, it boot successfully.

hardware: Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
OS: v3.10.30 + the two patches

Thanks,
Xishi Qiu

> Shuah Khan
> Senior Linux Kernel Developer - Open Source Group
> Samsung Research America(Silicon Valley)
> shuah...@samsung.com | (970) 672-0658
> 
> 



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

[PATCH] block: replace obsolete simple_strtol() with kstrtoul()

[Daeseok Youn]

npig...@kernel.dk account doesn't exist.

TO+ :
a...@linux-foundation.org, ax...@kernel.dk

On Thursday, February 20, 2014 03:56:30 PM you wrote:
> From cac24db7480b10b671d05320e0cb97a7bf5d0aea Mon Sep 17 00:00:00 2001
> From: Daeseok Youn 
> Date: Thu, 20 Feb 2014 15:35:14 +0900
> Subject: [PATCH] block: replace obsolete simple_strtol() with kstrtoul()
> 
> - Makes rd_size value as static, because it is only
> referenced in this file.
> 
> Signed-off-by: Daeseok Youn 
> ---
>  drivers/block/brd.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/block/brd.c b/drivers/block/brd.c
> index e73b85c..a33d8d3 100644
> --- a/drivers/block/brd.c
> +++ b/drivers/block/brd.c
> @@ -429,12 +429,12 @@ static const struct block_device_operations brd_fops =
> { * And now the modules code and kernel interface.
>   */
>  static int rd_nr;
> -int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
> +static unsigned long rd_size = CONFIG_BLK_DEV_RAM_SIZE;
>  static int max_part;
>  static int part_shift;
>  module_param(rd_nr, int, S_IRUGO);
>  MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
> -module_param(rd_size, int, S_IRUGO);
> +module_param(rd_size, ulong, S_IRUGO);
>  MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
>  module_param(max_part, int, S_IRUGO);
>  MODULE_PARM_DESC(max_part, "Maximum number of partitions per RAM disk");
> @@ -446,7 +446,8 @@ MODULE_ALIAS("rd");
>  /* Legacy boot options - nonmodular */
>  static int __init ramdisk_size(char *str)
>  {
> - rd_size = simple_strtol(str, NULL, 0);
> + if (kstrtoul(str, 0, _size) < 0)
> + return 0;
>   return 1;
>  }
>  __setup("ramdisk_size=", ramdisk_size);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [sched/balance] WARNING: CPU: 0 PID: 8 at kernel/sched/core.c:2939 rt_mutex_setprio()

[Alex Shi]

On 02/19/2014 08:18 PM, Fengguang Wu wrote:
> Greetings,
> 
> I got the below dmesg and the first bad commit is

[snip]
> 
> sched/balance: add balance_interval to tuning top level balance frequency
> 

Good catching! :)
I will fix this problem and updated soon.

-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -mm v3 0/7] memcg-vs-slab related fixes, improvements, cleanups

[Vladimir Davydov]

Hi,

This patch set mostly cleanups memcg slab caches creation/destruction
paths fixing a couple of bugs in the meanwhile. The only serious change
it introduces is a rework of the sysfs layout for memcg slub caches (see
patch 7).

Changes in v3 (thanks to Michal Hocko):
 - improve patch descriptions
 - overall cleanup
 - rebase onto v3.14-rc3
Changes in v2 (thanks to David Rientjes):
 - do not remove cgroup name part from memcg cache names
 - do not export memcg cache id to userspace

Thanks,

Vladimir Davydov (7):
  memcg, slab: never try to merge memcg caches
  memcg, slab: cleanup memcg cache creation
  memcg, slab: separate memcg vs root cache creation paths
  memcg, slab: unregister cache from memcg before starting to destroy
it
  memcg, slab: do not destroy children caches if parent has aliases
  slub: adjust memcg caches when creating cache alias
  slub: rework sysfs layout for memcg caches

 include/linux/memcontrol.h |9 +-
 include/linux/slab.h   |6 +-
 include/linux/slub_def.h   |3 +
 mm/memcontrol.c|  109 ---
 mm/slab.h  |   21 +---
 mm/slab_common.c   |  250 +++-
 mm/slub.c  |   58 --
 7 files changed, 261 insertions(+), 195 deletions(-)

-- 
1.7.10.4

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

[PATCH -mm v3 1/7] memcg, slab: never try to merge memcg caches

[Vladimir Davydov]

When a kmem cache is created (kmem_cache_create_memcg()), we first try
to find a compatible cache that already exists and can handle requests
from the new cache, i.e. has the same object size, alignment, ctor, etc.
If there is such a cache, we do not create any new caches, instead we
simply increment the refcount of the cache found and return it.

Currently we do this procedure not only when creating root caches, but
also for memcg caches. However, there is no point in that, because, as
every memcg cache has exactly the same parameters as its parent and
cache merging cannot be turned off in runtime (only on boot by passing
"slub_nomerge"), the root caches of any two potentially mergeable memcg
caches should be merged already, i.e. it must be the same root cache,
and therefore we couldn't even get to the memcg cache creation, because
it already exists.

The only exception is boot caches - they are explicitly forbidden to be
merged by setting their refcount to -1. There are currently only two of
them - kmem_cache and kmem_cache_node, which are used in slab internals
(I do not count kmalloc caches as their refcount is set to 1 immediately
after creation). Since they are prevented from merging preliminary I
guess we should avoid to merge their children too.

So let's remove the useless code responsible for merging memcg caches.

Signed-off-by: Vladimir Davydov 
---
 mm/slab.h|   21 -
 mm/slab_common.c |8 +---
 mm/slub.c|   19 +--
 3 files changed, 18 insertions(+), 30 deletions(-)

diff --git a/mm/slab.h b/mm/slab.h
index 8184a7cde272..3045316b7c9d 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -55,12 +55,12 @@ extern void create_boot_cache(struct kmem_cache *, const 
char *name,
 struct mem_cgroup;
 #ifdef CONFIG_SLUB
 struct kmem_cache *
-__kmem_cache_alias(struct mem_cgroup *memcg, const char *name, size_t size,
-  size_t align, unsigned long flags, void (*ctor)(void *));
+__kmem_cache_alias(const char *name, size_t size, size_t align,
+  unsigned long flags, void (*ctor)(void *));
 #else
 static inline struct kmem_cache *
-__kmem_cache_alias(struct mem_cgroup *memcg, const char *name, size_t size,
-  size_t align, unsigned long flags, void (*ctor)(void *))
+__kmem_cache_alias(const char *name, size_t size, size_t align,
+  unsigned long flags, void (*ctor)(void *))
 { return NULL; }
 #endif
 
@@ -119,13 +119,6 @@ static inline bool is_root_cache(struct kmem_cache *s)
return !s->memcg_params || s->memcg_params->is_root_cache;
 }
 
-static inline bool cache_match_memcg(struct kmem_cache *cachep,
-struct mem_cgroup *memcg)
-{
-   return (is_root_cache(cachep) && !memcg) ||
-   (cachep->memcg_params->memcg == memcg);
-}
-
 static inline void memcg_bind_pages(struct kmem_cache *s, int order)
 {
if (!is_root_cache(s))
@@ -204,12 +197,6 @@ static inline bool is_root_cache(struct kmem_cache *s)
return true;
 }
 
-static inline bool cache_match_memcg(struct kmem_cache *cachep,
-struct mem_cgroup *memcg)
-{
-   return true;
-}
-
 static inline void memcg_bind_pages(struct kmem_cache *s, int order)
 {
 }
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 1ec3c619ba04..e77b51eb7347 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -200,9 +200,11 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const 
char *name, size_t size,
 */
flags &= CACHE_CREATE_MASK;
 
-   s = __kmem_cache_alias(memcg, name, size, align, flags, ctor);
-   if (s)
-   goto out_unlock;
+   if (!memcg) {
+   s = __kmem_cache_alias(name, size, align, flags, ctor);
+   if (s)
+   goto out_unlock;
+   }
 
err = -ENOMEM;
s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
diff --git a/mm/slub.c b/mm/slub.c
index fe6d7be22ef0..2f40e615368f 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3685,6 +3685,9 @@ static int slab_unmergeable(struct kmem_cache *s)
if (slub_nomerge || (s->flags & SLUB_NEVER_MERGE))
return 1;
 
+   if (!is_root_cache(s))
+   return 1;
+
if (s->ctor)
return 1;
 
@@ -3697,9 +3700,8 @@ static int slab_unmergeable(struct kmem_cache *s)
return 0;
 }
 
-static struct kmem_cache *find_mergeable(struct mem_cgroup *memcg, size_t size,
-   size_t align, unsigned long flags, const char *name,
-   void (*ctor)(void *))
+static struct kmem_cache *find_mergeable(size_t size, size_t align,
+   unsigned long flags, const char *name, void (*ctor)(void *))
 {
struct kmem_cache *s;
 
@@ -3722,7 +3724,7 @@ static struct kmem_cache *find_mergeable(struct 
mem_cgroup *memcg, size_t size,
continue;
 
if ((flags & SLUB_MERGE_SAME) != (s->flags & 

[PATCH -mm v3 4/7] memcg, slab: unregister cache from memcg before starting to destroy it

[Vladimir Davydov]

Currently, memcg_unregister_cache(), which deletes the cache being
destroyed from the memcg_slab_caches list, is called after
__kmem_cache_shutdown() (see kmem_cache_destroy()), which starts to
destroy the cache. As a result, one can access a partially destroyed
cache while traversing a memcg_slab_caches list, which can have deadly
consequences (for instance, cache_show() called for each cache on a
memcg_slab_caches list from mem_cgroup_slabinfo_read() will dereference
pointers to already freed data).

To fix this, let's move memcg_unregister_cache() before the cache
destruction process beginning, issuing memcg_register_cache() on
failure.

Signed-off-by: Vladimir Davydov 
---
 mm/memcontrol.c  |   12 ++--
 mm/slab_common.c |3 ++-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 0e11c72047d0..b07e08f97460 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3205,6 +3205,7 @@ int memcg_alloc_cache_params(struct mem_cgroup *memcg, 
struct kmem_cache *s,
s->memcg_params->root_cache = root_cache;
INIT_WORK(>memcg_params->destroy,
kmem_cache_destroy_work_func);
+   css_get(>css);
} else
s->memcg_params->is_root_cache = true;
 
@@ -3213,6 +3214,10 @@ int memcg_alloc_cache_params(struct mem_cgroup *memcg, 
struct kmem_cache *s,
 
 void memcg_free_cache_params(struct kmem_cache *s)
 {
+   if (!s->memcg_params)
+   return;
+   if (!s->memcg_params->is_root_cache)
+   css_put(>memcg_params->memcg->css);
kfree(s->memcg_params);
 }
 
@@ -3235,9 +3240,6 @@ void memcg_register_cache(struct kmem_cache *s)
memcg = s->memcg_params->memcg;
id = memcg_cache_id(memcg);
 
-   css_get(>css);
-
-
/*
 * Since readers won't lock (see cache_from_memcg_idx()), we need a
 * barrier here to ensure nobody will see the kmem_cache partially
@@ -3286,10 +3288,8 @@ void memcg_unregister_cache(struct kmem_cache *s)
 * after removing it from the memcg_slab_caches list, otherwise we can
 * fail to convert memcg_params_to_cache() while traversing the list.
 */
-   VM_BUG_ON(!root->memcg_params->memcg_caches[id]);
+   VM_BUG_ON(root->memcg_params->memcg_caches[id] != s);
root->memcg_params->memcg_caches[id] = NULL;
-
-   css_put(>css);
 }
 
 /*
diff --git a/mm/slab_common.c b/mm/slab_common.c
index ccc012f00126..0c2879ff414c 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -313,9 +313,9 @@ void kmem_cache_destroy(struct kmem_cache *s)
s->refcount--;
if (!s->refcount) {
list_del(>list);
+   memcg_unregister_cache(s);
 
if (!__kmem_cache_shutdown(s)) {
-   memcg_unregister_cache(s);
mutex_unlock(_mutex);
if (s->flags & SLAB_DESTROY_BY_RCU)
rcu_barrier();
@@ -325,6 +325,7 @@ void kmem_cache_destroy(struct kmem_cache *s)
kmem_cache_free(kmem_cache, s);
} else {
list_add(>list, _caches);
+   memcg_register_cache(s);
mutex_unlock(_mutex);
printk(KERN_ERR "kmem_cache_destroy %s: Slab cache 
still has objects\n",
s->name);
-- 
1.7.10.4

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

[PATCH -mm v3 5/7] memcg, slab: do not destroy children caches if parent has aliases

[Vladimir Davydov]

Currently we destroy children caches at the very beginning of
kmem_cache_destroy(). This is wrong, because the root cache will not
necessarily be destroyed in the end - if it has aliases (refcount > 0),
kmem_cache_destroy() will simply decrement its refcount and return. In
this case, at best we will get a bunch of warnings in dmesg, like this
one:

  kmem_cache_destroy kmalloc-32:0: Slab cache still has objects
  CPU: 1 PID: 7139 Comm: modprobe Tainted: GB   W3.13.0+ #117
  Hardware name:
   88007d7a6368 880039b07e48 8168cc2e 88007d7a6d68
   88007d7a6300 880039b07e68 81175e9f 
   88007d7a6300 880039b07e98 811b67c7 88003e803c00
  Call Trace:
   [] dump_stack+0x49/0x5b
   [] kmem_cache_destroy+0xdf/0xf0
   [] kmem_cache_destroy_memcg_children+0x97/0xc0
   [] kmem_cache_destroy+0xf/0xf0
   [] xfs_mru_cache_uninit+0x21/0x30 [xfs]
   [] exit_xfs_fs+0x2e/0xc44 [xfs]
   [] SyS_delete_module+0x198/0x1f0
   [] system_call_fastpath+0x16/0x1b

At worst - if kmem_cache_destroy() will race with an allocation from a
memcg cache - the kernel will panic.

This patch fixes this by moving children caches destruction after the
check if the cache has aliases. Plus, it forbids destroying a root cache
if it still has children caches, because each children cache keeps a
reference to its parent.

Signed-off-by: Vladimir Davydov 
---
 include/linux/memcontrol.h |6 +---
 mm/memcontrol.c|   13 
 mm/slab_common.c   |   75 +---
 3 files changed, 57 insertions(+), 37 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 01a506a9e57b..af63e6004c62 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -513,7 +513,7 @@ struct kmem_cache *
 __memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp);
 
 void mem_cgroup_destroy_cache(struct kmem_cache *cachep);
-void kmem_cache_destroy_memcg_children(struct kmem_cache *s);
+int __kmem_cache_destroy_memcg_children(struct kmem_cache *s);
 
 /**
  * memcg_kmem_newpage_charge: verify if a new kmem allocation is allowed.
@@ -667,10 +667,6 @@ memcg_kmem_get_cache(struct kmem_cache *cachep, gfp_t gfp)
 {
return cachep;
 }
-
-static inline void kmem_cache_destroy_memcg_children(struct kmem_cache *s)
-{
-}
 #endif /* CONFIG_MEMCG_KMEM */
 #endif /* _LINUX_MEMCONTROL_H */
 
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index b07e08f97460..8a87614b6238 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3386,15 +3386,10 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
schedule_work(>memcg_params->destroy);
 }
 
-void kmem_cache_destroy_memcg_children(struct kmem_cache *s)
+int __kmem_cache_destroy_memcg_children(struct kmem_cache *s)
 {
struct kmem_cache *c;
-   int i;
-
-   if (!s->memcg_params)
-   return;
-   if (!s->memcg_params->is_root_cache)
-   return;
+   int i, failed = 0;
 
/*
 * If the cache is being destroyed, we trust that there is no one else
@@ -3428,8 +3423,12 @@ void kmem_cache_destroy_memcg_children(struct kmem_cache 
*s)
c->memcg_params->dead = false;
cancel_work_sync(>memcg_params->destroy);
kmem_cache_destroy(c);
+
+   if (cache_from_memcg_idx(s, i))
+   failed++;
}
mutex_unlock(_kmem_mutex);
+   return failed;
 }
 
 static void mem_cgroup_destroy_all_caches(struct mem_cgroup *memcg)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 0c2879ff414c..f3cfccf76dda 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -301,39 +301,64 @@ out_unlock:
mutex_unlock(_mutex);
put_online_cpus();
 }
+
+static int kmem_cache_destroy_memcg_children(struct kmem_cache *s)
+{
+   int rc;
+
+   if (!s->memcg_params ||
+   !s->memcg_params->is_root_cache)
+   return 0;
+
+   mutex_unlock(_mutex);
+   rc = __kmem_cache_destroy_memcg_children(s);
+   mutex_lock(_mutex);
+
+   return rc;
+}
+#else
+static int kmem_cache_destroy_memcg_children(struct kmem_cache *s)
+{
+   return 0;
+}
 #endif /* CONFIG_MEMCG_KMEM */
 
 void kmem_cache_destroy(struct kmem_cache *s)
 {
-   /* Destroy all the children caches if we aren't a memcg cache */
-   kmem_cache_destroy_memcg_children(s);
-
get_online_cpus();
mutex_lock(_mutex);
+
s->refcount--;
-   if (!s->refcount) {
-   list_del(>list);
-   memcg_unregister_cache(s);
-
-   if (!__kmem_cache_shutdown(s)) {
-   mutex_unlock(_mutex);
-   if (s->flags & SLAB_DESTROY_BY_RCU)
-   rcu_barrier();
-
-   memcg_free_cache_params(s);
-   kfree(s->name);
-   kmem_cache_free(kmem_cache, s);
-   } else 

[PATCH -mm v3 3/7] memcg, slab: separate memcg vs root cache creation paths

[Vladimir Davydov]

Memcg-awareness turned kmem_cache_create() into a dirty interweaving of
memcg-only and except-for-memcg calls. To clean this up, let's move
the code responsible for memcg cache creation to a separate function.

Signed-off-by: Vladimir Davydov 
---
 include/linux/memcontrol.h |6 --
 include/linux/slab.h   |6 +-
 mm/memcontrol.c|7 +-
 mm/slab_common.c   |  187 +---
 4 files changed, 111 insertions(+), 95 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 4d6b481d11db..01a506a9e57b 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -644,12 +644,6 @@ static inline int memcg_cache_id(struct mem_cgroup *memcg)
return -1;
 }
 
-static inline char *memcg_create_cache_name(struct mem_cgroup *memcg,
-   struct kmem_cache *root_cache)
-{
-   return NULL;
-}
-
 static inline int memcg_alloc_cache_params(struct mem_cgroup *memcg,
struct kmem_cache *s, struct kmem_cache *root_cache)
 {
diff --git a/include/linux/slab.h b/include/linux/slab.h
index 9260abdd67df..67f10f31f4fb 100644
--- a/include/linux/slab.h
+++ b/include/linux/slab.h
@@ -115,9 +115,9 @@ int slab_is_available(void);
 struct kmem_cache *kmem_cache_create(const char *, size_t, size_t,
unsigned long,
void (*)(void *));
-struct kmem_cache *
-kmem_cache_create_memcg(struct mem_cgroup *, const char *, size_t, size_t,
-   unsigned long, void (*)(void *), struct kmem_cache *);
+#ifdef CONFIG_MEMCG_KMEM
+void kmem_cache_create_memcg(struct mem_cgroup *, struct kmem_cache *);
+#endif
 void kmem_cache_destroy(struct kmem_cache *);
 int kmem_cache_shrink(struct kmem_cache *);
 void kmem_cache_free(struct kmem_cache *, void *);
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 62db588a8ca6..0e11c72047d0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3460,13 +3460,8 @@ static void memcg_create_cache_work_func(struct 
work_struct *w)
struct create_work *cw = container_of(w, struct create_work, work);
struct mem_cgroup *memcg = cw->memcg;
struct kmem_cache *cachep = cw->cachep;
-   struct kmem_cache *new;
 
-   new = kmem_cache_create_memcg(memcg, cachep->name,
-   cachep->object_size, cachep->align,
-   cachep->flags & ~SLAB_PANIC, cachep->ctor, cachep);
-   if (new)
-   new->allocflags |= __GFP_KMEMCG;
+   kmem_cache_create_memcg(memcg, cachep);
css_put(>css);
kfree(cw);
 }
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 11857abf7057..ccc012f00126 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -29,8 +29,7 @@ DEFINE_MUTEX(slab_mutex);
 struct kmem_cache *kmem_cache;
 
 #ifdef CONFIG_DEBUG_VM
-static int kmem_cache_sanity_check(struct mem_cgroup *memcg, const char *name,
-  size_t size)
+static int kmem_cache_sanity_check(const char *name, size_t size)
 {
struct kmem_cache *s = NULL;
 
@@ -57,13 +56,7 @@ static int kmem_cache_sanity_check(struct mem_cgroup *memcg, 
const char *name,
}
 
 #if !defined(CONFIG_SLUB) || !defined(CONFIG_SLUB_DEBUG_ON)
-   /*
-* For simplicity, we won't check this in the list of memcg
-* caches. We have control over memcg naming, and if there
-* aren't duplicates in the global list, there won't be any
-* duplicates in the memcg lists as well.
-*/
-   if (!memcg && !strcmp(s->name, name)) {
+   if (!strcmp(s->name, name)) {
pr_err("%s (%s): Cache name already exists.\n",
   __func__, name);
dump_stack();
@@ -77,8 +70,7 @@ static int kmem_cache_sanity_check(struct mem_cgroup *memcg, 
const char *name,
return 0;
 }
 #else
-static inline int kmem_cache_sanity_check(struct mem_cgroup *memcg,
- const char *name, size_t size)
+static inline int kmem_cache_sanity_check(const char *name, size_t size)
 {
return 0;
 }
@@ -139,6 +131,46 @@ unsigned long calculate_alignment(unsigned long flags,
return ALIGN(align, sizeof(void *));
 }
 
+static struct kmem_cache *
+do_kmem_cache_create(char *name, size_t object_size, size_t size, size_t align,
+unsigned long flags, void (*ctor)(void *),
+struct mem_cgroup *memcg, struct kmem_cache *root_cache)
+{
+   struct kmem_cache *s;
+   int err;
+
+   err = -ENOMEM;
+   s = kmem_cache_zalloc(kmem_cache, GFP_KERNEL);
+   if (!s)
+   goto out;
+
+   s->name = name;
+   s->object_size = object_size;
+   s->size = size;
+   s->align = align;
+   s->ctor = ctor;
+
+   err = memcg_alloc_cache_params(memcg, s, 

[PATCH -mm v3 6/7] slub: adjust memcg caches when creating cache alias

[Vladimir Davydov]

Otherwise, kzalloc() called from a memcg won't clear the whole object.

Signed-off-by: Vladimir Davydov 
---
 mm/slub.c |   13 +
 1 file changed, 13 insertions(+)

diff --git a/mm/slub.c b/mm/slub.c
index 2f40e615368f..cac2ff7fd68c 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3748,7 +3748,11 @@ __kmem_cache_alias(const char *name, size_t size, size_t 
align,
 
s = find_mergeable(size, align, flags, name, ctor);
if (s) {
+   int i;
+   struct kmem_cache *c;
+
s->refcount++;
+
/*
 * Adjust the object sizes so that we clear
 * the complete object on kzalloc.
@@ -3756,6 +3760,15 @@ __kmem_cache_alias(const char *name, size_t size, size_t 
align,
s->object_size = max(s->object_size, (int)size);
s->inuse = max_t(int, s->inuse, ALIGN(size, sizeof(void *)));
 
+   for_each_memcg_cache_index(i) {
+   c = cache_from_memcg_idx(s, i);
+   if (!c)
+   continue;
+   c->object_size = s->object_size;
+   c->inuse = max_t(int, c->inuse,
+ALIGN(size, sizeof(void *)));
+   }
+
if (sysfs_slab_alias(s, name)) {
s->refcount--;
s = NULL;
-- 
1.7.10.4

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

[PATCH -mm v3 7/7] slub: rework sysfs layout for memcg caches

[Vladimir Davydov]

Currently, we try to arrange sysfs entries for memcg caches in the same
manner as for global caches. Apart from turning /sys/kernel/slab into a
mess when there are a lot of kmem-active memcgs created, it actually
does not work properly - we won't create more than one link to a memcg
cache in case its parent is merged with another cache. For instance, if
A is a root cache merged with another root cache B, we will have the
following sysfs setup:

  X
  A -> X
  B -> X

where X is some unique id (see create_unique_id()). Now if memcgs M and
N start to allocate from cache A (or B, which is the same), we will get:

  X
  X:M
  X:N
  A -> X
  B -> X
  A:M -> X:M
  A:N -> X:N

Since B is an alias for A, we won't get entries B:M and B:N, which is
confusing.

It is more logical to have entries for memcg caches under the
corresponding root cache's sysfs directory. This would allow us to keep
sysfs layout clean, and avoid such inconsistencies like one described
above.

This patch does the trick. It creates a "cgroup" kset in each root cache
kobject to keep its children caches there.

Signed-off-by: Vladimir Davydov 
---
 include/linux/slub_def.h |3 +++
 mm/slub.c|   26 +-
 2 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index f56bfa9e4526..f2f7398848cf 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -87,6 +87,9 @@ struct kmem_cache {
 #ifdef CONFIG_MEMCG_KMEM
struct memcg_cache_params *memcg_params;
int max_attr_size; /* for propagation, maximum size of a stored attr */
+#ifdef CONFIG_SYSFS
+   struct kset *memcg_kset;
+#endif
 #endif
 
 #ifdef CONFIG_NUMA
diff --git a/mm/slub.c b/mm/slub.c
index cac2ff7fd68c..4a10126fec3a 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5138,6 +5138,15 @@ static const struct kset_uevent_ops slab_uevent_ops = {
 
 static struct kset *slab_kset;
 
+static inline struct kset *cache_kset(struct kmem_cache *s)
+{
+#ifdef CONFIG_MEMCG_KMEM
+   if (!is_root_cache(s))
+   return s->memcg_params->root_cache->memcg_kset;
+#endif
+   return slab_kset;
+}
+
 #define ID_STR_LENGTH 64
 
 /* Create a unique string id for a slab cache:
@@ -5203,7 +5212,7 @@ static int sysfs_slab_add(struct kmem_cache *s)
name = create_unique_id(s);
}
 
-   s->kobj.kset = slab_kset;
+   s->kobj.kset = cache_kset(s);
err = kobject_init_and_add(>kobj, _ktype, NULL, "%s", name);
if (err) {
kobject_put(>kobj);
@@ -5216,6 +5225,18 @@ static int sysfs_slab_add(struct kmem_cache *s)
kobject_put(>kobj);
return err;
}
+
+#ifdef CONFIG_MEMCG_KMEM
+   if (is_root_cache(s)) {
+   s->memcg_kset = kset_create_and_add("cgroup", NULL, >kobj);
+   if (!s->memcg_kset) {
+   kobject_del(>kobj);
+   kobject_put(>kobj);
+   return -ENOMEM;
+   }
+   }
+#endif
+
kobject_uevent(>kobj, KOBJ_ADD);
if (!unmergeable) {
/* Setup first alias */
@@ -5234,6 +5255,9 @@ static void sysfs_slab_remove(struct kmem_cache *s)
 */
return;
 
+#ifdef CONFIG_MEMCG_KMEM
+   kset_unregister(s->memcg_kset);
+#endif
kobject_uevent(>kobj, KOBJ_REMOVE);
kobject_del(>kobj);
kobject_put(>kobj);
-- 
1.7.10.4

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

[PATCH -mm v3 2/7] memcg, slab: cleanup memcg cache creation

[Vladimir Davydov]

This patch cleanups the memcg cache creation path as follows:
 - Move memcg cache name creation to a separate function to be called
   from kmem_cache_create_memcg(). This allows us to get rid of the
   mutex protecting the temporary buffer used for the name formatting,
   because the whole cache creation path is protected by the slab_mutex.
 - Get rid of memcg_create_kmem_cache(). This function serves as a proxy
   to kmem_cache_create_memcg(). After separating the cache name
   creation path, it would be reduced to a function call, so let's
   inline it.

Signed-off-by: Vladimir Davydov 
---
 include/linux/memcontrol.h |9 +
 mm/memcontrol.c|   89 +++-
 mm/slab_common.c   |5 ++-
 3 files changed, 52 insertions(+), 51 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index eccfb4a4b379..4d6b481d11db 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -497,6 +497,9 @@ void __memcg_kmem_commit_charge(struct page *page,
 void __memcg_kmem_uncharge_pages(struct page *page, int order);
 
 int memcg_cache_id(struct mem_cgroup *memcg);
+
+char *memcg_create_cache_name(struct mem_cgroup *memcg,
+ struct kmem_cache *root_cache);
 int memcg_alloc_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
 struct kmem_cache *root_cache);
 void memcg_free_cache_params(struct kmem_cache *s);
@@ -641,6 +644,12 @@ static inline int memcg_cache_id(struct mem_cgroup *memcg)
return -1;
 }
 
+static inline char *memcg_create_cache_name(struct mem_cgroup *memcg,
+   struct kmem_cache *root_cache)
+{
+   return NULL;
+}
+
 static inline int memcg_alloc_cache_params(struct mem_cgroup *memcg,
struct kmem_cache *s, struct kmem_cache *root_cache)
 {
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 53885166dc12..62db588a8ca6 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3159,6 +3159,29 @@ int memcg_update_cache_size(struct kmem_cache *s, int 
num_groups)
return 0;
 }
 
+char *memcg_create_cache_name(struct mem_cgroup *memcg,
+ struct kmem_cache *root_cache)
+{
+   static char *buf = NULL;
+
+   /*
+* We need a mutex here to protect the shared buffer. Since this is
+* expected to be called only on cache creation, we can employ the
+* slab_mutex for that purpose.
+*/
+   lockdep_assert_held(_mutex);
+
+   if (!buf) {
+   buf = kmalloc(NAME_MAX + 1, GFP_KERNEL);
+   if (!buf)
+   return NULL;
+   }
+
+   cgroup_name(memcg->css.cgroup, buf, NAME_MAX + 1);
+   return kasprintf(GFP_KERNEL, "%s(%d:%s)", root_cache->name,
+memcg_cache_id(memcg), buf);
+}
+
 int memcg_alloc_cache_params(struct mem_cgroup *memcg, struct kmem_cache *s,
 struct kmem_cache *root_cache)
 {
@@ -3363,46 +3386,6 @@ void mem_cgroup_destroy_cache(struct kmem_cache *cachep)
schedule_work(>memcg_params->destroy);
 }
 
-static struct kmem_cache *memcg_create_kmem_cache(struct mem_cgroup *memcg,
- struct kmem_cache *s)
-{
-   struct kmem_cache *new = NULL;
-   static char *tmp_path = NULL, *tmp_name = NULL;
-   static DEFINE_MUTEX(mutex); /* protects tmp_name */
-
-   BUG_ON(!memcg_can_account_kmem(memcg));
-
-   mutex_lock();
-   /*
-* kmem_cache_create_memcg duplicates the given name and
-* cgroup_name for this name requires RCU context.
-* This static temporary buffer is used to prevent from
-* pointless shortliving allocation.
-*/
-   if (!tmp_path || !tmp_name) {
-   if (!tmp_path)
-   tmp_path = kmalloc(PATH_MAX, GFP_KERNEL);
-   if (!tmp_name)
-   tmp_name = kmalloc(NAME_MAX + 1, GFP_KERNEL);
-   if (!tmp_path || !tmp_name)
-   goto out;
-   }
-
-   cgroup_name(memcg->css.cgroup, tmp_name, NAME_MAX + 1);
-   snprintf(tmp_path, PATH_MAX, "%s(%d:%s)", s->name,
-memcg_cache_id(memcg), tmp_name);
-
-   new = kmem_cache_create_memcg(memcg, tmp_path, s->object_size, s->align,
- (s->flags & ~SLAB_PANIC), s->ctor, s);
-   if (new)
-   new->allocflags |= __GFP_KMEMCG;
-   else
-   new = s;
-out:
-   mutex_unlock();
-   return new;
-}
-
 void kmem_cache_destroy_memcg_children(struct kmem_cache *s)
 {
struct kmem_cache *c;
@@ -3449,12 +3432,6 @@ void kmem_cache_destroy_memcg_children(struct kmem_cache 
*s)
mutex_unlock(_kmem_mutex);
 }
 
-struct create_work {
-   struct mem_cgroup *memcg;
-   struct kmem_cache *cachep;
-   struct work_struct work;
-};
-
 static void 

Re: [sched/balance] 7511dd0a7: +2.1e+05% context switches

[Alex Shi]

On 02/19/2014 09:00 PM, Fengguang Wu wrote:
> bc575710efe937e  7511dd0a73aaf2ca4bcd829f9
> ---  -
>   2029 ~ 0%+222.9%   6551 ~17%  
> lkp-snb01/micro/will-it-scale/pthread_mutex2
> 143678 ~42%  +4.8e+05%  6.927e+08 ~ 0%  
> lkp-snb01/micro/will-it-scale/sched_yield
> 145708 ~42%  +4.8e+05%  6.927e+08 ~ 0%  TOTAL 
> time.involuntary_context_switches


Thanks for testing, Fengguang!

Does the context switch increasing happen on whole patchset? or just
happens on this patch?

-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Feb 19 (netdev)

[David Miller]

From: Randy Dunlap 
Date: Wed, 19 Feb 2014 07:08:09 -0800

> on i386:
> 
> net/built-in.o:(.rodata+0x1707c): undefined reference to 
> `ip_tunnel_get_stats64'
> 
> Full randconfig file is attached.

Thanks for the report Randy, this should do it:

diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index 6d430ff..7b19528 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -119,52 +119,6 @@ static struct rtable *tunnel_rtable_get(struct ip_tunnel 
*t, u32 cookie)
return (struct rtable *)dst;
 }
 
-/* Often modified stats are per cpu, other are shared (netdev->stats) */
-struct rtnl_link_stats64 *ip_tunnel_get_stats64(struct net_device *dev,
-   struct rtnl_link_stats64 *tot)
-{
-   int i;
-
-   for_each_possible_cpu(i) {
-   const struct pcpu_sw_netstats *tstats =
-  per_cpu_ptr(dev->tstats, i);
-   u64 rx_packets, rx_bytes, tx_packets, tx_bytes;
-   unsigned int start;
-
-   do {
-   start = u64_stats_fetch_begin_bh(>syncp);
-   rx_packets = tstats->rx_packets;
-   tx_packets = tstats->tx_packets;
-   rx_bytes = tstats->rx_bytes;
-   tx_bytes = tstats->tx_bytes;
-   } while (u64_stats_fetch_retry_bh(>syncp, start));
-
-   tot->rx_packets += rx_packets;
-   tot->tx_packets += tx_packets;
-   tot->rx_bytes   += rx_bytes;
-   tot->tx_bytes   += tx_bytes;
-   }
-
-   tot->multicast = dev->stats.multicast;
-
-   tot->rx_crc_errors = dev->stats.rx_crc_errors;
-   tot->rx_fifo_errors = dev->stats.rx_fifo_errors;
-   tot->rx_length_errors = dev->stats.rx_length_errors;
-   tot->rx_frame_errors = dev->stats.rx_frame_errors;
-   tot->rx_errors = dev->stats.rx_errors;
-
-   tot->tx_fifo_errors = dev->stats.tx_fifo_errors;
-   tot->tx_carrier_errors = dev->stats.tx_carrier_errors;
-   tot->tx_dropped = dev->stats.tx_dropped;
-   tot->tx_aborted_errors = dev->stats.tx_aborted_errors;
-   tot->tx_errors = dev->stats.tx_errors;
-
-   tot->collisions  = dev->stats.collisions;
-
-   return tot;
-}
-EXPORT_SYMBOL_GPL(ip_tunnel_get_stats64);
-
 static bool ip_tunnel_key_match(const struct ip_tunnel_parm *p,
__be16 flags, __be32 key)
 {
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index 6156f4e..8d69626 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -148,3 +148,49 @@ error:
return ERR_PTR(err);
 }
 EXPORT_SYMBOL_GPL(iptunnel_handle_offloads);
+
+/* Often modified stats are per cpu, other are shared (netdev->stats) */
+struct rtnl_link_stats64 *ip_tunnel_get_stats64(struct net_device *dev,
+   struct rtnl_link_stats64 *tot)
+{
+   int i;
+
+   for_each_possible_cpu(i) {
+   const struct pcpu_sw_netstats *tstats =
+  per_cpu_ptr(dev->tstats, i);
+   u64 rx_packets, rx_bytes, tx_packets, tx_bytes;
+   unsigned int start;
+
+   do {
+   start = u64_stats_fetch_begin_bh(>syncp);
+   rx_packets = tstats->rx_packets;
+   tx_packets = tstats->tx_packets;
+   rx_bytes = tstats->rx_bytes;
+   tx_bytes = tstats->tx_bytes;
+   } while (u64_stats_fetch_retry_bh(>syncp, start));
+
+   tot->rx_packets += rx_packets;
+   tot->tx_packets += tx_packets;
+   tot->rx_bytes   += rx_bytes;
+   tot->tx_bytes   += tx_bytes;
+   }
+
+   tot->multicast = dev->stats.multicast;
+
+   tot->rx_crc_errors = dev->stats.rx_crc_errors;
+   tot->rx_fifo_errors = dev->stats.rx_fifo_errors;
+   tot->rx_length_errors = dev->stats.rx_length_errors;
+   tot->rx_frame_errors = dev->stats.rx_frame_errors;
+   tot->rx_errors = dev->stats.rx_errors;
+
+   tot->tx_fifo_errors = dev->stats.tx_fifo_errors;
+   tot->tx_carrier_errors = dev->stats.tx_carrier_errors;
+   tot->tx_dropped = dev->stats.tx_dropped;
+   tot->tx_aborted_errors = dev->stats.tx_aborted_errors;
+   tot->tx_errors = dev->stats.tx_errors;
+
+   tot->collisions  = dev->stats.collisions;
+
+   return tot;
+}
+EXPORT_SYMBOL_GPL(ip_tunnel_get_stats64);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] ioat: fix tasklet tear down

[Dan Williams]

Since commit 77873803363c "net_dma: mark broken" we no longer pin dma
engines active for the network-receive-offload use case.  As a result
the ->free_chan_resources() that occurs after the driver self-test no
longer has a NET_DMA induced ->alloc_chan_resources() to back it up.  A
late firing irq can lead to ksoftirqd spinning indefinitely due to the
tasklet_disable() performed by ->free_chan_resources().  Only
->alloc_chan_resources() can clear this condition in affected kernels.

This problem has been present since commit 3e037454bcfa "I/OAT: Add
support for MSI and MSI-X" in 2.6.24, but is now exposed. Given the
NET_DMA use case is deprecated we can revisit moving the driver to use
threaded irqs.  For now, just tear down the irq and tasklet properly by:

1/ Disable the irq from triggering the tasklet

2/ Disable the irq from re-arming

3/ Flush inflight interrupts

4/ Flush the timer

5/ Flush inflight tasklets

References:
https://lkml.org/lkml/2014/1/27/282
https://lkml.org/lkml/2014/2/19/672

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Steven Rostedt 
Cc: 
Reported-by: Mike Galbraith 
Reported-by: Stanislav Fomichev 
Signed-off-by: Dan Williams 
---

Passes my testing, but would appreciate a tested-by.

 drivers/dma/ioat/dma.c|   52 +++--
 drivers/dma/ioat/dma.h|1 +
 drivers/dma/ioat/dma_v2.c |   11 --
 drivers/dma/ioat/dma_v3.c |3 +++
 4 files changed, 54 insertions(+), 13 deletions(-)

diff --git a/drivers/dma/ioat/dma.c b/drivers/dma/ioat/dma.c
index 87529181efcc..4e3549a16132 100644
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -77,7 +77,8 @@ static irqreturn_t ioat_dma_do_interrupt(int irq, void *data)
attnstatus = readl(instance->reg_base + IOAT_ATTNSTATUS_OFFSET);
for_each_set_bit(bit, , BITS_PER_LONG) {
chan = ioat_chan_by_index(instance, bit);
-   tasklet_schedule(>cleanup_task);
+   if (test_bit(IOAT_RUN, >state))
+   tasklet_schedule(>cleanup_task);
}
 
writeb(intrctrl, instance->reg_base + IOAT_INTRCTRL_OFFSET);
@@ -93,7 +94,8 @@ static irqreturn_t ioat_dma_do_interrupt_msix(int irq, void 
*data)
 {
struct ioat_chan_common *chan = data;
 
-   tasklet_schedule(>cleanup_task);
+   if (test_bit(IOAT_RUN, >state))
+   tasklet_schedule(>cleanup_task);
 
return IRQ_HANDLED;
 }
@@ -116,7 +118,6 @@ void ioat_init_channel(struct ioatdma_device *device, 
struct ioat_chan_common *c
chan->timer.function = device->timer_fn;
chan->timer.data = data;
tasklet_init(>cleanup_task, device->cleanup_fn, data);
-   tasklet_disable(>cleanup_task);
 }
 
 /**
@@ -354,13 +355,49 @@ static int ioat1_dma_alloc_chan_resources(struct dma_chan 
*c)
writel(((u64) chan->completion_dma) >> 32,
   chan->reg_base + IOAT_CHANCMP_OFFSET_HIGH);
 
-   tasklet_enable(>cleanup_task);
+   set_bit(IOAT_RUN, >state);
ioat1_dma_start_null_desc(ioat);  /* give chain to dma device */
dev_dbg(to_dev(chan), "%s: allocated %d descriptors\n",
__func__, ioat->desccount);
return ioat->desccount;
 }
 
+void ioat_stop(struct ioat_chan_common *chan)
+{
+   struct ioatdma_device *device = chan->device;
+   struct pci_dev *pdev = device->pdev;
+   int chan_id = chan_num(chan);
+   struct msix_entry *msix;
+
+   /* 1/ stop irq from firing tasklets
+* 2/ stop the tasklet from re-arming irqs
+*/
+   clear_bit(IOAT_RUN, >state);
+
+   /* flush inflight interrupts */
+   switch (device->irq_mode) {
+   case IOAT_MSIX:
+   msix = >msix_entries[chan_id];
+   synchronize_irq(msix->vector);
+   break;
+   case IOAT_MSI:
+   case IOAT_INTX:
+   synchronize_irq(pdev->irq);
+   break;
+   default:
+   break;
+   }
+
+   /* flush inflight timers */
+   del_timer_sync(>timer);
+
+   /* flush inflight tasklet runs */
+   tasklet_kill(>cleanup_task);
+
+   /* final cleanup now that everything is quiesced and can't re-arm */
+   device->cleanup_fn((unsigned long) >common);
+}
+
 /**
  * ioat1_dma_free_chan_resources - release all the descriptors
  * @chan: the channel to be cleaned
@@ -379,9 +416,7 @@ static void ioat1_dma_free_chan_resources(struct dma_chan 
*c)
if (ioat->desccount == 0)
return;
 
-   tasklet_disable(>cleanup_task);
-   del_timer_sync(>timer);
-   ioat1_cleanup(ioat);
+   ioat_stop(chan);
 
/* Delay 100ms after reset to allow internal DMA logic to quiesce
 * before removing DMA descriptor resources.
@@ -526,8 +561,11 @@ ioat1_dma_prep_memcpy(struct dma_chan *c, dma_addr_t 
dma_dest,
 static void ioat1_cleanup_event(unsigned long data)
 {
struct ioat_dma_chan *ioat = to_ioat_chan((void *) data);
+   struct ioat_chan_common 

Re: [PATCH] pcie: Add Xilinx PCIe Host Bridge IP driver

[Srikanth Thokala]

On Wed, Feb 19, 2014 at 6:05 AM, Jason Gunthorpe
 wrote:
> On Tue, Feb 18, 2014 at 02:32:58PM -0700, Bjorn Helgaas wrote:
>> [+cc Arnd]
>>
>> On Sun, Feb 16, 2014 at 8:33 AM, Srikanth Thokala  wrote:
>> > This is the driver for Xilinx AXI PCIe Host Bridge Soft IP
>> >
>> > Signed-off-by: Srikanth Thokala 
>> > - Rebased on v3.14.0-rc2
>> >  .../devicetree/bindings/pci/xilinx-pcie.txt|   43 +
>> >  drivers/pci/host/Kconfig   |7 +
>> >  drivers/pci/host/Makefile  |1 +
>> >  drivers/pci/host/pci-xilinx.c  |  985 
>> > 
>> >  4 files changed, 1036 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/pci/xilinx-pcie.txt
>> >  create mode 100644 drivers/pci/host/pci-xilinx.c
>> >
>> > diff --git a/Documentation/devicetree/bindings/pci/xilinx-pcie.txt 
>> > b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
>> > new file mode 100644
>> > index 000..66a2487
>> > +++ b/Documentation/devicetree/bindings/pci/xilinx-pcie.txt
>> > @@ -0,0 +1,43 @@
>> > +* Xilinx AXI PCIe Root Port Bridge DT description
>> > +
>> > +Required properties:
>> > +- #address-cells: Address representation for root ports, set to <3>
>> > +- #size-cells: Size representation for root ports, set to <2>
>> > +- compatible: Should contain "xlnx,axi-pcie-1.00.a"
>> > +- reg: Should contain AXI PCIe registers location and length
>> > +- interrupts: Should contain AXI PCIe interrupt
>> > +- ranges: ranges for the PCI memory regions
>> > +   Please refer to the standard PCI bus binding document for a more
>> > +   detailed explanation
>> > +- xlnx,axibar-num: Number of memory regions configured in the hardware,
>> > +   maximum being three which is configurable in the hardware.
>> > +- xlnx,include-rc: Root Port (=1) or End Point (=0)
>> > +- xlnx,pciebar2axibar-0: Translation address from PCIe to AXI
>> > +   Only one PCIe BAR is applicable in Root port mode, it can be
>> > +   either 32/64-bit. If it is 64-bit BAR, lower 32 bits are present
>> > +   in 'xlnx,pciebar2axibar-0' and Upper 32 bits in 'xlnx,pciebar2
>> > +   axibar-1'. And if it is 32-bit BAR, only 'xlnx,pciebar2axibar-0'
>> > +   is valid
>> > +
>> > +Optional properties
>> > +- xlnx,pciebar-as: PCIe BAR aperture size is 32 (=0) or 64-bit (=1).
>> > +- xlnx,pciebar2axibar-1: Translation address from PCIe to AXI, contains
>> > +   upper 32 bits if PCIe BAR size is 64-bit. When xlnx,pciebar-as
>> > +   is set, this is a required property and should contain a valid
>> > +   value (other than FF's)
>>
>> I hardly know anything about DT, but xlnx,pciebar2axibar-0,
>> xlnx,pciebar-as, and xlnx,pciebar2axibar-1 look strange to me.  Is
>> that really the DT way of dealing with 32/64-bit BARs and host bridge
>> address translation?  I don't see similar things in the other files in
>> Documentation/devicetree/bindings/pci/, even though some of the other
>> drivers/pci/host/*.c files do use pci_add_resource_offset(), which
>> indicates that they support address translation.
>
> I agree Bjorn.
>
> These should use the standard ranges mechanism for translations and
> apertures.

This AXI PCIe bridge IP do have two kind of BARs AXI-to-PCIe BAR and
PCIe-to-AXI BAR.  The former specifies the AXI Base address and are the
memory windows, these are listed in the 'ranges' DT property.  The latter
BAR specifies the addresses that PCI Express should respond to/is
tallowed to write to and these addresses written to configuration space
during the initialization.

>
> Also, IMHO, only root ports should be supported in a host bridge
> driver. A PCI end point is something entirely different.

We are not supporting end point in this driver.  This is a soft IP and can be
configurable as a Root Port/End point while creating a HW design in the
FPGA.  So, the driver use this DT property to first check if it is
configured for
Root Port and bail out if it is not.

Srikanth

>
> I think with those two observations all the xlnx properties should go
> away.
>
> Thanks,
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [3.13.2] list passed to list_sort() too long for efficiency.

[Dave Chinner]

On Wed, Feb 12, 2014 at 10:07:46AM -0800, Joe Perches wrote:
> On Wed, 2014-02-12 at 18:59 +0100, Paweł Sikora wrote:
> > On Wednesday 12 of February 2014 09:46:26 Joe Perches wrote:
> > > On Wed, 2014-02-12 at 18:16 +0100, Paweł Sikora wrote:
> > > > [16855.582522] list passed to list_sort() too long for efficiency
> > > > 
> > > > could someone put some light on the last line?
> > > 
> > > Did you look at the list_sort function in lib/list_sort.c?
> > > 
> > > (granted the dmesg is harder to find that it should be
> > >  because the format is split)
> > > 
> > > It just means it's slower than it could otherwise be
> > 
> > thanks,
> > so without a stacktrace in dmesg we can't isolate a root of cause :/
> > 
> 
> Perhaps something like this would help:
> 
> Emit the caller of list_sort using %pS when the list is too
> long to be efficient.  Also emit the message if necessary
> once for each call.

Still not useful. For XFS, the list_sort caller isn't directly of
interest - it's further down the stack where the interesting
information is (e.g. caller flushing buffers from log recovery,
metadata writeback, quota shrinker, quotacheck, etc).  Only a full
stack trace will tell us what we need to know.

I think WARN_ON_ONCE() is probably a better solution here.

Cheers,

Dave.

-- 
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: Tree for Feb 20

[Stephen Rothwell]

Hi all,

If you see failures in building this tree due to missing declarations of
k..alloc/free, then it may be caused by commit 2bd59d48ebfb ("cgroup:
convert to kernfs").  Please send Tejun Heo  a patch
adding an inclusion of linux/slab.h to the appropriate file(s).

This tree fails (more than usual) the powerpc allyesconfig build.

Changes since 20140219:

New tree: clang

The imx-mxs tree gained a conflict against the arm-soc tree.

The powerpc tree still had its build failure.

The mfd-lj tree still had its build failure so I used the version from
next-20140210.

The hid tree gained conflicts against Lunus' tree.

The sound-asoc tree gained a build failure so I used the version from
next-20140219 (with a driver disabled because of yesterday's error).

Non-merge commits (relative to Linus' tree): 3539
 3718 files changed, 126532 insertions(+), 67391 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log files
in the Next directory.  Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final
link) and i386, sparc, sparc64 and arm defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.

Below is a summary of the state of the merge.

I am currently merging 210 trees (counting Linus' and 28 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ .  Thanks to Frank Seidel.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

$ git checkout master
$ git reset --hard stable
Merging origin/master (e95003c3f9cc Merge tag 'nfs-for-3.14-4' of 
git://git.linux-nfs.org/projects/trondmy/linux-nfs)
Merging fixes/master (b0031f227e47 Merge tag 's2mps11-build' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator)
Merging kbuild-current/rc-fixes (38dbfb59d117 Linus 3.14-rc1)
Merging arc-current/for-curr (7e22e91102c6 Linux 3.13-rc8)
Merging arm-current/fixes (39544ac9df20 ARM: 7957/1: add DSB after icache flush 
in __flush_icache_all())
Merging m68k-current/for-linus (7247f55381d5 m68k: Wire up sched_setattr and 
sched_getattr)
Merging metag-fixes/fixes (3b2f64d00c46 Linux 3.11-rc2)
Merging powerpc-merge/merge (66f9af83e56b powerpc/eeh: Disable EEH on reboot)
Merging sparc/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of 
git://git.monstr.eu/linux-2.6-microblaze)
Merging net/master (d554f73df6bc xen-netfront: reset skb network header before 
checksum)
Merging ipsec/master (960dfc4eb23a Merge branch 'drm-fixes' of 
git://people.freedesktop.org/~airlied/linux)
Merging sound-current/for-linus (13c12dbe3a2c ALSA: hda/ca0132 - Fix recording 
from mode id 0x8)
Merging pci-current/for-linus (fc40363b2140 ahci: Fix broken fallback to single 
MSI mode)
Merging wireless/master (4885c8731a34 hostap: fix "hostap: proc: Use 
remove_proc_subtree()")
Merging driver-core.current/driver-core-linus (6d0abeca3242 Linux 3.14-rc3)
Merging tty.current/tty-linus (6d0abeca3242 Linux 3.14-rc3)
Merging usb.current/usb-linus (64fe1891696c phy: let phy_provider_register be 
the last step in registering PHY)
Merging staging.current/staging-linus (6d0abeca3242 Linux 3.14-rc3)
Merging char-misc.current/char-misc-linus (accb884b32e8 mei: set client's 
read_cb to NULL when flow control fails)
Merging input-current/for-linus (70b0052425ff Input: da9052_onkey - use correct 
register bit for key status)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard" 
stripe)
Merging crypto-current/master (ee97dc7db4cb crypto: s390 - fix des and des3_ede 
ctr concurrency issue)
Merging ide/master (738b52bb9845 Merge tag 'microblaze-3.14-rc3' of 
git://git.mo

[PATCH] block: replace obsolete simple_strtol() with kstrtoul()

[Daeseok Youn]

>From cac24db7480b10b671d05320e0cb97a7bf5d0aea Mon Sep 17 00:00:00 2001
From: Daeseok Youn 
Date: Thu, 20 Feb 2014 15:35:14 +0900
Subject: [PATCH] block: replace obsolete simple_strtol() with kstrtoul()

- Makes rd_size value as static, because it is only
referenced in this file.

Signed-off-by: Daeseok Youn 
---
 drivers/block/brd.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index e73b85c..a33d8d3 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -429,12 +429,12 @@ static const struct block_device_operations brd_fops = {
  * And now the modules code and kernel interface.
  */
 static int rd_nr;
-int rd_size = CONFIG_BLK_DEV_RAM_SIZE;
+static unsigned long rd_size = CONFIG_BLK_DEV_RAM_SIZE;
 static int max_part;
 static int part_shift;
 module_param(rd_nr, int, S_IRUGO);
 MODULE_PARM_DESC(rd_nr, "Maximum number of brd devices");
-module_param(rd_size, int, S_IRUGO);
+module_param(rd_size, ulong, S_IRUGO);
 MODULE_PARM_DESC(rd_size, "Size of each RAM disk in kbytes.");
 module_param(max_part, int, S_IRUGO);
 MODULE_PARM_DESC(max_part, "Maximum number of partitions per RAM disk");
@@ -446,7 +446,8 @@ MODULE_ALIAS("rd");
 /* Legacy boot options - nonmodular */
 static int __init ramdisk_size(char *str)
 {
-   rd_size = simple_strtol(str, NULL, 0);
+   if (kstrtoul(str, 0, _size) < 0)
+   return 0;
return 1;
 }
 __setup("ramdisk_size=", ramdisk_size);
-- 
1.7.9.5

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

Re: mmotm 2014-02-19-16-07 uploaded (sound/soc/intel/sst-dsp.c)

[Stephen Rothwell]

Hi Randy,

On Wed, 19 Feb 2014 21:41:36 -0800 Randy Dunlap  wrote:
>
> on i386:
> (from linux-next)
> 
>   CC  sound/soc/intel/sst-dsp.o
> sound/soc/intel/sst-dsp.c: In function 'sst_dsp_outbox_write':
> sound/soc/intel/sst-dsp.c:218:2: error: implicit declaration of function 
> 'memcpy_toio' [-Werror=implicit-function-declaration]
> sound/soc/intel/sst-dsp.c: In function 'sst_dsp_outbox_read':
> sound/soc/intel/sst-dsp.c:231:2: error: implicit declaration of function 
> 'memcpy_fromio' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[4]: *** [sound/soc/intel/sst-dsp.o] Error 1

Which linux-next?  How did you generate that error?  I think I have that
driver disabled in linux-next ever since it was introduced due to getting
this error in one of my builds.

... thinks ...

I get it - the linux-next patch in Andrew's patch queue is based on the
part of linux-next *before* the commit that reverted the commit that
allowed that file to build.  :-(  Today, that will not happen.  I'll see
if I can come up with a more permanent solution to that problem.

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpQKeYoZu_qg.pgp
Description: PGP signature

Re: Thread overran stack, or stack corrupted on 3.13.0

[Dave Chinner]

On Wed, Feb 05, 2014 at 02:19:32PM -0800, David Rientjes wrote:
> On Thu, 6 Feb 2014, Andrew Vagin wrote:
> 
> > [532284.563576] BUG: unable to handle kernel paging request at 
> > 35c83420
> > [532284.564086] IP: [] cpuacct_charge+0x97/0x1e0
> > [532284.564086] PGD 116369067 PUD 116368067 PMD 0
> > [532284.564086] Thread overran stack, or stack corrupted
> > [532284.564086] Oops:  [#1] SMP
> > [532284.564086] Modules linked in: veth binfmt_misc ip6table_filter 
> > ip6_tables tun netlink_diag af_packet_diag udp_diag tcp_diag inet_diag 
> > unix_diag bridge stp llc btrfs libcrc32c xor raid6_pq microcode i2c_piix4 
> > joydev virtio_balloon virtio_net pcspkr i2c_core virtio_blk virtio_pci 
> > virtio_ring virtio floppy
> > [532284.564086] CPU: 2 PID: 2487 Comm: cat Not tainted 3.13.0 #160
> > [532284.564086] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > [532284.564086] task: 8800cdb6 ti: 8801167ee000 task.ti: 
> > 8801167ee000
> > [532284.564086] RIP: 0010:[]  [] 
> > cpuacct_charge+0x97/0x1e0
> > [532284.564086] RSP: 0018:8801167ee638  EFLAGS: 00010002
> > [532284.564086] RAX: e540 RBX: 0006086c RCX: 
> > 000f
> > [532284.564086] RDX: 81c4e960 RSI: 81c50640 RDI: 
> > 0046
> > [532284.564086] RBP: 8801167ee668 R08: 0003 R09: 
> > 0001
> > [532284.564086] R10: 0001 R11: 0004 R12: 
> > 8800cdb6
> > [532284.564086] R13: 167ee038 R14: 8800db3576d8 R15: 
> > 80ee26ec7dcf
> > [532284.564086] FS:  7fc30ecc7740() GS:88011b20() 
> > knlGS:
> > [532284.564086] CS:  0010 DS:  ES:  CR0: 8005003b
> > [532284.564086] CR2: 35c83420 CR3: 00011f966000 CR4: 
> > 06e0
> > [532284.564086] Stack:
> > [532284.564086]  810cae80 88010014 8800db333480 
> > 0006086c
> > [532284.564086]  8800cdb60068 8800cdb6 8801167ee6a8 
> > 810b948f
> > [532284.564086]  8801167ee698 8800cdb60068 8800db333480 
> > 0001
> > [532284.564086] Call Trace:
> > [532284.564086]  [] ? cpuacct_css_alloc+0xb0/0xb0
> > [532284.564086]  [] update_curr+0x13f/0x220
> > [532284.564086]  [] dequeue_entity+0x24/0x5b0
> > [532284.564086]  [] ? sched_clock+0x9/0x10
> > [532284.564086]  [] dequeue_task_fair+0x49/0x430
> > [532284.564086]  [] dequeue_task+0x73/0x90
> > [532284.564086]  [] deactivate_task+0x23/0x30
> > [532284.564086]  [] __schedule+0x501/0x960
> > [532284.564086]  [] schedule+0x29/0x70
> > [532284.564086]  [] schedule_timeout+0x14c/0x2a0
> > [532284.564086]  [] ? del_timer+0x70/0x70
> > [532284.564086]  [] ? 
> > _raw_spin_unlock_irqrestore+0x40/0x80
> > [532284.564086]  [] io_schedule_timeout+0x9f/0x100
> > [532284.564086]  [] ? trace_hardirqs_on+0xd/0x10
> > [532284.564086]  [] mempool_alloc+0x152/0x180
> > [532284.564086]  [] ? bit_waitqueue+0xd0/0xd0
> > [532284.564086]  [] ? kvm_clock_read+0x27/0x40
> > [532284.564086]  [] bio_alloc_bioset+0x10b/0x1e0
> > [532284.564086]  [] ? end_swap_bio_read+0xc0/0xc0
> > [532284.564086]  [] ? end_swap_bio_read+0xc0/0xc0
> > [532284.564086]  [] get_swap_bio+0x30/0x90
> > [532284.564086]  [] ? end_swap_bio_read+0xc0/0xc0
> > [532284.564086]  [] __swap_writepage+0x150/0x230
> > [532284.564086]  [] ? _raw_spin_unlock+0x2b/0x40
> > [532284.564086]  [] ? page_swapcount+0x53/0x70
> > [532284.564086]  [] swap_writepage+0x43/0x90
> > [532284.564086]  [] shrink_page_list+0x6cf/0xaa0
> > [532284.564086]  [] shrink_inactive_list+0x1c2/0x5b0
> > [532284.564086]  [] ? __lock_acquire+0x249/0x1800
> > [532284.564086]  [] shrink_lruvec+0x335/0x600
> > [532284.564086]  [] ? mem_cgroup_iter+0x1f5/0x510
> > [532284.564086]  [] shrink_zone+0x96/0x1d0
> > [532284.564086]  [] do_try_to_free_pages+0x103/0x600
> > [532284.564086]  [] ? zone_watermark_ok+0x1f/0x30
> > [532284.564086]  [] try_to_free_pages+0xdc/0x230
> > [532284.564086]  [] ? drain_pages+0xad/0xe0
> > [532284.564086]  [] __alloc_pages_nodemask+0xa14/0xc90
> > [532284.564086]  [] ? sched_clock_local+0x25/0x90
> > [532284.564086]  [] alloc_pages_current+0x126/0x200
> > [532284.564086]  [] ? new_slab+0x2e5/0x390
> > [532284.564086]  [] ? new_slab+0x2cd/0x390
> > [532284.564086]  [] new_slab+0x2e5/0x390
> > [532284.564086]  [] __slab_alloc+0x3f3/0x700
> > [532284.564086]  [] ? kmem_cache_alloc+0x27f/0x2a0
> > [532284.564086]  [] ? sched_clock_cpu+0xb8/0x110
> > [532284.564086]  [] ? mempool_alloc_slab+0x15/0x20
> > [532284.564086]  [] ? rcu_read_unlock+0x2e/0x70
> > [532284.564086]  [] ? __memcg_kmem_get_cache+0x58/0x2b0
> > [532284.564086]  [] kmem_cache_alloc+0x27f/0x2a0
> > [532284.564086]  [] ? mempool_alloc_slab+0x15/0x20
> > [532284.564086]  [] mempool_alloc_slab+0x15/0x20
> > [532284.564086]  [] mempool_alloc+0x60/0x180
> > [532284.564086]  [] bio_alloc_bioset+0x10b/0x1e0
> > [532284.564086]  [] mpage_alloc+0x3b/0xa0
> > [532284.564086]  [] 

Re: [PATCH v3 14/15] charger: max14577: Configure battery-dependent settings from DTS

[Jenny Tc]

On Mon, Feb 17, 2014 at 10:05:49AM +0100, Krzysztof Kozlowski wrote:
> +static inline int max14577_init_eoc(struct max14577_charger *chg,
> + unsigned int uamp)
> +{
> + unsigned int current_bits = 0xf;
> + u8 reg_data;
> +
> + switch (chg->maxim_core->dev_type) {
> + case MAXIM_DEVICE_TYPE_MAX77836:
> + if (uamp < 5000)
> + return -EINVAL; /* Requested current is too low */
> +
> + if (uamp == 7500)
> + current_bits = 0x0;

if (uamp <= 7500) ?

> + /* Initialize Overvoltage-Protection Threshold */
> + switch (chg->pdata->ovp_uvolt) {
> + case 750:
> + reg_data = 0x0;
> + break;
> + case 600:
> + case 650:
> + case 700:
> + reg_data = 0x1 + (chg->pdata->ovp_uvolt - 600) / 50;
> + break;

Is it battery OVP or charger source OVP? If it's battery OVP, then  minimum
level as 6V seems to be unsafe even for 4.4V batteries.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf/x86/uncore: Fix IVT/SNB-EP uncore CBOX NID filter table

[Yan, Zheng]

On 02/19/2014 09:10 PM, Stephane Eranian wrote:
> 
> This patch updates the CBOX PMU filters mapping tables for SNB-EP
> and IVT (model 45 and 62 respectively).
> 
> The NID umask always comes in addition to another umask.
> When set, the NID filter is applied.

Do you means the NID always applies for LLC_LOOKUP no matter what umask is.
If yes, I think it's better to define filter as SNBEP_CBO_EVENT_EXTRA_REG(0x34, 
0xff, 0x6)

Regards
Yan, Zheng

> 
> The current mapping tables were missing some code/umask
> combinations to account for the NID umask. This patch
> fixes that.
> 
> Signed-off-by: Stephane Eranian 
> 
> diff --git a/arch/x86/kernel/cpu/perf_event_intel_uncore.c 
> b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> --- a/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> +++ b/arch/x86/kernel/cpu/perf_event_intel_uncore.c
> @@ -501,8 +501,11 @@ static struct extra_reg snbep_uncore_cbox_extra_regs[] = 
> {
>   SNBEP_CBO_EVENT_EXTRA_REG(SNBEP_CBO_PMON_CTL_TID_EN,
> SNBEP_CBO_PMON_CTL_TID_EN, 0x1),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0334, 0x, 0x4),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4334, 0x, 0x6),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0534, 0x, 0x4),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4534, 0x, 0x6),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0934, 0x, 0x4),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4934, 0x, 0x6),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x4134, 0x, 0x6),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0135, 0x, 0x8),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0335, 0x, 0x8),
> @@ -1178,10 +1181,15 @@ static struct extra_reg ivt_uncore_cbox_extra_regs[] 
> = {
>   SNBEP_CBO_EVENT_EXTRA_REG(SNBEP_CBO_PMON_CTL_TID_EN,
> SNBEP_CBO_PMON_CTL_TID_EN, 0x1),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x1031, 0x10ff, 0x2),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x1134, 0x, 0x4),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4134, 0x, 0xc),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x5134, 0x, 0xc),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0334, 0x, 0x4),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4334, 0x, 0xc),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0534, 0x, 0x4),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4534, 0x, 0xc),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0934, 0x, 0x4),
> - SNBEP_CBO_EVENT_EXTRA_REG(0x4134, 0x, 0xc),
> + SNBEP_CBO_EVENT_EXTRA_REG(0x4934, 0x, 0xc),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0135, 0x, 0x10),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x0335, 0x, 0x10),
>   SNBEP_CBO_EVENT_EXTRA_REG(0x2135, 0x, 0x10),
> 

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

[PATCH 4/4] power_supply: bq24261 charger driver

[Jenny TC]

This patch introduces BQ24261 charger driver. The driver makes use of power
supply charging driver to setup charging. So the driver does hardware
abstraction and handles h/w specific corner cases. The charging logic resides
with power supply charging driver

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig |   10 +
 drivers/power/Makefile|1 +
 drivers/power/bq24261-charger.c   | 1350 +
 include/linux/power/bq24261-charger.h |   25 +
 4 files changed, 1386 insertions(+)
 create mode 100644 drivers/power/bq24261-charger.c
 create mode 100644 include/linux/power/bq24261-charger.h

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 913ec36..a1c2780 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -409,6 +409,16 @@ config BATTERY_GOLDFISH
  Say Y to enable support for the battery and AC power in the
  Goldfish emulator.
 
+config CHARGER_BQ24261
+   tristate "BQ24261 charger driver"
+   select POWER_SUPPLY_CHARGER
+   depends on I2C
+   help
+ Say Y to include support for BQ24261 Charger driver. This driver
+ makes use of power supply charging driver. So the driver gives
+ the charger hardware abstraction only. Charging logic is abstracted
+ in the power supply charging driver.
+
 source "drivers/power/reset/Kconfig"
 
 endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 77535fd..9dde895 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -59,4 +59,5 @@ obj-$(CONFIG_CHARGER_BQ24735) += bq24735-charger.o
 obj-$(CONFIG_POWER_AVS)+= avs/
 obj-$(CONFIG_CHARGER_SMB347)   += smb347-charger.o
 obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
+obj-$(CONFIG_CHARGER_BQ24261)  += bq24261-charger.o
 obj-$(CONFIG_POWER_RESET)  += reset/
diff --git a/drivers/power/bq24261-charger.c b/drivers/power/bq24261-charger.c
new file mode 100644
index 000..187c1fe
--- /dev/null
+++ b/drivers/power/bq24261-charger.c
@@ -0,0 +1,1350 @@
+/*
+ * bq24261-charger.c - BQ24261 Charger I2C client driver
+ *
+ * Copyright (C) 2011 Intel Corporation
+ *
+ * ~~
+ *
+ * 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; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#define DEV_NAME "bq24261_charger"
+#define MODEL_NAME_SIZE 8
+
+#define EXCEPTION_MONITOR_DELAY (60 * HZ)
+#define WDT_RESET_DELAY (15 * HZ)
+
+/* BQ24261 registers */
+#define BQ24261_STAT_CTRL0_ADDR0x00
+#define BQ24261_CTRL_ADDR  0x01
+#define BQ24261_BATT_VOL_CTRL_ADDR 0x02
+#define BQ24261_VENDOR_REV_ADDR0x03
+#define BQ24261_TERM_FCC_ADDR  0x04
+#define BQ24261_VINDPM_STAT_ADDR   0x05
+#define BQ24261_ST_NTC_MON_ADDR0x06
+
+#define BQ24261_RESET_MASK (0x01 << 7)
+#define BQ24261_RESET_ENABLE   (0x01 << 7)
+
+#define BQ24261_FAULT_MASK 0x07
+#define BQ24261_STAT_MASK  (0x03 << 4)
+#define BQ24261_BOOST_MASK (0x01 << 6)
+#define BQ24261_TMR_RST_MASK   (0x01 << 7)
+#define BQ24261_TMR_RST(0x01 << 7)
+
+#define BQ24261_ENABLE_BOOST   (0x01 << 6)
+
+#define BQ24261_VOVP   0x01
+#define BQ24261_LOW_SUPPLY 0x02
+#define BQ24261_THERMAL_SHUTDOWN   0x03
+#define BQ24261_BATT_TEMP_FAULT0x04
+#define BQ24261_TIMER_FAULT0x05
+#define BQ24261_BATT_OVP   0x06
+#define BQ24261_NO_BATTERY 0x07
+#define BQ24261_STAT_READY 0x00
+
+#define BQ24261_STAT_CHRG_PRGRSS   (0x01 << 4)
+#define BQ24261_STAT_CHRG_DONE (0x02 << 4)
+#define BQ24261_STAT_FAULT (0x03 << 4)
+
+#define BQ24261_CE_MASK(0x01 << 1)
+#define BQ24261_CE_DISABLE (0x01 << 1)
+
+#define BQ24261_HZ_MASK(0x01)
+#define BQ24261_HZ_ENABLE  (0x01)
+
+#define BQ24261_ICHRG_MASK (0x1F << 3)
+#define BQ24261_MIN_CC 500 /* 500mA */
+#define BQ24261_MAX_CC 3000 /* 3A */
+
+#define BQ24261_ITERM_MASK (0x03)
+#define BQ24261_MIN_ITERM 50 /* 50 mA */
+#define BQ24261_MAX_ITERM 300 /* 

[PATCH 3/4] power_supply: Introduce PSE compliant algorithm

[Jenny TC]

As per Product Safety Engineering (PSE) specification for battery charging, the
battery characteristics and thereby the charging rates can vary on different
temperature zones. This patch introduces a PSE compliant charging algorithm with
maintenance charging support. The algorithm can be selected by the power supply
charging driver based on the type of the battery charging profile.

Signed-off-by: Jenny TC 
---
 drivers/power/Kconfig  |   13 ++
 drivers/power/Makefile |1 +
 drivers/power/charging_algo_pse.c  |  204 
 include/linux/power/power_supply_charger.h |   48 +++
 4 files changed, 266 insertions(+)
 create mode 100644 drivers/power/charging_algo_pse.c

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index f679f82..913ec36 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER
  drivers to keep the charging logic outside and the charger driver
  just need to abstract the charger hardware.
 
+config POWER_SUPPLY_CHARGING_ALGO_PSE
+   bool "PSE compliant charging algorithm"
+   help
+ Say Y here to select Product Safety Engineering (PSE) compliant
+ charging algorithm. As per PSE standard the battery characteristics
+ and thereby the charging rates can vary on different temperature
+ zones. This config will enable PSE compliant charging algorithm with
+ maintenance charging support. At runtime the algorithm will be
+ selected by the psy charger driver based on the type of the battery
+ charging profile.
+
+   depends on POWER_SUPPLY_CHARGER
+
 config PDA_POWER
tristate "Generic PDA/phone power driver"
depends on !S390
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index 405f0f4..77535fd 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_POWER_SUPPLY)  += power_supply.o
 obj-$(CONFIG_GENERIC_ADC_BATTERY)  += generic-adc-battery.o
 
 obj-$(CONFIG_POWER_SUPPLY_CHARGER) += power_supply_charger.o
+obj-$(CONFIG_POWER_SUPPLY_CHARGING_ALGO_PSE) += charging_algo_pse.o
 obj-$(CONFIG_PDA_POWER)+= pda_power.o
 obj-$(CONFIG_APM_POWER)+= apm_power.o
 obj-$(CONFIG_MAX8925_POWER)+= max8925_power.o
diff --git a/drivers/power/charging_algo_pse.c 
b/drivers/power/charging_algo_pse.c
new file mode 100644
index 000..a092e30
--- /dev/null
+++ b/drivers/power/charging_algo_pse.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * ~~
+ *
+ * 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; version 2 of the License.
+ *
+ * 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.
+ *
+ * ~~
+ * Author: Jenny TC 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "power_supply.h"
+#include "power_supply_charger.h"
+
+/* 98% of CV is considered as voltage to detect Full */
+#define FULL_CV_MIN 98
+
+/*
+ * Offset to exit from maintenance charging. In maintenance charging
+ * if the volatge is less than the (maintenance_lower_threshold -
+ * MAINT_EXIT_OFFSET) then system can switch to normal charging
+ */
+
+#define MAINT_EXIT_OFFSET 50  /* mV */
+
+static int get_tempzone(struct psy_pse_chrg_prof *pse_mod_bprof,
+   int temp)
+{
+   int i = 0;
+   int temp_range_cnt = min_t(u16, pse_mod_bprof->temp_mon_ranges,
+   BATT_TEMP_NR_RNG);
+
+   if ((temp < pse_mod_bprof->temp_low_lim) ||
+   (temp > pse_mod_bprof->temp_mon_range[0].temp_up_lim))
+   return -EINVAL;
+
+   for (i = 0; i < temp_range_cnt; ++i)
+   if (temp > pse_mod_bprof->temp_mon_range[i].temp_up_lim)
+   break;
+   return i-1;
+}
+
+static inline bool __is_battery_full(long volt, long cur,
+   long iterm, unsigned long cv)
+{
+   pr_devel("%s:current=%ld pse_mod_bprof->chrg_term_mA =%ld 
voltage_now=%ld full_cond=%ld",
+   __func__, cur, iterm, volt * 100, (FULL_CV_MIN * cv));
+
+   return (cur > 0) && (cur <= iterm) &&
+   ((volt * 100)  >= (FULL_CV_MIN * cv));
+
+}
+
+static inline bool is_battery_full(struct psy_batt_props bat_prop,
+   struct psy_pse_chrg_prof *pse_mod_bprof, unsigned long cv)
+{
+
+   int i;
+
+   /*
+   * Software full detection. Check the 

[PATCH 1/4] power_supply: Add inlmt,iterm, min/max temp props

[Jenny TC]

Add new power supply properties for input current, charge termination
current, min and max temperature

POWER_SUPPLY_PROP_TEMP_MIN - minimum operatable temperature
POWER_SUPPLY_PROP_TEMP_MAX - maximum operatable temperature

POWER_SUPPLY_PROP_INLMT - input current limit programmed by charger. Indicates
the input current for a charging source.

POWER_SUPPLY_PROP_CHARGE_TERM_CUR - Charge termination current used to detect
the end of charge condition

Signed-off-by: Jenny TC 
---
 Documentation/power/power_supply_class.txt |6 ++
 drivers/power/power_supply_sysfs.c |4 
 include/linux/power_supply.h   |4 
 3 files changed, 14 insertions(+)

diff --git a/Documentation/power/power_supply_class.txt 
b/Documentation/power/power_supply_class.txt
index 89a8816..48cff88 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -118,6 +118,10 @@ relative, time-based measurements.
 CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger.
 CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the
 power supply object.
+INPUT_CURRENT_LIMIT - input current limit programmed by charger. Indicates
+the current drawn from a charging source.
+CHARGE_TERM_CURRENT - Charge termination current used to detect the end of 
charge
+condition.
 
 CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
 CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
@@ -140,6 +144,8 @@ TEMP_ALERT_MAX - maximum battery temperature alert.
 TEMP_AMBIENT - ambient temperature.
 TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
 TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
+TEMP_MIN - minimum operatable temperature
+TEMP_MAX - maximum operatable temperature
 
 TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
 while battery powers a load)
diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index 44420d1..750a202 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -167,6 +167,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(constant_charge_voltage_max),
POWER_SUPPLY_ATTR(charge_control_limit),
POWER_SUPPLY_ATTR(charge_control_limit_max),
+   POWER_SUPPLY_ATTR(input_current_limit),
POWER_SUPPLY_ATTR(energy_full_design),
POWER_SUPPLY_ATTR(energy_empty_design),
POWER_SUPPLY_ATTR(energy_full),
@@ -178,6 +179,8 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(capacity_alert_max),
POWER_SUPPLY_ATTR(capacity_level),
POWER_SUPPLY_ATTR(temp),
+   POWER_SUPPLY_ATTR(temp_max),
+   POWER_SUPPLY_ATTR(temp_min),
POWER_SUPPLY_ATTR(temp_alert_min),
POWER_SUPPLY_ATTR(temp_alert_max),
POWER_SUPPLY_ATTR(temp_ambient),
@@ -189,6 +192,7 @@ static struct device_attribute power_supply_attrs[] = {
POWER_SUPPLY_ATTR(time_to_full_avg),
POWER_SUPPLY_ATTR(type),
POWER_SUPPLY_ATTR(scope),
+   POWER_SUPPLY_ATTR(charge_term_current),
/* Properties of type `const char *' */
POWER_SUPPLY_ATTR(model_name),
POWER_SUPPLY_ATTR(manufacturer),
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index c9dc4e0..0278600 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -120,6 +120,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE_MAX,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT,
POWER_SUPPLY_PROP_CHARGE_CONTROL_LIMIT_MAX,
+   POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN,
POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN,
POWER_SUPPLY_PROP_ENERGY_FULL,
@@ -131,6 +132,8 @@ enum power_supply_property {
POWER_SUPPLY_PROP_CAPACITY_ALERT_MAX, /* in percents! */
POWER_SUPPLY_PROP_CAPACITY_LEVEL,
POWER_SUPPLY_PROP_TEMP,
+   POWER_SUPPLY_PROP_TEMP_MAX,
+   POWER_SUPPLY_PROP_TEMP_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MIN,
POWER_SUPPLY_PROP_TEMP_ALERT_MAX,
POWER_SUPPLY_PROP_TEMP_AMBIENT,
@@ -142,6 +145,7 @@ enum power_supply_property {
POWER_SUPPLY_PROP_TIME_TO_FULL_AVG,
POWER_SUPPLY_PROP_TYPE, /* use power_supply.type instead */
POWER_SUPPLY_PROP_SCOPE,
+   POWER_SUPPLY_PROP_CHARGE_TERM_CURRENT,
/* Properties of type `const char *' */
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
-- 
1.7.9.5

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

[PATCH v6 0/4] power_supply: Introduce power supply charging driver

[Jenny TC]

v1: introduced feature as a framework within power supply class driver with
separate files for battid framework and charging framework
v2: fixed review comments, moved macros and inline functions to power_supply.h
v3: moved the feature as a separate driver, combined battid framework and
charging framework inside the power supply charging driver. Moved
charger specific properties to power_supply_charger.h and plugged the
driver with power supply subsystem using power_supply_notifier
introduced in my previous patch. Also a sample charger chip driver
(bq24261) patch added to give more idea on the psy charging driver
usage
v4: Fixed review comments, no major design changes.
v5: Fixed makefile inconsistencies, removed unused pdata callbacks
v6: Fixed nested loops, commenting style

The Power Supply charging driver connects multiple subsystems
to do charging in a generic way. The subsystems involves power_supply,
thermal and battery communication subsystems (1wire).With this the charging is
handled in a generic way.

The driver makes use of different new features - Battery Identification
interfaces, pluggable charging algorithms, charger cable arbitrations etc.
The patch also introduces generic interface for charger cable notifications.
Charger cable events and capabilities can be notified using the generic
power_supply_notifier chain.

Overall this driver removes the charging logic out of the charger chip driver
and the charger chip driver can just listen to the request from the power
supply charging driver to set the charger properties. This can be implemented
by exposing get_property and set property callbacks.

Jenny TC (4):
  power_supply: Add inlmt,iterm, min/max temp props
  power_supply: Introduce generic psy charging driver
  power_supply: Introduce PSE compliant algorithm
  power_supply: bq24261 charger driver

 Documentation/power/power_supply_charger.txt |  353 +++
 Documentation/power/power_supply_class.txt   |6 +
 drivers/power/Kconfig|   31 +
 drivers/power/Makefile   |3 +
 drivers/power/bq24261-charger.c  | 1350 ++
 drivers/power/charging_algo_pse.c|  204 
 drivers/power/power_supply_charger.c | 1186 ++
 drivers/power/power_supply_charger.h |  218 +
 drivers/power/power_supply_core.c|3 +
 drivers/power/power_supply_sysfs.c   |4 +
 include/linux/power/bq24261-charger.h|   25 +
 include/linux/power/power_supply_charger.h   |  235 +
 include/linux/power_supply.h |  164 
 13 files changed, 3782 insertions(+)
 create mode 100644 Documentation/power/power_supply_charger.txt
 create mode 100644 drivers/power/bq24261-charger.c
 create mode 100644 drivers/power/charging_algo_pse.c
 create mode 100644 drivers/power/power_supply_charger.c
 create mode 100644 drivers/power/power_supply_charger.h
 create mode 100644 include/linux/power/bq24261-charger.h
 create mode 100644 include/linux/power/power_supply_charger.h

-- 
1.7.9.5

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

Re: [PATCH 1/1] fs: xattr: Don't display attributes without read access

[Fabian Frederick]

On Tue, 18 Feb 2014 15:16:50 -0800
Andrew Morton  wrote:

> On Sun, 16 Feb 2014 20:31:01 +0800 Fabian Frederick  wrote:
> 
> > Any user can display extented attribute names without read
> > access.
> > 
> > eg: attr -l 
> > 
> > This patch checks inode_permission in listxattr common
> > function before executing vfs_listxattr.
> > 
> > ...
> >
> > --- a/fs/xattr.c
> > +++ b/fs/xattr.c
> > @@ -543,6 +543,10 @@ listxattr(struct dentry *d, char __user *list, size_t 
> > size)
> > char *klist = NULL;
> > char *vlist = NULL; /* If non-NULL, we used vmalloc() */
> >  
> > +   error = inode_permission(d->d_inode, MAY_READ);
> > +   if (error)
> > +   return error;
> > +
> > if (size) {
> > if (size > XATTR_LIST_MAX)
> > size = XATTR_LIST_MAX;
> 
> erk.  Doesn't this mean that if existing userspace is relying on the
> current behaviour, this patch will cause breakage?
> 
FYI, I just noticed FreeBSD was giving the expected result : no attribute name 
revealed
 without read access  
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: mmotm 2014-02-19-16-07 uploaded (sound/soc/intel/sst-dsp.c)

[Randy Dunlap]

On 02/19/14 16:08, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2014-02-19-16-07 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 

on i386:
(from linux-next)

  CC  sound/soc/intel/sst-dsp.o
sound/soc/intel/sst-dsp.c: In function 'sst_dsp_outbox_write':
sound/soc/intel/sst-dsp.c:218:2: error: implicit declaration of function 
'memcpy_toio' [-Werror=implicit-function-declaration]
sound/soc/intel/sst-dsp.c: In function 'sst_dsp_outbox_read':
sound/soc/intel/sst-dsp.c:231:2: error: implicit declaration of function 
'memcpy_fromio' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[4]: *** [sound/soc/intel/sst-dsp.o] Error 1


-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm

[Jenny Tc]

On Tue, Feb 04, 2014 at 12:36:40PM +0100, Pavel Machek wrote:
> > --- a/drivers/power/Kconfig
> > +++ b/drivers/power/Kconfig
> > @@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER
> >   drivers to keep the charging logic outside and the charger driver
> >   just need to abstract the charger hardware.
> >  
> > +config POWER_SUPPLY_CHARGING_ALGO_PSE
> > +   bool "PSE compliant charging algorithm"
> > +   help
> > + Say Y here to select Product Safety Engineering (PSE) compliant
> > + charging algorithm. As per PSE standard the battery characteristics
> > + and thereby the charging rates can vary on different temperature
> > + zones. This config will enable PSE compliant charging algorithm with
> > + maintenance charging support. At runtime the algorithm will be
> > + selected by the psy charger driver based on the type of the battery
> > + charging profile.
> 
> Information where to expect PSE compliant chargers would be nice.

This algorithm can be used with non PSE compliant chargers also. This is a SW
based charging algorithm.

-Jenny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] virtio: Use pci_enable_msix_range() instead of pci_enable_msix()

[Michael S. Tsirkin]

On Wed, Feb 19, 2014 at 11:15:29AM +0100, Alexander Gordeev wrote:
> As result deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
> 
> Signed-off-by: Alexander Gordeev 
> Cc: Rusty Russell 
> Cc: "Michael S. Tsirkin" 
> Cc: virtio-...@lists.oasis-open.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: linux-...@vger.kernel.org

Acked-by: Michael S. Tsirkin 

> ---
>  drivers/virtio/virtio_pci.c |8 +++-
>  1 files changed, 3 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
> index a416f9b..dea042c 100644
> --- a/drivers/virtio/virtio_pci.c
> +++ b/drivers/virtio/virtio_pci.c
> @@ -333,11 +333,9 @@ static int vp_request_msix_vectors(struct virtio_device 
> *vdev, int nvectors,
>   for (i = 0; i < nvectors; ++i)
>   vp_dev->msix_entries[i].entry = i;
>  
> - /* pci_enable_msix returns positive if we can't get this many. */
> - err = pci_enable_msix(vp_dev->pci_dev, vp_dev->msix_entries, nvectors);
> - if (err > 0)
> - err = -ENOSPC;
> - if (err)
> + err = pci_enable_msix_range(vp_dev->pci_dev,
> + vp_dev->msix_entries, nvectors, nvectors);
> + if (err < 0)
>   goto error;
>   vp_dev->msix_enabled = 1;
>  
> -- 
> 1.7.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Progress, very small, on making a boot.

[Gene Heskett]

On Wednesday 19 February 2014 Randy Dunlap did write:

Lets start with a clean slate here.  See the image from trying to boot 
a 3.13.3 made from the repaired 3.12.9 .config file via an edit to 
re-enable the missing media stuffs followed by a make oldconfig.

Fresh boot pix, not as well focused as I'd like, at the usual link in my
signature. This camera seems not to be able to nail the autofocus dead on
when trying to range find this dell monitors anti-reflective screen and
of course its "available light" so the exposure is a goodly fraction of
a second.

Link in my sig, click on Genes-os9-stf/LCNC/, the .JPG there.

I see two errors, one just a couple lines from the top, and of course the 
non-find of ATA1 stuff that started all this, and at the bottom, an attempt, 
and a fuss over ATA6 which does not even exist.  There are 4 active 1 Tb 
drives, ATA1-ATA4, followed by a sata interfaced dvd writer, ATA5. MoBo 
sockets for SATA6 and SATA7 are empty.

Are we being bamboozled by an off by one error in the sata_nv code? Some
post 3.12.9 patch perhaps?

Should I go get the ChangeLogs and start grepping for sata_nv?

blkid output booted to 3.12.9:
gene@coyote:/opt/Genes-os9-stf/LCNC$ sudo blkid
/dev/sda1: LABEL="ububoot" UUID="f54ba7af-1545-43f3-a86e-bfc0017b4526" 
SEC_TYPE="ext2" TYPE="ext3" 
/dev/sda2: LABEL="uburoot" UUID="ec677e9c-6be6-4311-b97b-3889d42ce6ef" 
TYPE="ext4" 
/dev/sda3: UUID="edc2880e-257d-4521-8220-0df5b57dcae4" TYPE="swap" 
/dev/sdb1: UUID="80ab0463-d6fc-4f5b-af08-5aa43d55fdf8" SEC_TYPE="ext2" 
TYPE="ext3" 
/dev/sdb5: UUID="b4841721-a040-48bc-80dc-e742164ad38a" TYPE="swap" 
/dev/sdc1: UUID="1321fc90-ba7a-4742-8176-f7b3a8284be5" TYPE="ext4" 
/dev/sdc2: LABEL="amandatapes-1-T" UUID="b7657920-d9a2-4379-ae21-08a0651b65cc" 
SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdd1: LABEL="home2" UUID="7601432d-7a30-42a3-80b5-57f08ae71f2a" 
TYPE="ext4" 
/dev/sdd2: LABEL="opt2" UUID="748b01e1-ae7b-4b17-b8e9-c88429bcefbf" TYPE="ext4" 
/dev/sr0: LABEL="10-302-50-1" TYPE="iso9660" 

Your thoughts?

Thanks Randy.
Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

NOTICE: Will pay 100 USD for an HP-4815A defective but
complete probe assembly.

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

Re: [PATCH 4/4] power_supply: bq24261 charger driver

[Jenny Tc]

On Tue, Feb 04, 2014 at 12:36:21PM +0100, Pavel Machek wrote:
> > +#define BQ24261_MIN_CV 3500
> > +#define BQ24261_MAX_CV 4440
> 
> Other defines use uV as an unit :-(.

uV is used if the value is read from psy class. For register configurations
uses mV. Will change the name to reflect mV

> > +   /* If status is fault, wait for READY before enabling the charging */
> > +
> > +   if (!is_ready) {
> > +   ret = wait_event_timeout(chip->wait_ready,
> > +   (chip->chrgr_stat != BQ24261_CHRGR_STAT_READY),
> > +   HZ);
> > +   dev_info(>client->dev,
> > +   "chrgr_stat=%x\n", chip->chrgr_stat);
> > +   if (ret == 0) {
> > +   dev_err(>client->dev,
> > +   "Waiting for Charger Ready Failed.Enabling 
> > charging anyway\n");
> > +   }
> > +   }
> 
> So charger has a problem, and we force it on, anyway? Also put space
> after ".".

Yes, sometimes charger does not give ready, so we force.
> 
> > +static inline int bq24261_set_cv(struct bq24261_charger *chip, int cv)
> > +{
> > +   int bat_volt;
> > +   int ret;
> > +   u8 reg_val;
> > +   u8 vindpm_val = 0x0;
> > +
> > +   /*
> > +   * Setting VINDPM value as per the battery voltage
> > +   *  VBatt   Vindpm Register Setting
> > +   *  < 3.7v   4.2v   0x0 (default)
> > +   *  3.71v - 3.96v4.36v  0x2
> > +   *  > 3.96v  4.6v   0x5
> > +   */
> > +   ret = get_battery_voltage(_volt);
> > +   if (ret) {
> > +   dev_err(>client->dev,
> > +   "Error getting battery voltage!!\n");
> > +   } else {
> 
> You forget the error value and continue anyway.

On error, throw the error and program default VINDPM value.

-Jenny
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] mm: Clean up style in install_special_mapping()

[tip-bot for H. Peter Anvin]

Commit-ID:  3af7111e2066a641510c16a4e9e82dd81550115b
Gitweb: http://git.kernel.org/tip/3af7111e2066a641510c16a4e9e82dd81550115b
Author: H. Peter Anvin 
AuthorDate: Wed, 19 Feb 2014 20:46:57 -0800
Committer:  H. Peter Anvin 
CommitDate: Wed, 19 Feb 2014 20:46:57 -0800

mm: Clean up style in install_special_mapping()

We can clean up the style in install_special_mapping(), and make it
use PTR_ERR_OR_ZERO().

Reported-by: kbuild test robot 
Link: 
http://lkml.kernel.org/r/1392587568-7325-3-git-send-email-stef...@seibold.net
Signed-off-by: H. Peter Anvin 
---
 mm/mmap.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 81ba54f..6b78a77 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -2959,12 +2959,10 @@ int install_special_mapping(struct mm_struct *mm,
unsigned long addr, unsigned long len,
unsigned long vm_flags, struct page **pages)
 {
-   struct vm_area_struct *vma = _install_special_mapping(mm,
-   addr, len, vm_flags, pages);
+   struct vm_area_struct *vma;
 
-   if (IS_ERR(vma))
-   return PTR_ERR(vma);
-   return 0;
+   vma = _install_special_mapping(mm, addr, len, vm_flags, pages);
+   return PTR_ERR_OR_ZERO(vma);
 }
 
 static DEFINE_MUTEX(mm_all_locks_mutex);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[David Rientjes]

On Wed, 19 Feb 2014, Luiz Capitulino wrote:

> > Yes, my concrete objection is that the command line interface is 
> > unnecessary if you can dynamically allocate and free 1GB pages at runtime 
> > unless memory will be so fragmented that it cannot be done when userspace 
> > is brought up.  That is not your use case, thus this support is not 
> 
> Yes it is. The early boot is the most reliable moment to allocate huge pages
> and we want to take advantage from that.
> 

Your use case is 8GB of hugepages on a 32GB machine.  It shouldn't be 
necessary to do that at boot.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[Luiz Capitulino]

On Wed, 19 Feb 2014 19:46:41 -0800 (PST)
David Rientjes  wrote:

> On Wed, 19 Feb 2014, Marcelo Tosatti wrote:
> 
> > We agree that, in the future, we'd like to provide the ability to
> > dynamically allocate and free 1GB pages at runtime.
> > 
> > Extending the kernel command line interface is a first step.
> > 
> > Do you have a concrete objection to that first step ?
> > 
> 
> Yes, my concrete objection is that the command line interface is 
> unnecessary if you can dynamically allocate and free 1GB pages at runtime 
> unless memory will be so fragmented that it cannot be done when userspace 
> is brought up.  That is not your use case, thus this support is not 

Yes it is. The early boot is the most reliable moment to allocate huge pages
and we want to take advantage from that.

I would understand your position against this series if it was intrusive
or if it was changing the code in an undesirable way, but the code it adds
is completely self-contained and runs only once at boot. It gives us just
one more choice for huge pages allocation at boot. I don't see the huge
problem here.

> needed.  I think Mel also brought up this point.
>
> There's no "first step" about it, this is unnecessary for your use case if 
> you can do it at runtime.  I'm not sure what's so surprising about this.
> 
> > > You can't specify an interleave behavior with Luiz's command line 
> > > interface so now we'd have two different interfaces for allocating 
> > > hugepage sizes depending on whether you're specifying a node or not.  
> > > It's "hugepagesz=1G hugepages=16" vs "hugepage_node=1:16:1G" (and I'd 
> > > have 
> > > to look at previous messages in this thread to see if that means 16 1GB 
> > > pages on node 1 or 1 1GB pages on node 16.)
> > 
> > What syntax do you prefer and why ?
> > 
> 
> I'm not sure it's interesting to talk about since this patchset is 
> unnecessary if you can do it at runtime, but since "hugepagesz=" and 
> "hugepages=" have existed for many kernel releases, we must maintain 
> backwards compatibility.  Thus, it seems, the easiest addition would have 
> been "hugepagesnode=" which I've mentioned several times, there's no 
> reason to implement yet another command line option purely as a shorthand 
> which hugepage_node=1:2:1G is and in a very cryptic way.
> 

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

Re: [RFC][PATCH 0/5] arch: atomic rework

[Linus Torvalds]

On Wed, Feb 19, 2014 at 8:01 PM, Paul E. McKenney
 wrote:
>
> The control dependency should order subsequent stores, at least assuming
> that "a" and "b" don't start off with identical stores that the compiler
> could pull out of the "if" and merge.  The same might also be true for ?:
> for all I know.  (But see below)

Stores I don't worry about so much because

 (a) you can't sanely move stores up in a compiler anyway
 (b) no sane CPU or moves stores up, since they aren't on the critical path

so a read->cmp->store is actually really hard to make anything sane
re-order. I'm sure it can be done, and I'm sure it's stupid as hell.

But that "it's hard to screw up" is *not* true for a load->cmp->load.

So lets make this really simple: if you have a consume->cmp->read, is
the ordering of the two reads guaranteed?

> As long as there is an unbroken chain of -data- dependencies from the
> consume to the later access in question, and as long as that chain
> doesn't go through the excluded operations, yes.

So let's make it *really* specific, and make it real code doing a real
operation, that is actually realistic and reasonable in a threaded
environment, and may even be in some critical code.

The issue is the read-side ordering guarantee for 'a' and 'b', for this case:

 - Initial state:

   a = b = 0;

 - Thread 1 ("consumer"):

if (atomic_read(, consume))
 return b;
/* not yet initialized */
return -1;

 - Thread 2 ("initializer"):

 b = some_value_lets_say_42;
 /* We are now ready to party */
 atomic_write(, 1, release);

and quite frankly, if there is no ordering guarantee between the read
of "a" and the read of "b" in the consumer thread, then the C atomics
standard is broken.

Put another way: I claim that if "thread 1" ever sees a return value
other than -1 or 42, then the whole definition of atomics is broken.

Question 2: and what changes if the atomic_read() is turned into an
acquire, and why? Does it start working?

> Neither has a data-dependency guarantee, because there is no data
> dependency from the load to either "a" or "b".  After all, the value
> loaded got absorbed into the "if" condition.  However, according to
> discussions earlier in this thread, the "if" variant would have a
> control-dependency ordering guarantee for any stores in "a" and "b"
> (but not loads!).

So exactly what part of the standard allows the loads to be
re-ordered, and why? Quite frankly, I'd think that any sane person
will agree that the above code snippet is realistic, and that my
requirement that thread 1 sees either -1 or 42 is valid.

And if the C standards body has said that control dependencies break
the read ordering, then I really think that the C standards committee
has screwed up.

If the consumer of an atomic load isn't a pointer chasing operation,
then the consume should be defined to be the same as acquire. None of
this "conditionals break consumers". No, conditionals on the
dependency path should turn consumers into acquire, because otherwise
the "consume" load is dangerous as hell.

And if the definition of acquire doesn't include the control
dependency either, then the C atomic memory model is just completely
and utterly broken, since the above *trivial* and clearly useful
example is broken.

I really think the above example is pretty damn black-and-white.
Either it works, or the standard isn't worth wiping your ass with.

  Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] softirq: stable v3.1[23] (others?) have screaming tasklet disease - ksoftirqd[random] eats 100% CPU

[Mike Galbraith]

On Thu, 2014-02-20 at 01:00 +0100, Thomas Gleixner wrote: 
> On Wed, 19 Feb 2014, Mike Galbraith wrote:
> > I'm seeing ksoftirqd chewing 100% CPU on one or more CPUs in both 3.12
> > and 3.13, as below in a 40 core (+smt) box.  It should look very
> > familiar to CCs, especially Ingo.
> > 
> > Below, tasklet is disabled by ioat2_free_chan_resources, and what I
> > presume was systemd-udevd-1050 starts screaming when it meets same,
> > until debug patchlet turns tracing off.  Once the box was up such that I
> > could login, 1050 was long gone, and ksoftirqd had taken over.
> > 
> >systemd-udevd-976   [016] 27.467534: ioat_init_channel: 
> > tasklet_disable_nosync 880465b8bee8
> >systemd-udevd-976   [016] 27.467649: ioat2_alloc_chan_resources: 
> > tasklet_enable 880465b8bee8
> >   -0 [072] ..s.27.467659: tasklet_action: ENTER 
> > struct tasklet_struct *list: 880465b8bee8
> >   -0 [072] .Ns.27.467667: tasklet_action: LOOP struct 
> > tasklet_struct *t = list: 880465b8bee8
> >   -0 [072] .Ns.27.467673: tasklet_action: LOOP 
> > processed 880465b8bee8
> >systemd-udevd-976   [016] 27.467679: ioat2_free_chan_resources: 
> > tasklet_disable_nosync 880465b8bee8
> >systemd-udevd-1034  [000] .Ns.27.467917: tasklet_action: ENTER 
> > struct tasklet_struct *list: 880465b8bee8
> >systemd-udevd-1034  [000] .Ns.27.467918: tasklet_action: LOOP struct 
> > tasklet_struct *t = list: 880465b8bee8
> ><...>-1050  [000] ..s.27.468203: tasklet_action: ENTER 
> > struct tasklet_struct *list: 880465b8bee8
> ><...>-1050  [000] ..s.27.468204: tasklet_action: LOOP struct 
> > tasklet_struct *t = list: 880465b8bee8
> ><...>-1050  [000] ..s.27.468204: tasklet_action: ENTER 
> > struct tasklet_struct *list: 880465b8bee8
> ><...>-1050  [000] ..s.27.468205: tasklet_action: LOOP struct 
> > tasklet_struct *t = list: 880465b8bee8
> > ... much no processing, see tasklet disabled, raise softirq - wash rinse 
> > repeat
> ><...>-1050  [000] ..s.27.469561: tasklet_action: ENTER 
> > struct tasklet_struct *list: 880465b8bee8
> ><...>-1050  [000] ..s.27.469562: tasklet_action: LOOP struct 
> > tasklet_struct *t = list: 880465b8bee8
> ><...>-1050  [000] ..s.27.469563: tasklet_action: LOOP 
> > tasklet disabled 880465b8bee8 - It's dead Jim
> > 
> > Hm, he says, now where have I seen text describing that trace?  Right,
> > RT, and the below fixes screaming NOPREEMPT kernels.
> > 
> > Taken from 3.12-rt, and applied to screaming 3.12.11-virgin
> 
> Indeed. That's a very similar issue just for different reasons. The RT
> case is special as the mainline usage side of tasklets do not expect
> the preemption scenario.
> 
> But this one is clearly a driver issue.

rapidio::tsi721_free_chan_resources() appears to do the same.  Joy.

> The window where you can bring a machine into that state is infinite
> large. Lets look at the tasklet_schedule --> softirq sequence:
> 
> tasklet_schedule(t)
>   set_bit(TASKLET_STATE_SCHED, >state);
>   queue_tasklet_on_cpu_list(t);
>   raise_softirq();
> 
> softirq()
>   splice_tasklet_cpu_list(cpu_list, list);
>   while (list) {
> t = list;
> list = t->next;
> /* Sets the TASKLET_STATE_RUN bit ! */
> if (tasklet_trylock(t) {
>   if (!atomic_read(>count)) {   <- 
>   clear_bit(TASKLET_STATE_SCHED, >state);
>   t->func();
>   /* Clear the TASKLET_STATE_RUN bit */
>   tasklet_unlock();
>   continue;
>   }
> tasklet_unlock();
> queue_tasklet_on_cpu_list(t);
> raise_softirq();
>   }  
> 
> So up to the atomic_read in the softirq all calls to tasklet_disable()
> even if issued eons before that point are going to put the softirq
> into an infinite loop when the tasklet is scheduled.
> 
> Even if we would put a check for the disabled state into
> tasklet_schedule there would be still the window between the schedule
> and the actual softirq handling. And we even can't add that check
> because that would break "sane" use sites of tasklet_disable.
> 
> tasklet_disable/enable is only meant for temporary, i.e. over a very
> short code sequence, preventing the execution of the tasklet.
> 
> The usage of tasklet_disable() in teardown scenarios is completely
> broken. The only way to do that is to have a proper serialization of
> the teardown versus the interrupt which schedules the tasklet:
> 
>   /*
>* First step.
>*/
>   disable_interrupt_at_device_or_irq_line_level();
> 
>   /*
>* This makes sure that even a spurious interrupt which
>* arrives _AFTER_ the synchronize_irq() cannot schedule
>* the tasklet anymore.
>*/
>   tell_interrupt_to_not_schedule_tasklet();
> 
>   /* Make sure that no interrupt is on the fly */
>   

Re: sched: hang in migrate_swap

[Michael wang]

On 02/20/2014 02:08 AM, Sasha Levin wrote:
> Hi all,
> 
> While fuzzing with trinity inside a KVM tools guest, running latest
> -next kernel, I see to hit the following hang quite often.

Fix for the stuck issue around idle_balance() is now in progress, this
may caused be the same problem, I suggest we do some retest after these
patch got merged.

Regards,
Michael Wang

> 
> The initial spew is:
> 
> [  293.110057] BUG: soft lockup - CPU#8 stuck for 22s! [migration/8:258]
> [  293.110057] Modules linked in:
> [  293.110057] irq event stamp: 20828
> [  293.110057] hardirqs last  enabled at (20827): []
> restore_args+0x0/0x30
> [  293.110057] hardirqs last disabled at (20828): []
> apic_timer_interrupt+0x6d/0x80
> [  293.110057] softirqs last  enabled at (20826): []
> __do_softirq+0x447/0x4f0
> [  293.110057] softirqs last disabled at (20821): []
> irq_exit+0x83/0x160
> [  293.110057] CPU: 8 PID: 258 Comm: migration/8 Tainted: GW
> 3.14.0-rc3-next-20140218-sasha-8-g16140ff-dirty #109
> [  293.110057] task: 8805b8283000 ti: 8805b82c task.ti:
> 8805b82c
> [  293.110057] RIP: 0010:[]  []
> multi_cpu_stop+0xc2/0x1c0
> [  293.110057] RSP: :8805b82c1cd8  EFLAGS: 0293
> [  293.110057] RAX: 0001 RBX: 84385437 RCX:
> 
> [  293.110057] RDX: 0001 RSI: 0001 RDI:
> 8800c40bb978
> [  293.110057] RBP: 8805b82c1d18 R08:  R09:
> 
> [  293.110057] R10: 0001 R11: 0001 R12:
> 8805b82c1c48
> [  293.110057] R13: 8805b8283000 R14: 8805b82c R15:
> 8805b8283000
> [  293.110057] FS:  () GS:8805b900()
> knlGS:
> [  293.110057] CS:  0010 DS:  ES:  CR0: 8005003b
> [  293.110057] CR2: 00942d58 CR3: 05c26000 CR4:
> 06e0
> [  293.110057] DR0: 0089e000 DR1: 7f938d51a000 DR2:
> 
> [  293.110057] DR3:  DR6: 0ff0 DR7:
> 0600
> [  293.110057] Stack:
> [  293.110057]  8805b91d0be0 c40bb9d8 8805b82c1cf8
> 8805b91d0be0
> [  293.110057]  8800c40bba28 812037d0 8800c40bb978
> 8805b91d0c30
> [  293.110057]  8805b82c1de8 81202f56 0001
> 81202e44
> [  293.110057] Call Trace:
> [  293.110057]  [] ? stop_cpus+0x60/0x60
> [  293.110057]  [] cpu_stopper_thread+0x96/0x190
> [  293.110057]  [] ? cpu_stop_should_run+0x44/0x60
> [  293.110057]  [] ? __lock_release+0x1da/0x1f0
> [  293.110057]  [] ?
> _raw_spin_unlock_irqrestore+0x65/0xb0
> [  293.110057]  [] ? trace_hardirqs_on+0xd/0x10
> [  293.110057]  [] smpboot_thread_fn+0x2b6/0x2c0
> [  293.110057]  [] ?
> smpboot_register_percpu_thread+0x100/0x100
> [  293.110057]  [] kthread+0x105/0x110
> [  293.110057]  [] ? wait_for_completion+0xc2/0x110
> [  293.110057]  [] ? set_kthreadd_affinity+0x30/0x30
> [  293.110057]  [] ret_from_fork+0x7c/0xb0
> [  293.110057]  [] ? set_kthreadd_affinity+0x30/0x30
> [  293.110057] Code: b5 05 01 66 0f 1f 44 00 00 45 89 ed 4d 0f a3 2e 45
> 19 ed 45 85 ed 41 0f 95 c7 4c 8d 73 24 31 c0 c7 45 cc 00 00 00 00 66 90
> f3 90 <44> 8b 6b 20 41 39 c5 74 66 41 83 fd 02 74 0f 41 83 fd 03 75 41
> 
> This is followed by a dump of the rest of the CPU states, and I see the
> following:
> 
> [  268.450444] NMI backtrace for cpu 34
> [  268.450444] CPU: 34 PID: 9859 Comm: trinity-c129 Tainted: GW
> 3.14.0-rc3-next-20140218-sasha-8-g16140ff-dirty #109
> [  268.450444] task: 880154aa3000 ti: 8800c40ba000 task.ti:
> 8800c40ba000
> [  268.450444] RIP: 0010:[]  []
> pvclock_clocksource_read+0x1a/0xc0
> [  268.450444] RSP: 0018:8800c40bb538  EFLAGS: 0082
> [  268.450444] RAX: 905f62ec RBX: 8805b93d8500 RCX:
> 000a
> [  268.450444] RDX: 00a1 RSI: 0040 RDI:
> 881027f12880
> [  268.450444] RBP: 8800c40bb548 R08:  R09:
> 0001
> [  268.450444] R10: 0002 R11: 0001 R12:
> 8805b93d8510
> [  268.450444] R13:  R14:  R15:
> 0001
> [  268.450444] FS:  7f938e16a700() GS:8805b920()
> knlGS:
> [  268.450444] CS:  0010 DS:  ES:  CR0: 8005003b
> [  268.450444] CR2: 7f938a658a38 CR3: c40b2000 CR4:
> 06e0
> [  268.450444] DR0: 0089e000 DR1: 7f938d51a000 DR2:
> 
> [  268.450444] DR3:  DR6: 0ff0 DR7:
> 00f7060a
> [  268.450444] Stack:
> [  268.450444]  8805b93d8500 8805b93d8510 8800c40bb558
> 810b6f04
> [  268.450444]  8800c40bb568 81076e1d 8800c40bb598
> 81180635
> [  268.450444]  875f7be0 0022 001d8500
> 8805b93d8500
> [  268.450444] Call Trace:
> [  268.450444]  [] kvm_clock_read+0x24/0x50
> [  268.450444]  [] 

Re: [PATCH] virtio: Use pci_enable_msix_range() instead of pci_enable_msix()

[Rusty Russell]

Alexander Gordeev  writes:
> As result deprecation of MSI-X/MSI enablement functions
> pci_enable_msix() and pci_enable_msi_block() all drivers
> using these two interfaces need to be updated to use the
> new pci_enable_msi_range() and pci_enable_msix_range()
> interfaces.
>
> Signed-off-by: Alexander Gordeev 
> Cc: Rusty Russell 
> Cc: "Michael S. Tsirkin" 
> Cc: virtio-...@lists.oasis-open.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: linux-...@vger.kernel.org
> ---
>  drivers/virtio/virtio_pci.c |8 +++-
>  1 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
> index a416f9b..dea042c 100644
> --- a/drivers/virtio/virtio_pci.c
> +++ b/drivers/virtio/virtio_pci.c
> @@ -333,11 +333,9 @@ static int vp_request_msix_vectors(struct virtio_device 
> *vdev, int nvectors,
>   for (i = 0; i < nvectors; ++i)
>   vp_dev->msix_entries[i].entry = i;
>  
> - /* pci_enable_msix returns positive if we can't get this many. */
> - err = pci_enable_msix(vp_dev->pci_dev, vp_dev->msix_entries, nvectors);
> - if (err > 0)
> - err = -ENOSPC;
> - if (err)
> + err = pci_enable_msix_range(vp_dev->pci_dev,
> + vp_dev->msix_entries, nvectors, nvectors);
> + if (err < 0)
>   goto error;
>   vp_dev->msix_enabled = 1;

I've put this in my pending queue, but in case someone else wants to
take it:

Acked-by: Rusty Russell 

Cheers,
Rusty.

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

Re: [PATCH 01/17 v2] Input - arizona-haptics: Fix double lock of dapm_mutex

[Dmitry Torokhov]

On February 19, 2014 7:54:31 PM PST, Mark Brown  wrote:
>On Tue, Feb 18, 2014 at 03:22:12PM +, Charles Keepax wrote:
>> snd_soc_dapm_sync takes the dapm_mutex internally, but we currently
>take
>> it externally as well. This patch fixes this.
>
>Dimitry, are you OK with this being merged via ASoC?  The subsequent
>improvements to the infrastructure and fix this more generally build on
>top of this one so they'll need to go together.


Sure, please go ahead.

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: locking changes in tty broke low latency feature

[Greg KH]

On Wed, Feb 19, 2014 at 09:55:21PM -0500, Peter Hurley wrote:
> On 02/19/2014 06:06 PM, Hal Murray wrote:
> >> Can you give me an idea of your device's average and minimum required
> >> latency (please be specific)?  Is your target arch x86 [so I can evaluate 
> >> the
> >> the impact of bus-locked instructions relative to your expected]?
> >
> > The code I'm familiar with is ntpd and gpsd.  They run on almost any 
> > hardware
> > or OS and talk to a wide collection of devices.
> >
> > There is no hard requirement for latency.  They just work better with lower
> > latency.  The lower the better.
> >
> > People gripe about the latency due to USB polling which is about a ms.
> 
> Have you tried 3.12+ without low_latency? I ripped out a lot of locks
> from 3.12+ so it's possible it already meets your requirements.

Once USB gets involved, I don't want to hear anyone start complaining
about "latency" issues.  Almost all USB->serial devices do not take
latency into account at all.  The ones that do are really expensive and
not showing up in GPS devices and other "normal" devices at all.

So go blame the device manufactures for this, they obviously don't care
about issues like that if they use USB bulk endpoints for their data.

And yes, there are rumors that new hardware in a few years will be able
to handle time differences with USB latencies and the like, but I'll
wait until I see that hardware ship before even start to worry about the
issues involved...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: android: binder: convert commented messages to pr_debug

[SeongJae Park]

On Thu, Feb 20, 2014 at 12:24 AM, Greg KH  wrote:
> On Wed, Feb 19, 2014 at 12:49:33PM +0900, SeongJae Park wrote:
>> 2 debugging messages were just commented out for normal case. Let them
>> be activated on debug mode without explicit code modification.
>
> Are you sure this doesn't just always send the messages to the debug log
> all the time now?  Again, I'd just leave it alone...

Yes, I sure it will not unless `DEBUG` defined. I tested it again.

Anyway, I know this patch makes just a little, trivial enhancement and
for somebody, it would not looks like enhancement at all. In these case,
I think maintainer's opinion must be respected.
Also, I agree the code as-is just works and not bad.

Thank you for reviewing and your opinion, Greg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/ttm: declare 'struct device' in ttm_page_alloc.h

[Alexandre Courbot]

Ping, David?

On Mon, Feb 10, 2014 at 9:37 PM, Thierry Reding
 wrote:
> On Sun, Feb 09, 2014 at 06:43:18PM +0900, Alexandre Courbot wrote:
>> Declare 'struct device' explicitly in ttm_page_alloc.h as this file
>> does not include any file declaring it. This removes the following
>> warning:
>>
>>   warning: 'struct device' declared inside parameter list
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>> This warning was visible when compiling Nouveau on -next today.
>>
>>  include/drm/ttm/ttm_page_alloc.h | 2 ++
>>  1 file changed, 2 insertions(+)
>
> I don't think I've seen this on x86, but I've certainly encountered the
> same warning when building nouveau on ARM, so:
>
> Reviewed-by: Thierry Reding 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/3] usb: chipidea: msm: Clean and fix glue layer driver

[Tim Bird]

Thanks very much.  I will try out the things you mention and let you
know if I make progress.
 -- Tim


On Wed, Feb 19, 2014 at 6:58 AM, Ivan T. Ivanov  wrote:
>
> Hi Tim,
>
> On Tue, 2014-02-18 at 22:21 -0800, Tim Bird wrote:
>> Ivan,
>>
>> I'm having tremendous problems getting this driver to initialize.  For
>> some reason, I can't get the driver to actually transition the
>> hardware into peripheral mode.  At first I was getting a lot of probe
>> deferrals, based on not finding the regulators early enough in the
>> boot, and I thought it was an issue with the gadget drivers loading
>> before the driver could complete its setup.  However, I switched
>> everything to loading via modules, and now have less probe deferrals,
>> but I still can't get the driver to activate.
>
> My understanding for gadget drivers is that you can have only one
> of them active in particular time. When compiled in kernel you can
> chose only one of them, also you can have only one module (function)
> loaded.
>
>
>>   I see zero interrupts.
>
> Right, I think that we will not see interrupts until we have
> SPMI drivers which could control PMIC chip, PMIC is responsible
> to do ID line detection and generate IRQ to APQ/MSM chip.
>
>> In particular the routine hw_device_state (which turns on interrupts
>> in the controller) is never called, because I can't get
>> msm_otg_start_peripheral to actually kick the hardware.
>>
>
> OTG state machine is not used at all. This phy-"otg" driver is
> working only in "peripheral" mode, because of missing PMIC
> communication.
>
> The only callback which you could see to be executed is
> struct usb_otg::set_peripheral(), when you load gadget driver.
>
>
> 
>
> (Would you mind sharing your config?).
>
> Sure. Attached.
>
>
>> I tried configuring the qcom,otg-control for user controlled mode
>> setting (via debugfs),
>
> Never testes this. It was there before.
>
>>
>> My kernel is based on an internal Sony 3.13-rc6 kernel with clock and
>> regulator patches applied, as well as your phy-msm-usb.c patches from
>> November and your chipidea patches from yesterday.
>
> You will need also 4th chipidea patch[1]. I have dropped it, because
> I will like to upstream PHY driver changes first. They are depended
> anyway.
>
> To reduce dependency to other drivers, I could recommend you to
> use Zero gadget driver. It should be enough to test USB stack,
> where APQ device will be peripheral and development workstation
> will be a host[2].
>
>
> # cat zero.sh
> #!/bin/sh
> cd /lib/modules/$(uname -r)/kernel/drivers/usb/gadget
> insmod ./libcomposite.ko
> insmod ./usb_f_ss_lb.ko
> insmod ./g_zero.ko
>
>
>> [   22.454287] [] (warn_slowpath_common+0x68/0x88) from
>> [] (warn_slowpath_fmt+0x30/0x40)
>> [   22.463060] [] (warn_slowpath_fmt+0x30/0x40) from
>> [] (msm_otg_probe+0x24/0x904 [phy_msm_usb])
>> [   22.472703] [] (msm_otg_probe+0x24/0x904 [phy_msm_usb])
>
> This is know non-fatal issue. I will try to see how to fix it.
>
>
> Regards,
> Ivan
>
> [1] usb: chipidea: msm: Use USB PHY API to control PHY state
> [2] http://www.linux-usb.org/usbtest/
>
>



-- 
 -- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the mfd-lj tree

[Stephen Rothwell]

Hi Lee,

On Mon, 17 Feb 2014 14:14:46 +1100 Stephen Rothwell  
wrote:
>
> On Fri, 14 Feb 2014 13:42:17 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the mfd-lj tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from drivers/mfd/max665x.c:19:0:
> > include/linux/mfd/max665x-private.h:31:1: error: expected ';', identifier 
> > or '(' before 'struct'
> >  struct max665x_dev {
> >  ^
> > 
> > Caused by commit e77bb5297293 ("mfd: max665x: Differentiate between
> > MAX665X devices").  Clearly never built by anyone :-(
> > 
> > I have used the mfd-lj tree from next-20140210 again for today (since the
> > other version had other problems).
> 
> Still seeing this error.

Still ...

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpUJ_I8Yzk1D.pgp
Description: PGP signature

Re: [RFC][PATCH 0/5] arch: atomic rework

[Paul E. McKenney]

On Wed, Feb 19, 2014 at 04:53:49PM -0800, Linus Torvalds wrote:
> On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel  wrote:
> > On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote:
> >>
> >> Can you point to it? Because I can find a draft standard, and it sure
> >> as hell does *not* contain any clarity of the model. It has a *lot* of
> >> verbiage, but it's pretty much impossible to actually understand, even
> >> for somebody who really understands memory ordering.
> >
> > http://www.cl.cam.ac.uk/~mjb220/n3132.pdf
> > This has an explanation of the model up front, and then the detailed
> > formulae in Section 6.  This is from 2010, and there might have been
> > smaller changes since then, but I'm not aware of any bigger ones.
> 
> Ahh, this is different from what others pointed at. Same people,
> similar name, but not the same paper.
> 
> I will read this version too, but from reading the other one and the
> standard in parallel and trying to make sense of it, it seems that I
> may have originally misunderstood part of the whole control dependency
> chain.
> 
> The fact that the left side of "? :", "&&" and "||" breaks data
> dependencies made me originally think that the standard tried very
> hard to break any control dependencies. Which I felt was insane, when
> then some of the examples literally were about the testing of the
> value of an atomic read. The data dependency matters quite a bit. The
> fact that the other "Mathematical" paper then very much talked about
> consume only in the sense of following a pointer made me think so even
> more.
> 
> But reading it some more, I now think that the whole "data dependency"
> logic (which is where the special left-hand side rule of the ternary
> and logical operators come in) are basically an exception to the rule
> that sequence points end up being also meaningful for ordering (ok, so
> C11 seems to have renamed "sequence points" to "sequenced before").
> 
> So while an expression like
> 
> atomic_read(p, consume) ? a : b;
> 
> doesn't have a data dependency from the atomic read that forces
> serialization, writing
> 
>if (atomic_read(p, consume))
>   a;
>else
>   b;
> 
> the standard *does* imply that the atomic read is "happens-before" wrt
> "a", and I'm hoping that there is no question that the control
> dependency still acts as an ordering point.

The control dependency should order subsequent stores, at least assuming
that "a" and "b" don't start off with identical stores that the compiler
could pull out of the "if" and merge.  The same might also be true for ?:
for all I know.  (But see below)

That said, in this case, you could substitute relaxed for consume and get
the same effect.  The return value from atomic_read() gets absorbed into
the "if" condition, so there is no dependency-ordered-before relationship,
so nothing for consume to do.

One caution...  The happens-before relationship requires you to trace a
full path between the two operations of interest.  This is illustrated
by the following example, with both x and y initially zero:

T1: atomic_store_explicit(, 1, memory_order_relaxed);
r1 = atomic_load_explicit(, memory_order_relaxed);

T2: atomic_store_explicit(, 1, memory_order_relaxed);
r2 = atomic_load_explicit(, memory_order_relaxed);

There is a happens-before relationship between T1's load and store,
and another happens-before relationship between T2's load and store,
but there is no happens-before relationship from T1 to T2, and none
in the other direction, either.  And you don't get to assume any
ordering based on reasoning about these two disjoint happens-before
relationships.

So it is quite possible for r1==1&==1 after both threads complete.

Which should be no surprise: This misordering can happen even on x86,
which would need a full smp_mb() to prevent it.

> THAT was one of my big confusions, the discussion about control
> dependencies and the fact that the logical ops broke the data
> dependency made me believe that the standard tried to actively avoid
> the whole issue with "control dependencies can break ordering
> dependencies on some CPU's due to branch prediction and memory
> re-ordering by the CPU".
> 
> But after all the reading, I'm starting to think that that was never
> actually the implication at all, and the "logical ops breaks the data
> dependency rule" is simply an exception to the sequence point rule.
> All other sequence points still do exist, and do imply an ordering
> that matters for "consume"
> 
> Am I now reading it right?

As long as there is an unbroken chain of -data- dependencies from the
consume to the later access in question, and as long as that chain
doesn't go through the excluded operations, yes.

> So the clarification is basically to the statement that the "if
> (consume(p)) a" version *would* have an ordering guarantee between the
> read of "p" and "a", but the "consume(p) ? a : b" would *not* have
> such an ordering guarantee. Yes?

Neither 

Re: [PATCH v5 3/5] ACPI / processor: Introduce map_gic_id() to get apic id from MADT or _MAT method

[Hanjun Guo]

Hi Sudeep,

Thanks for your comments, please refer to the replies below. :)

On 2014年02月19日 22:33, Sudeep Holla wrote:

Hi Hanjun,

On 18/02/14 16:23, Hanjun Guo wrote:

Get apic id from MADT or _MAT method is not implemented on arm/arm64,
and ACPI 5.0 introduces GIC Structure for it, so this patch introduces
map_gic_id() to get apic id followed the ACPI 5.0 spec.

Signed-off-by: Hanjun Guo 
---
  drivers/acpi/processor_core.c |   26 ++
  1 file changed, 26 insertions(+)

diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 4dcf776..d316d9b 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -71,6 +71,27 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
return 0;
  }
  
+static int map_gic_id(struct acpi_subtable_header *entry,

+   int device_declaration, u32 acpi_id, int *apic_id)
+{
+   struct acpi_madt_generic_interrupt *gic =
+   (struct acpi_madt_generic_interrupt *)entry;
+
+   if (!(gic->flags & ACPI_MADT_ENABLED))
+   return -ENODEV;
+
+   /* In the GIC interrupt model, logical processors are
+* required to have a Processor Device object in the DSDT,
+* so we should check device_declaration here
+*/
+   if (device_declaration && (gic->uid == acpi_id)) {
+   *apic_id = gic->gic_id;

I have mentioned this earlier, it's not clear yet to me how does this work ?
It needs more clarity in the form of comment here at-least as the ACPIv5.0 is
also not so clear or explicit on how to handle this.


Yes, I noticed your comments and had a reply for that, after a
long consideration for this, I would withdraw my previous comments
before, please refer to the comments below.



Here you are expecting gic->uid = acpi_id which is fine, while acpi_map_cpuid
matches apic_id with cpu_physical_id(which must be MPIDR in ARM{32,64}). The
latter imposes restriction that gic->gic_id has to be MPIDR. Does that mean we
are imposing restriction on GIC ID to be MPIDR ? If so please document it here
and please explain the reason behind that choice.


On x86 and IA64, APIC/SAPIC ID is the hardware id of the logical
processor, and UID is just a unique ID to identify the processor in DSDT, it
can be any value, and even can be strings defined in ASL if I remember
that correctly.

The processor driver also follows that guidance now, and GIC structure 
in MADT

actually represents a processor (GICC) in the system, so I would let
gic->gic_id as MPIDR(processor hardware ID) for now to avoid confusions
and keep consistency with current ACPI driver.

UID can be any value and it depends on implementation, so it can be MPIDR
also, it will not conflict with GIC ID and can works fine in acpi processor
driver now.



I would expect _UID to be MPIDR rather than GIC ID but you may have some reasons
for this choice.


I think they both can be MPIDR for now, is this ok to you?

we can update the code when the new ACPI spec is coming out if there
is a clear explanation for GIC ID and UID in GIC structures, does this make
sense to you?

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/17 v2] Input - arizona-haptics: Fix double lock of dapm_mutex

[Mark Brown]

On Tue, Feb 18, 2014 at 03:22:12PM +, Charles Keepax wrote:
> snd_soc_dapm_sync takes the dapm_mutex internally, but we currently take
> it externally as well. This patch fixes this.

Dimitry, are you OK with this being merged via ASoC?  The subsequent
improvements to the infrastructure and fix this more generally build on
top of this one so they'll need to go together.


signature.asc
Description: Digital signature

Re: [patch]blk-mq: remove obsolete comments

[Shaohua Li]

On Wed, Feb 19, 2014 at 09:28:05AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 19, 2014 at 08:22:22PM +0800, Shaohua Li wrote:
> > 
> > We now have blk_mq_stop/start_queues API, delete the obsolete comments.
> 
> We do have the API, but the big question is if we want to require every
> driver to manually call it each time we get a busy return here.

block layer can't know if driver is ready to handle request, so I'm afraid
driver should manually call it.

Thanks,
Shaohua
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[David Rientjes]

On Wed, 19 Feb 2014, Marcelo Tosatti wrote:

> We agree that, in the future, we'd like to provide the ability to
> dynamically allocate and free 1GB pages at runtime.
> 
> Extending the kernel command line interface is a first step.
> 
> Do you have a concrete objection to that first step ?
> 

Yes, my concrete objection is that the command line interface is 
unnecessary if you can dynamically allocate and free 1GB pages at runtime 
unless memory will be so fragmented that it cannot be done when userspace 
is brought up.  That is not your use case, thus this support is not 
needed.  I think Mel also brought up this point.

There's no "first step" about it, this is unnecessary for your use case if 
you can do it at runtime.  I'm not sure what's so surprising about this.

> > You can't specify an interleave behavior with Luiz's command line 
> > interface so now we'd have two different interfaces for allocating 
> > hugepage sizes depending on whether you're specifying a node or not.  
> > It's "hugepagesz=1G hugepages=16" vs "hugepage_node=1:16:1G" (and I'd have 
> > to look at previous messages in this thread to see if that means 16 1GB 
> > pages on node 1 or 1 1GB pages on node 16.)
> 
> What syntax do you prefer and why ?
> 

I'm not sure it's interesting to talk about since this patchset is 
unnecessary if you can do it at runtime, but since "hugepagesz=" and 
"hugepages=" have existed for many kernel releases, we must maintain 
backwards compatibility.  Thus, it seems, the easiest addition would have 
been "hugepagesnode=" which I've mentioned several times, there's no 
reason to implement yet another command line option purely as a shorthand 
which hugepage_node=1:2:1G is and in a very cryptic way.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH -tip 1/2] [BUGFIX]kprobes/x86: Fix page-fault handling logic

[Masami Hiramatsu]

Current kprobes in-kernel page fault handler doesn't
expect that its single-stepping can be interrupted by
an NMI handler which may cause a page fault(e.g. perf
with callback tracing).
In that case, the page-fault handled by kprobes and it
misunderstands the page-fault has been caused by the
single-stepping code and tries to recover IP address
to probed address.
But the truth is the page-fault has been caused by the
NMI handler, and do_page_fault failes to handle real
page fault because the IP address is modified and
causes Kernel BUGs like below.

 
 [ 2264.726905] BUG: unable to handle kernel NULL pointer
 dereference at 0020
[ 2264.727190] IP: [] copy_user_generic_string+0x0/0x40
[ 2264.727380] PGD cbcd067 PUD cbcc067 PMD 0
[ 2264.727529] Oops:  [#1] SMP
[ 2264.727683] Modules linked in: ipt_MASQUERADE bnep bluetooth 6lowpan_iphc 
iptable_nat nf_nat_ipv4 nf_nat aesni_intel aes_x86_64 ablk_helper cryptd lrw 
gf128mul glue_helper virtio_balloon snd_hda_intel snd_hda_codec snd_hwdep
[ 2264.728391] CPU: 1 PID: 25094 Comm: perf Not tainted 3.14.0-rc1.badprobe+ #24
[ 2264.728592] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 2264.728747] task: 88003db9c210 ti: 88000caac000 task.ti: 
88000caac000
[ 2264.728950] RIP: 0010:[]  [] 
copy_user_generic_string+0x0/0x40
[ 2264.729163] RSP: 0018:88003fd06bd0  EFLAGS: 00010246
[ 2264.729291] RAX:  RBX: 88003fd06bf8 RCX: 0002
[ 2264.729472] RDX:  RSI: 0020 RDI: 88003fd06bf8
[ 2264.729661] RBP: 88003fd06bd8 R08: 0030 R09: 
[ 2264.729789] R10: 001e R11: 0015 R12: 88000caadfd8
[ 2264.729789] R13: 88003d76bc00 R14: 88003db9c210 R15: 0020
[ 2264.729789] FS:  7f398bbcc780() GS:88003fd0() 
knlGS:
[ 2264.729789] CS:  0010 DS:  ES:  CR0: 80050033
[ 2264.729789] CR2: 0020 CR3: 204f2000 CR4: 07e0
[ 2264.729789] Stack:
[ 2264.729789]  813c5fd4 88003fd06c30 810183b0 
88003d76bc00
[ 2264.729789]  88003fd06ef8   
88003d76bc00
[ 2264.729789]  000c 00052ce0 88000956f800 
88000caadf58
[ 2264.729789] Call Trace:
[ 2264.729789]  
[ 2264.729789]  [] ? copy_from_user_nmi+0x64/0x70
[ 2264.729789]  [] perf_callchain_user+0xc0/0x220
[ 2264.729789]  [] perf_callchain+0x1c4/0x210
[ 2264.729789]  [] perf_prepare_sample+0x253/0x320
[ 2264.729789]  [] __perf_event_overflow+0xe7/0x230
[ 2264.729789]  [] ? x86_perf_event_set_period+0xe8/0x150
[ 2264.729789]  [] perf_event_overflow+0x14/0x20
[ 2264.729789]  [] intel_pmu_handle_irq+0x1cd/0x400
[ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
[ 2264.729789]  [] ? copy_user_generic_unrolled+0xc0/0xc0
[ 2264.729789]  [] perf_event_nmi_handler+0x2b/0x50
[ 2264.729789]  [] nmi_handle+0x88/0x180
[ 2264.729789]  [] ? copy_user_generic_unrolled+0xc0/0xc0
[ 2264.729789]  [] default_do_nmi+0x4a/0x140
[ 2264.729789]  [] do_nmi+0xa8/0xe0
[ 2264.729789]  [] end_repeat_nmi+0x1e/0x2e
[ 2264.729789]  [] ? copy_user_generic_unrolled+0xc0/0xc0
[ 2264.729789]  [] ? skip_prefixes+0x1c/0x40
[ 2264.729789]  [] ? bad_get_user+0x17/0x17
[ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
[ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
[ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
[ 2264.729789]  <>
[ 2264.729789]  <#DB>  [] ? 
copy_user_generic_unrolled+0xc0/0xc0
[ 2264.729789]  [] ? copy_user_generic_string+0x1/0x40
[ 2264.729789]  [] ? ftrace_cmp_recs+0x1/0x30
[ 2264.729789]  [] ? inat_get_opcode_attribute+0x5/0x20
[ 2264.729789]  [] ? inat_get_opcode_attribute+0x5/0x20
[ 2264.729789]  [] ? skip_prefixes+0x1c/0x40
[ 2264.729789]  [] resume_execution+0x37/0x1d0
[ 2264.729789]  [] kprobe_debug_handler+0x3f/0xe0
[ 2264.729789]  [] do_debug+0x7f/0x1d0
[ 2264.729789]  [] debug+0x3a/0x50
[ 2264.729789]  <>
[ 2264.729789]  [] ? seq_read+0x88/0x390
[ 2264.729789]  [] ? security_file_permission+0x84/0xa0
[ 2264.729789]  [] proc_reg_read+0x3d/0x80
[ 2264.729789]  [] vfs_read+0x9b/0x160
[ 2264.729789]  [] SyS_read+0x49/0xa0
[ 2264.729789]  [] system_call_fastpath+0x16/0x1b
[ 2264.729789] Code: c9 75 ee 21 d2 74 10 89 d1 8a 06 88 07 48 ff c6 48 ff c7 ff
 c9 75 f2 31 c0 0f 1f 00 c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00  1f 00
 83 fa 08 72 27 89 f9 83 e1 07 74 15 83 e9 08 f7 d9 29
[ 2264.729789] RIP  [] copy_user_generic_string+0x0/0x40
[ 2264.729789]  RSP 
[ 2264.729789] CR2: 0020
[ 2264.729789] ---[ end trace 533fc16b4cc45447 ]---
[ 2264.729789] Kernel panic - not syncing: Fatal exception in interrupt
[ 2264.729789] Kernel Offset: 0x0 from 0x8100 (relocation range: 0xf
fff8000-0x9fff)
 

To handle this correctly, I fixed the kprobes fault
handler to ensure the faulted ip address is its own
single-step buffer instead of checking current kprobe
state.


Signed-off-by: Masami 

[PATCH -tip 2/2] kprobes/x86: Allow to handle reentered kprobe on singlestepping

[Masami Hiramatsu]

Since the NMI handlers(e.g. perf) can interrupt in the
single stepping (or preparing the single stepping, do_debug
etc.), we should consider a kprobe is hit in the NMI
handler. Even in that case, the kprobe is allowed to be
reentered as same as the kprobes hit in kprobe handlers
(KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE).
The real issue will happen when a kprobe hit while another
reentered kprobe is processing (KPROBE_REENTER), because
we already consumed a saved-area for the previous kprobe.

Signed-off-by: Masami Hiramatsu 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
---
 arch/x86/kernel/kprobes/core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index b482e96..a9a42fa 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -531,10 +531,11 @@ reenter_kprobe(struct kprobe *p, struct pt_regs *regs, 
struct kprobe_ctlblk *kcb
switch (kcb->kprobe_status) {
case KPROBE_HIT_SSDONE:
case KPROBE_HIT_ACTIVE:
+   case KPROBE_HIT_SS:
kprobes_inc_nmissed_count(p);
setup_singlestep(p, regs, kcb, 1);
break;
-   case KPROBE_HIT_SS:
+   case KPROBE_REENTER:
/* A probe has been hit in the codepath leading up to, or just
 * after, single-stepping of a probed instruction. This entire
 * codepath should strictly reside in .kprobes.text section.


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

[PATCH -tip 0/2] kprobes/x86: Fix bugs for NMI handling

[Masami Hiramatsu]

The following series fixes bugs hidden in the ancient code.

The bugs suddenly appeared when I enabled over 6,000 kprobes
and ran perf-top with --call-graph. The bugs are hidden in
the old code and it have woken up by real stress testing.

Actually, current kprobes doesn't expect an NMI handler
hits in single-stepping state (including preparation and
do_debug() handling). Moreover, the NMI handler causing
a page fault by trying to access user pages, is out of
imagination! :) But perf does it.

Thus the previous code optimistically check the current
running kprobe state, and if it is in the singlestep state,
it changes the IP address to probed address and return,
because it expects the page fault happened on the single
stepped code.
However, in fact, the perf's NMI can interrupt the
do_debug or somewhere around that and it may cause a
page fault. In this case, putting the IP address to
probed address is simply wrong. It causes unexpected
kernel crash.
To handle this correctly, this patch fixes it to ensure
the page-fault address is actually same to the single-
stepping address, and only if so, set the IP address
to the probed address.

I also found another small mistake which gives up the
recovery from reentered kprobes in single-stepping state,
but it also assumes that there is no NMI handler interrupts
in that state. It should gives up only when the nested
reentering happens.

Thanks to Ingo and Frank for encouraging me to start
stress testing with massive multiple kprobes. :)

Thank you,

---

Masami Hiramatsu (2):
  [BUGFIX]kprobes/x86: Fix page-fault handling logic
  kprobes/x86: Allow to handle reentered kprobe on singlestepping


 arch/x86/kernel/kprobes/core.c |   16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

--
Signature

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

perf test failure on 3.14rc3

[Dave Jones]

 1: vmlinux symtab matches kallsyms: Ok
 2: detect open syscall event  : Ok
 3: detect open syscall event on all cpus  : Ok
 4: read samples using the mmap interface  : Ok
 5: parse events tests :  Warning: function 
__le16_to_cpup not defined
  Warning: function __le16_to_cpup not defined
  Warning: function __le16_to_cpup not defined
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: bad op token {
  Warning: function is_writable_pte not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: function scsi_trace_parse_cdb not defined
  Warning: unknown op '->'
  Warning: function jiffies_to_msecs not defined
  Warning: function jiffies_to_msecs not defined
  Warning: unknown op '{'
  Warning: unknown op '{'
 Ok
 6: x86 rdpmc test : Ok
 7: Validate PERF_RECORD_* events & perf_sample fields : Ok
 8: Test perf pmu format parsing   : Ok
 9: Test dso data interface: Ok
10: roundtrip evsel->name check: Ok
11: Check parsing of sched tracepoints fields  : Ok
12: Generate and check syscalls:sys_enter_open event fields: Ok
13: struct perf_event_attr setup   : Ok
14: Test matching and linking multiple hists   : Ok
15: Try 'use perf' in python, checking link problems   : FAILED!
16: Test breakpoint overflow signal handler: Ok
17: Test breakpoint overflow sampling  : Ok
18: Test number of exit event of a simple workload : Ok
19: Test software clock events have valid period values: Ok
20: Test converting perf time to TSC   : Ok
21: Test object code reading   : FAILED!
22: Test sample parsing: Ok
23: Test using a dummy software event to keep tracking : Ok
24: Test parsing with no sample_id_all bit set : Ok


I see '5' failing in similar ways in 3.13 too, so it's been broken
for a while.

Is 21 due to CONFIG_RANDOMIZE_BASE perhaps ?
Might that also explain why perf top isn't showing me kernel
function names any more ?

Dave

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

Re: [PATCH 2/2] ASoC: fsl: Make Freescale SAI/ESAI/SPDIF to be visible in Kconfig

[Nicolin Chen]

On Thu, Feb 20, 2014 at 11:44:32AM +0900, Mark Brown wrote:
> On Thu, Feb 20, 2014 at 02:06:20AM +, li.xi...@freescale.com wrote:
> 
> > I'm not very sure of this patch, maybe should we add one menu
> > in Kconfig for all visible CPU DAIs firstly like for code drivers?
> 
> Allowing them to be individually selected is definitely useful if people
> are trying to minimise their kernel size and/or build time.  However
> none of the other Freescale people have commented on this patch (which
> I'd have expected) so I was giving them time and IIRC it needs a rebase
> against current code.

Last month I was revising a new CODEC driver for ESAI and meanwhile abort
to plan to try simple card for this combination but being suspended due to
some tough internal issues. So I think it should be a good idea for us to
move towards simple card starting from this patch.

Surely, Acked.
Nicolin Chen


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

[PATCH] sched: reset se-depth when task switched to FAIR

[Michael wang]

Sasha reported:

[  522.645288] BUG: unable to handle kernel NULL pointer dereference at ...
[  522.646271] IP: [] check_preempt_wakeup+0x11f/0x210
...
[  522.650021] Call Trace:
[  522.650021]  
[  522.650021]  [] check_preempt_curr+0x3d/0xb0
[  522.650021]  [] ttwu_do_wakeup+0x18/0x130
...

which was caused by the se-depth changed during the time when task is not
FAIR, and we will use the wrong depth value after it switched back to FAIR.

This patch reset the depth at the time when task switched to FAIR, make sure
that we always have the correct value when task is FAIR.

CC: Ingo Molnar 
CC: Peter Zijlstra 
Reported-by: Sasha Levin 
Tested-by: Sasha Levin 
Signed-off-by: Michael Wang 
---
 kernel/sched/fair.c |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 235cfa7..280da89 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7317,7 +7317,15 @@ static void switched_from_fair(struct rq *rq, struct 
task_struct *p)
  */
 static void switched_to_fair(struct rq *rq, struct task_struct *p)
 {
-   if (!p->se.on_rq)
+   struct sched_entity *se = >se;
+#ifdef CONFIG_FAIR_GROUP_SCHED
+   /*
+* Since the real-depth could have been changed (only FAIR
+* class maintain depth value), reset depth properly.
+*/
+   se->depth = se->parent ? se->parent->depth + 1 : 0;
+#endif
+   if (!se->on_rq)
return;
 
/*
-- 
1.7.9.5

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

Linux module(s) related to user's permission

[Tom Cao]

Hi all,

Can everyone tell me about kernel module(s) that related to permission
or privilege of user (root, normal users) in Linux.
I want to research about permission module and do some modifications
to the kernel. In fact, I want to limit root's privilege on a specific
file or folder. So, can anybody tell me some documents, books or links
to find such information.
I am looking forward to hearing from you,

-- 
Best regards,
Tom
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: OMAP3+: DPLL: stop reparenting to same parent if already done

[Paul Walmsley]

On Wed, 5 Feb 2014, Nishanth Menon wrote:

> omap3_noncore_dpll_set_rate forces a reparent to the same clk_ref
> for every call that takes place. This is an can be done only if a change
> is detected.
> 
> Signed-off-by: Nishanth Menon 

Queued for v3.15 with Tero's ack unless the patch is updated to indicate 
that it's more than an optimization.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] et131x: fix allocation failures

[Zhao, Gang]

On Wed, 2014-02-19 at 19:43:15 +0800, One Thousand Gnomes wrote:
> On Wed, 19 Feb 2014 09:14:19 +0800
> "Zhao\, Gang"  wrote:
>
>> Alan, thanks for resending this patch. But it seems you overlooked
>> something we discussed earlier.
>> 
>> On Mon, 2014-02-17 at 22:13:08 +0800, Alan wrote:
>> > We should check the ring allocations don't fail.
>> > If we get a fail we need to clean up properly. The allocator assumes the
>> > deallocator will be used on failure, but it isn't. Make sure the
>> > right deallocator is always called and add a missing check against
>> > fbr allocation failure.
>> >
>> > [v2]: Correct check logic
>> >
>> > Signed-off-by: Alan Cox 
>> > ---
>> >  drivers/staging/et131x/et131x.c |9 +++--
>> >  1 file changed, 7 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/staging/et131x/et131x.c 
>> > b/drivers/staging/et131x/et131x.c
>> > index 6413500..cc600df 100644
>> > --- a/drivers/staging/et131x/et131x.c
>> > +++ b/drivers/staging/et131x/et131x.c
>> > @@ -2124,7 +2124,11 @@ static int et131x_rx_dma_memory_alloc(struct 
>> > et131x_adapter *adapter)
>> >  
>> >/* Alloc memory for the lookup table */
>> >rx_ring->fbr[0] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
>> > +  if (rx_ring->fbr[0] == NULL)
>> > +  return -ENOMEM;
>> >rx_ring->fbr[1] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
>> > +  if (rx_ring->fbr[1] == NULL)
>> > +  return -ENOMEM;
>> 
>> Shouldn't rx_ring->fbr[0] be freed when allocation of rx_ring->fbr[1]
>> fails ? Or we will leak memory here.
>
> No.. the tx_dma_memory_free and rx_dma_memory_free functions are
> designed to handle incomplete set up. They are now called on incomplete
> setup and will clean up all the resources.
>

Yes, you are right. By calling {tx, rx}_dma_memory_free the memory will
be freed.

But I think a comment is needed here, to make this more clear ? Without
proper comment the above code looks a little strange to let one think
it's right. :)


>> > @@ -3591,6 +3595,7 @@ static int et131x_adapter_memory_alloc(struct 
>> > et131x_adapter *adapter)
>> >if (status) {
>> >dev_err(>pdev->dev,
>> >  "et131x_tx_dma_memory_alloc FAILED\n");
>> > +  et131x_tx_dma_memory_free(adapter);
>> >return status;
>> >}
>> >/* Receive buffer memory allocation */
>> > @@ -3598,7 +3603,7 @@ static int et131x_adapter_memory_alloc(struct 
>> > et131x_adapter *adapter)
>> >if (status) {
>> >dev_err(>pdev->dev,
>> >  "et131x_rx_dma_memory_alloc FAILED\n");
>> > -  et131x_tx_dma_memory_free(adapter);
>> > +  et131x_adapter_memory_free(adapter);
>> >return status;
>> >}
>> >  
>
> Which is what these changes are about.
>
> Whoever wrote the allocator and cleanup methods arranged (except for the
> rx_ring->fbr cases) that the free method should be called on a failure.
> It looks as if somewhere along the line of the driver development whoever
> wrote the higher level bits didn't understand that.
>
> Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build failure after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

ERROR: "snd_pcm_hw_constraint_mask64" [sound/soc/codecs/snd-soc-adau1977.ko] 
undefined!

Caused by commit 603597c9375b ("ASoC: Add ADAU1977 CODEC driver").

I have used the sound-asoc tree from next-20140219 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp5fETrl2CAS.pgp
Description: PGP signature

linux-next: build warning after merge of the sound-asoc tree

[Stephen Rothwell]

Hi all,

After merging the sound-asoc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

sound/soc/codecs/cs42l51.c: In function 'cs42l51_probe':
sound/soc/codecs/cs42l51.c:490:26: warning: unused variable 'cs42l51' 
[-Wunused-variable]
  struct cs42l51_private *cs42l51 = snd_soc_codec_get_drvdata(codec);
  ^

Introduced by commit da0714897624 ("ASoC: cs42l51: Convert to direct
regmap API usage").

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpqucbV5O9t_.pgp
Description: PGP signature

Re: locking changes in tty broke low latency feature

[Peter Hurley]

On 02/19/2014 06:06 PM, Hal Murray wrote:

Can you give me an idea of your device's average and minimum required
latency (please be specific)?  Is your target arch x86 [so I can evaluate the
the impact of bus-locked instructions relative to your expected]?


The code I'm familiar with is ntpd and gpsd.  They run on almost any hardware
or OS and talk to a wide collection of devices.

There is no hard requirement for latency.  They just work better with lower
latency.  The lower the better.

People gripe about the latency due to USB polling which is about a ms.


Have you tried 3.12+ without low_latency? I ripped out a lot of locks
from 3.12+ so it's possible it already meets your requirements.


I can easily notice a few 10s of microseconds.  I probably wouldn't notice a
few microseconds, but there are people who would.  The latency isn't
critical, it's the jitter.  (ntpd has fudge factors to correct for a fixed
offset.)  Yes, down at the microsecond level luck-of-the-cache is important.


Hopefully you meant "milliseconds" here; single-digit microsecond latency on
any kind of stable duty cycle is linux-rt territory, and simply not a reasonable
goal for mainline.

The jitter is all scheduler and since the user-space app is sleeping waiting
for input, there's nothing the tty core can do about that. Removing one
mandatory scheduling wakeup _may_ help latency, but will probably not make
much difference regarding jitter.


Also, how painful would it be if unsupported termios changes were rejected
if the port was in low_latency mode and/or if low_latency setting was
disallowed because of termios state?


What does "unsupported termios changes" mean?


For example, once the port is in low_latency mode, setting L_ECHO (and its ilk)
would be rejected. And vice versa, if the L_ECHO is set in termios, low_latency
would be rejected.

So running a vt console is low_latency mode is not going to work.


ntpd has only a few places where it opens a serial port.  I'll collect a list
of the options that are used if that will help.  The common cases are either
raw binary, or lines of text.  It doesn't need any fancy editing.



It would be pointless to throttle low_latency, yes?


What does "throttle" mean?  If you mean what I call flow-control, then no,
it's not interesting.


Yes, whatever the driver currently considers flow-control. The core is
agnostic about the mechanism; throttling is the generic requirement.


There shouldn't be any problem with ntpd or gpsd grabbing all the data
promptly.


Ok.


What would be an acceptable outcome of being unable to accept input?
Corrupted overrun? Dropped i/o? Queued for later? Please explain with
comparison to the outcome of missed minimum latency.


Corruption would be evil.  Longer latency would be OK, especially if it
didn't happen often.  (ntpd has code to discard outliers.)  3% of the time
would probably not be a problem.  25% might cause problems.

We can allocate a bigger buffer if that helps.


No need, I already solved this step.


gpsd uses TIOCMIWAIT to get a wakeup from a PPS signal connected to a modem
control line.  That path might have the same problem and/or some ideas on how
to handle the data case.


What Alan said. low_latency has no impact on the handling of the PPS signal
through DCD.

Regards,
Peter Hurley

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

Re: [PATCH 3.13 00/40] 3.13.4-stable review

[Mark Brown]

On Wed, Feb 19, 2014 at 06:20:13PM -0700, Shuah Khan wrote:

> Right. I think this message should be a warning instead of an error.
> Error is too alarming, unless there is a good reason for it to be an
> error.

Patches welcome...


signature.asc
Description: Digital signature

Re: [PATCH Resend] regmap: fix _regmap_update_bits()

[Mark Brown]

On Thu, Feb 20, 2014 at 08:50:10AM +0800, Xiubo Li wrote:

> This resend version just rewrites the commit comment.

I've applied this but I updated the commit log further - part of the
reason this didn't get applied first time around was that it says it's a
fix but it's actually a coding style change.  The other part of the
reason was that at first glance I wasn't sure if it was actually an
improvement so wanted to think about it.


signature.asc
Description: Digital signature

Re: [PATCH 2/2] ASoC: fsl: Make Freescale SAI/ESAI/SPDIF to be visible in Kconfig

[Mark Brown]

On Thu, Feb 20, 2014 at 02:06:20AM +, li.xi...@freescale.com wrote:

> I'm not very sure of this patch, maybe should we add one menu
> in Kconfig for all visible CPU DAIs firstly like for code drivers?

Allowing them to be individually selected is definitely useful if people
are trying to minimise their kernel size and/or build time.  However
none of the other Freescale people have commented on this patch (which
I'd have expected) so I was giving them time and IIRC it needs a rebase
against current code.


signature.asc
Description: Digital signature

Re: [PATCH] sched: keep quiescent cpu out of idle balance loop

[Lei Wen]

On Wed, Feb 19, 2014 at 5:04 PM, Peter Zijlstra  wrote:
> On Wed, Feb 19, 2014 at 01:20:30PM +0800, Lei Wen wrote:
>> Since cpu which is put into quiescent mode, would remove itself
>> from kernel's sched_domain. So we could use search sched_domain
>> method to check whether this cpu don't want to be disturbed as
>> idle load balance would send IPI to it.
>>
>> Signed-off-by: Lei Wen 
>> ---
>>  kernel/sched/fair.c | 14 +++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 235cfa7..14230ae 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -6783,6 +6783,8 @@ out_unlock:
>>   * - When one of the busy CPUs notice that there may be an idle rebalancing
>>   *   needed, they will kick the idle load balancer, which then does idle
>>   *   load balancing for all the idle CPUs.
>> + * - exclude those cpus not inside current call_cpu's sched_domain, so that
>> + *   those isolated cpu could be kept in their quisecnt mode.
>>   */
>>  static struct {
>>   cpumask_var_t idle_cpus_mask;
>> @@ -6792,10 +6794,16 @@ static struct {
>>
>>  static inline int find_new_ilb(void)
>>  {
>> - int ilb = cpumask_first(nohz.idle_cpus_mask);
>> + int ilb;
>> + int cpu = smp_processor_id();
>> + struct sched_domain *tmp;
>>
>> - if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> - return ilb;
>> + for_each_domain(cpu, tmp) {
>> + ilb = cpumask_first_and(nohz.idle_cpus_mask,
>> + sched_domain_span(tmp));
>> + if (ilb < nr_cpu_ids && idle_cpu(ilb))
>> + return ilb;
>> + }
>
> The ILB code is bad; but you just made it horrible. Don't add pointless
> for_each_domain() iterations.
>
> I'm thinking something like:
>
>   ilb = cpumask_first_and(nohz.idle_cpus_mask, this_rq()->rd.span);
>
> Should work just fine, no?

Yes, it has the same result as my previous patch did.

>
> Better still would be to maybe not participate in the ILB in the first
> place and leave this selection loop alone.

Not quitely get your point here...
Do you mean that you want idle cpu selection be put in earlier place
than current find_new_ilb is?

Thanks,
Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How could we get rid of saved_max_pfn for calgary iommu?

[Vivek Goyal]

On Wed, Feb 19, 2014 at 05:04:22PM -0700, Jon Mason wrote:
> On Tue, Feb 18, 2014 at 11:18 PM, WANG Chao  wrote:
> > Hi, All
> >
> > arch/x86/kernel/pci-calgary.c is the only user of saved_max_pfn today:
> >
> > int __init detect_calgary(void)
> > {
> > [..]
> > specified_table_size = determine_tce_table_size((is_kdump_kernel() ?
> > saved_max_pfn : max_pfn) * 
> > PAGE_SIZE);
> > [..]
> > }
> 
> IIUC, the purpose of this code is to reuse the TCE table from the
> previous kernel.  Thus, it needs to be of the same size as the
> pre-kdump kernel.  It is using the max_pfn to determine the TCE table
> size in the non-kdump case.  If there is another way to determine the
> size it used before, then I am fine making the change to use that way.

How about passing old tce table size on command line to second kernel.
Given the fact that it is specific to calgary only, we can it very
specific. Say calgary_iommu_old_tce_table_sz=.

But we will then need to know the size of TCE table in first kernel. Is
this information exported to user space somewhere?

Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [cgroup] BUG: unable to handle kernel NULL pointer dereference at 0000001c

[Li Zefan]

On 2014/2/19 20:25, Fengguang Wu wrote:
> Greetings,
> 
> I got the below dmesg and the first bad commit is
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-next
> 
> commit ace2bee8135a3dc725958b8d08c55ee9df813d39
> Author: Tejun Heo 
> AuthorDate: Tue Feb 11 11:52:47 2014 -0500
> Commit: Tejun Heo 
> CommitDate: Tue Feb 11 11:52:47 2014 -0500
> 
> cgroup: introduce cgroup_tree_mutex
> 
> Signed-off-by: Tejun Heo 
> Acked-by: Li Zefan 
> 

Thanks for the report. It was introduced by

e61734c55c24cdf11b07e52a74aec4dc4a7f4bd0 cgroup: remove cgroup->name

And It has been fixed by

cc045e3952175e84c38dad22dea14465b9fc8fb5 cgroup: deal with dummp_top in 
cgroup_name() and cgroup_path()

The fix has been in for-next fox about a week, so I'm curious why
you still hit this bug.

> [   97.464167] BUG: unable to handle kernel NULL pointer dereference at 
> 001c
> [   97.464897] IP: [<8130f33d>] kernfs_path_locked+0x7d/0xc0
> [   97.465519] *pde = 
> [   97.465960] Oops:  [#1] SMP
> [   97.466936] CPU: 0 PID: 24 Comm: kworker/0:1 Tainted: G S  W
> 3.14.0-rc2-01592-g97162c1 #6
> [   97.467818] Workqueue: events_freezable_power_ disk_events_workfn
> [   97.468342] task: 801c7560 ti: 801d6000 task.ti: 801d6000
> [   97.468836] EIP: 0060:[<8130f33d>] EFLAGS: 0046 CPU: 0
> [   97.469291] EIP is at kernfs_path_locked+0x7d/0xc0
> [   97.469636] EAX:  EBX:  ECX: 801d7c34 EDX: 801d7bb4
> [   97.470024] ESI: 0046 EDI: 801d7c33 EBP: 801d7b68 ESP: 801d7b58
> [   97.470505]  DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
> [   97.470929] CR0: 8005003b CR2: 001c CR3: 03b92000 CR4: 00300690
> [   97.471550] DR0:  DR1:  DR2:  DR3: 
> [   97.472155] DR6:  DR7: 
> [   97.472397] Stack:
> [   97.472397]  801d7bb4  0046 801d7bb4 801d7b80 8130fe59 
> 0080 929c0ce0
> [   97.472397]  929ae498 0018 801d7c40 8199b88a 0002 0001 
>  8199b650
> [   97.472397]  929ae498  0001 801c7560 929ae5e4 929b46f8 
> 929c0ca0 819978d0
> [   97.472397] Call Trace:
> [   97.472397]  [<8130fe59>] kernfs_path+0x49/0x80
> [   97.472397]  [<8199b88a>] cfq_find_alloc_queue+0x3fa/0x620
> [   97.472397]  [<8199b650>] ? cfq_find_alloc_queue+0x1c0/0x620
> [   97.472397]  [<819978d0>] ? cfq_put_request+0x220/0x220
> [   97.472397]  [<8199bca5>] ? cfq_set_request+0x85/0x740
> [   97.472397]  [<8111e5ce>] ? do_raw_spin_lock+0xe/0x2e0
> [   97.472397]  [<8199bb35>] cfq_get_queue+0x85/0x170
> [   97.472397]  [<8199bff7>] cfq_set_request+0x3d7/0x740
> 

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

Re: [PATCH 4/4] hugetlb: add hugepages_node= command-line option

[Marcelo Tosatti]

On Tue, Feb 18, 2014 at 02:16:42PM -0800, David Rientjes wrote:
> On Tue, 18 Feb 2014, Marcelo Tosatti wrote:
> 
> > > Lacking from your entire patchset is a specific example of what you want 
> > > to do.  So I think we're all guessing what exactly your usecase is and we 
> > > aren't getting any help.  Are you really suggesting that a customer wants 
> > > to allocate 4 1GB hugepages on node 0, 12 2MB hugepages on node 0, 6 1GB 
> > > hugepages on node 1, 24 2MB hugepages on node 1, 2 1GB hugepages on node 
> > > 2, 100 2MB hugepages on node 3, etc?  Please.
> > 
> > Customer has 32GB machine. He wants 8 1GB pages for his performance
> > critical application on node0 (KVM guest), and other guests and
> > pagecache etc. using the remaining 26GB of memory.
> > 
> 
> Wow, is that it?  (This still doesn't present a clear picture since we 
> don't know how much memory is on node 0, though.)
>
> So Luiz's example of setting up different size hugepages on three 
> different nodes requiring nine kernel command line parameters doesn't even 
> have a legitimate usecase today.
> 
> Back to the original comment on this patchset, forgetting all this 
> parameter parsing stuff, if you had the ability to free 1GB pages at 
> runtime then your problem is already solved, correct?  If that 32GB 
> machine has two nodes, then doing "hugepagesz=1G hugepages=16" will boot 
> just fine and then an init script frees the 8 1GB pages on node1.
> 
> It gets trickier if there are four nodes and each node is 8GB.  Then you'd 
> be ooming the machine if you did "hugepagesz=1G hugepages=32".  You could 
> actually do "hugepagesz=1G hugepages=29" and free the hugepages on 
> everything except for node 0, but I feel like movablecore= would be a 
> better option.
> 
> So why not just work on making 1GB pages dynamically allocatable and 
> freeable at runtime?  It feels like it would be a much more heavily used 
> feature than a special command line parameter for a single customer.

David,

We agree that, in the future, we'd like to provide the ability to
dynamically allocate and free 1GB pages at runtime.

Extending the kernel command line interface is a first step.

Do you have a concrete objection to that first step ?

> > > If that's actually the usecase then I'll renew my objection to the 
> > > entire patchset and say you want to add the ability to dynamically 
> > > allocate 1GB pages and free them at runtime early in initscripts.  If 
> > > something is going to be added to init code in the kernel then it 
> > > better be trivial since all this can be duplicated in userspace if you 
> > > really want to be fussy about it.
> > 
> > Not sure what is the point here. The command line interface addition
> > being proposed is simple, is it not?
> > 
> 
> You can't specify an interleave behavior with Luiz's command line 
> interface so now we'd have two different interfaces for allocating 
> hugepage sizes depending on whether you're specifying a node or not.  
> It's "hugepagesz=1G hugepages=16" vs "hugepage_node=1:16:1G" (and I'd have 
> to look at previous messages in this thread to see if that means 16 1GB 
> pages on node 1 or 1 1GB pages on node 16.)

What syntax do you prefer and why ?

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

Re: sched: fair: NULL ptr deref in check_preempt_wakeup

[Michael wang]

On 02/20/2014 02:10 AM, Sasha Levin wrote:
> On 02/17/2014 09:26 PM, Michael wang wrote:
>> On 02/17/2014 05:20 PM, Peter Zijlstra wrote:
>> [snip]
 >>  static void switched_to_fair(struct rq *rq, struct task_struct *p)
 >>  {
 >>-if (!p->se.on_rq)
 >>+struct sched_entity *se = >se;
 >>+#ifdef CONFIG_FAIR_GROUP_SCHED
 >>+se->depth = se->parent ? se->parent->depth + 1 : 0;
 >>+#endif
 >>+if (!se->on_rq)
 >>  return;
 >>
 >>  /*
>>> >
>>> >Yes indeed. My first idea yesterday was to put it in set_task_rq()
>>> to be
>>> >absolutely sure we catch all; but if this is sufficient its better.
>> Agree, let's wait for Sasha's testing result then:)
> 
> I took my time with testing it seems I'm hitting new issues with both
> sched and mm, and I've wanted to confirm I don't see this one any more.
> 
> It does seem like this patch fixes the problem for me, so:
> 
> Tested-by: Sasha Levin 

Thanks for the testing :) will post the patch later.

Regards,
Michael Wang

> 
> 
> Thanks,
> Sasha
> 

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

3.13 i915 brightness settings broken when going from docked -> undocked

[Josh Boyer]

Hi All,

We've had a rather weird report[1] of the brightness adjustments being
broken in a specific case with Thinkpad x220 hardware (SandyBridge
based).  If you boot the machine with it in a dock and then undock,
the brightness adjustments do not work.  That is with either the FN
keys or the GNOME brightness slider.

I can see that the value of
/sys/class/backlight/acpi_video0/brightness increases/decreases but
/sys/class/backlight/intel_backlight/brightness doesn't reflect any
changes.  With 3.12 this works, and oddly with 3.14-rc1 it works
(specifically, it starts working around v3.13-10231-g53d8ab2 which is
right after the first DRM merge for 3.14).  With 3.13, if I undock and
echo a higher value in the intel_backlight_brightness sysfs entry, the
brightness will actually increase so it can be done manually, but it
does not work as you'd expect.

I'm in the middle of trying to do a reverse bisect for which patch
fixes it in the 3.14-rcX series, but that's taking a while.  I thought
I'd email and see if anyone already knows about this situation, what
patch in 3.13 broke this, and which one then fixed it again.  Thus far
all I've gathered is that backlight handling is confusing.

josh

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: locking changes in tty broke low latency feature

[Peter Hurley]

On 02/19/2014 04:42 PM, One Thousand Gnomes wrote:

It only has to happen *once*, not every time to screw stuff up.


If the reader isn't pulling _all_ the data out the instant it's woken,
trying to trim off one worker wakeup (by processing input at interrupt time)
is pointless.


No - because of the statistical corner cases. The standard Linux is not
remotely hard real time, and even if it were most of the tools involved
are not.


Ok, so this is still only about "best effort", and really bad
worst case behavior (that the tty core has no control over) is ok.

Going to great lengths to trim one wakeup when nouveau disables interrupts
for 2ms seemed like a waste of time.


Low latency goes back to the days of flip buffers, bottom halves an a
100Hz clock. There are certainly better ways to do it now if its needed.


Still, as you've pointed out a couple of times, maybe there's a limited
fastpath that's easy and simple. That's why I was asking about throttling
because it's evaluated even for raw mode.


Even if there isn't the goal of low latency was always 'get stuff to
happen soon' not 'get stuff to happen in the IRQ handler' If you have the
tty processing happening immediately after the IRQ returns when
low_latency is set I'm sure the numbers will be just fine and as good as
historically.

Whether you can always do that I guess depends what happens on really
slow boxes if you don't do any deferral - eg on Geert's Amiga.


Sure.

I think _some_ effort will yield positive results. For example,
in flush_to_ldisc():

if (disc == NULL)
return;

-   mutex_lock(>lock);
+   if (!mutex_trylock(>lock))
+   goto deref;

while (1) {
struct tty_buffer *head = buf->head;

.

mutex_unlock(>lock);
-
+ deref:
tty_ldisc_deref(disc);
 }

This change makes flush_to_ldisc() itself safely callable from
interrupt context, and:
1. doesn't lose data (ie., buffers if the ldisc is filling up)
2. automatically picks the optimum handling whether the input worker
   is running or not
3. doesn't require more locks to exclude flushing or the input worker

This still leaves fixing termios lock, properly handling throttling
and the exclusion logic for incompatible termios options and low_latency.

[For this change to work properly, I still need to solve a race where
the driver has just updated the commit marker but can't grab the buf
lock because tty_buffer_flush() still has the lock but has already
performed the flush -- in this case, the work needs to be restarted
or something because there's still data in the buffer that needs
processing. There's plenty of possible solutions to this; I'm thinking on
which is the right one].


Flow control even in raw mode is expected Unix behaviour. However do we
ever need to evaluate it if the tty termios has IXON and CRTSCTS clear ?


It doesn't right now because the assumption is that drivers can
have a whole host of reasons why they want to throttle (the pty driver
leaves it on permanently; the vt driver needs unthrottle to support
paste that no one uses even though I fixed it).

Putting aside for a moment the issue of termios safety inside
the throttle and unthrottle driver methods, the exclusion locks here could
be spinlocks if the drivers can be audited/fixed to not sleep here.

Then that just leaves the termios lock, which is a non-trivial problem, and
I'm not convinced RCU will magically fix it.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: sched: fair: NULL ptr deref in check_preempt_wakeup

[Michael wang]

On 02/20/2014 12:16 AM, Peter Zijlstra wrote:
[snip]
>>
>>
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 235cfa7..4445e56 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -7317,7 +7317,11 @@ static void switched_from_fair(struct rq *rq, struct 
>> task_struct *p)
>>   */
>>  static void switched_to_fair(struct rq *rq, struct task_struct *p)
>>  {
>> -if (!p->se.on_rq)
>> +struct sched_entity *se = >se;
>> +#ifdef CONFIG_FAIR_GROUP_SCHED
>> +se->depth = se->parent ? se->parent->depth + 1 : 0;
>> +#endif
>> +if (!se->on_rq)
>>  return;
>>  
>>  /*
> 
> 
> Michael, do you think you can send a proper patch for this?

My pleasure :) will post it later.

Regards,
Michael Wang

> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

Re: [PATCH] Add eMMC 5.0 support

[Jaehoon Chung]

Hi,

You can refer to this.

http://comments.gmane.org/gmane.linux.kernel.mmc/23838

Best Regards,
Jaehoon Chung

On 02/19/2014 10:47 PM, Zhang Yi wrote:
> Current code will exist when read eMMC 5.0, add support for it
> 
> Signed-off-by: Zhang Yi 
> ---
>  mmc_cmds.c |3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mmc_cmds.c b/mmc_cmds.c
> index b8afa74..5edf42b 100644
> --- a/mmc_cmds.c
> +++ b/mmc_cmds.c
> @@ -722,6 +722,9 @@ int do_read_extcsd(int nargs, char **argv)
>   ext_csd_rev = ext_csd[192];
>  
>   switch (ext_csd_rev) {
> + case 7:
> + str = "5.0";
> + break;
>   case 6:
>   str = "4.5";
>   break;
> 

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

Re: [Linaro-acpi] [PATCH v4 5/5] ACPI: Replace printk with pr_* in tables.c

[Hanjun Guo]

On 2014年02月20日 08:37, Rafael J. Wysocki wrote:

On Wednesday, February 19, 2014 04:46:19 PM Sudeep Holla wrote:

On 19/02/14 16:49, Rafael J. Wysocki wrote:

On Wednesday, February 19, 2014 04:32:34 PM Sudeep Holla wrote:

On 18/02/14 13:55, Hanjun Guo wrote:

This patch just do some clean up to replace printk with pr_*,
no functional change.


Any particular reason for choosing just this file in this series ?


Yes, the reason is that I will update this file in my next patch set 
(ARM64 ACPI core) with

pr_*, in order to keep  consistency, I updated them all in this file first.


It seems but off-topic in this series. The printk format is same in almost all
other acpi files and it's better to change all or none for consistency.

Well, it's fine, I can put it into a different branch in any case. :-)


Signed-off-by: Hanjun Guo 
---
  drivers/acpi/tables.c |   51 +++--
  1 file changed, 20 insertions(+), 31 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 5837f85..97bc6df 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -55,8 +55,7 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header 
*header)
{
struct acpi_madt_local_apic *p =
(struct acpi_madt_local_apic *)header;
-   printk(KERN_INFO PREFIX
-  "LAPIC (acpi_id[0x%02x] lapic_id[0x%02x] %s)\n",
+   pr_info(PREFIX "LAPIC (acpi_id[0x%02x] lapic_id[0x%02x] 
%s)\n",

You can even get rid of PREFIX by defining pr_fmt instead.

But this is a good point.


If the intention is to move to pr_* format it's better to have this as separate
patch and convert all of them.

Well, not really.  One file at a time is OK too.


No what I meant was to convert all for consistency, not in a single patch.
As I was playing with regex for few minutes, with few patterns was able to fix
most(not all) of them. It even compiles :) for x86. But turns out to be a big
churn :( [43 files changed, 253 insertions(+), 329 deletions(-)]

Well, precisely.  That's why I'd prefer doing that gradually.

That said I'll just drop the patch for now due to the PREFIX thing.


I will update this patch accordingly and send it out soon.

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 2/2] ASoC: fsl: Make Freescale SAI/ESAI/SPDIF to be visible in Kconfig

[li.xi...@freescale.com]

Hi Mark,

I'm not very sure of this patch, maybe should we add one menu
in Kconfig for all visible CPU DAIs firstly like for code drivers?

Thanks,

--
Best Regards,
Xiubo


> Subject: [PATCH 2/2] ASoC: fsl: Make Freescale SAI/ESAI/SPDIF to be visible in
> Kconfig
> 
> For simple card since the whole idea is to support any CODEC and
> any CPU DAI with the same driver, we should probably just make sure
> that all the individual CODEC and CPU DAI drivers can be enabled in
> Kconfig. That way we don't have to have specific Kconfig entries for
> boards and loose some of the benefit of the generic card.
> 
> This will make the Freescale SAI/ESAI/SPDIF device be visible in
> Kconfig.
> 
> Signed-off-by: Xiubo Li 
> Cc: Nicolin Chen 
> Cc: Mark Brown 
> ---
>  sound/soc/fsl/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig
> index d0914c0..f397144 100644
> --- a/sound/soc/fsl/Kconfig
> +++ b/sound/soc/fsl/Kconfig
> @@ -1,5 +1,5 @@
>  config SND_SOC_FSL_SAI
> - tristate
> + tristate "ALSA SoC support for the Freescale SAI device"
>   select REGMAP_MMIO
>   select SND_SOC_GENERIC_DMAENGINE_PCM
> 
> @@ -7,11 +7,11 @@ config SND_SOC_FSL_SSI
>   tristate
> 
>  config SND_SOC_FSL_SPDIF
> - tristate
> + tristate "ALSA SoC support for the Freescale SPDIF device"
>   select REGMAP_MMIO
> 
>  config SND_SOC_FSL_ESAI
> - tristate
> + tristate "ALSA SoC support for the Freescale ESAI device"
>   select REGMAP_MMIO
> 
>  config SND_SOC_FSL_UTILS
> --
> 1.8.4
> 

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

linux-next: manual merge of the hid tree with Linus' tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the hid tree got a conflict in
drivers/hid/hid-core.c between commit 117309c51dca ("HID: microsoft: Add
ID's for Surface Type/Touch Cover 2") from Linus' tree and commit
3faed1aff786 ("HID: hid-microsoft: Add support for scrollwheel and
special keypad keys") from the hid tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/hid/hid-core.c
index cc32a6f96c64,6f579dfba6ee..
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@@ -1780,8 -1823,7 +1824,9 @@@ static const struct hid_device_id hid_h
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_PRESENTER_8K_USB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_WIRELESS_OPTICAL_DESKTOP_3_0) },
 +  { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_2) },
 +  { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TOUCH_COVER_2) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_OFFICE_KB) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MONTEREY, USB_DEVICE_ID_GENIUS_KB29E) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, USB_DEVICE_ID_NTRIG_TOUCH_SCREEN) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NTRIG, 
USB_DEVICE_ID_NTRIG_TOUCH_SCREEN_1) },


pgpKNkoAO4wLf.pgp
Description: PGP signature

linux-next: manual merge of the hid tree with Linus' tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the hid tree got a conflict in
drivers/hid/hid-ids.h between commits adc232592337 ("[media] si4713: HID
blacklist Si4713 USB development board") and 3db187e7bf76 ("HID:
multitouch: add FocalTech FT support") from Linus' tree and commit
e932d8178667 ("HID: add hid-cp2112 driver") from the hid tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/hid/hid-ids.h
index 22f28d6b33a8,00be0d0f0dde..
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@@ -241,9 -240,7 +241,10 @@@
  
  #define USB_VENDOR_ID_CYGNAL  0x10c4
  #define USB_DEVICE_ID_CYGNAL_RADIO_SI470X 0x818a
 +#define USB_DEVICE_ID_FOCALTECH_FT_MULTITOUCH 0x81b9
 +
 +#define USB_DEVICE_ID_CYGNAL_RADIO_SI4713   0x8244
+ #define USB_DEVICE_ID_CYGNAL_CP2112   0xea90
  
  #define USB_VENDOR_ID_CYPRESS 0x04b4
  #define USB_DEVICE_ID_CYPRESS_MOUSE   0x0001


pgp6fcRDEz_x5.pgp
Description: PGP signature

Re: [PATCH v2] rcu: ensure kernel/rcu/rcu.h can be sourced/used stand-alone

[Paul Gortmaker]

[Re: [PATCH v2] rcu: ensure kernel/rcu/rcu.h can be sourced/used stand-alone] 
On 19/02/2014 (Wed 17:53) Paul E. McKenney wrote:

> On Wed, Feb 19, 2014 at 02:33:27PM -0500, Paul Gortmaker wrote:
> > The kbuild test bot uncovered an implicit dependence on the
> > trace header being present before rcu.h in ia64 allmodconfig
> > that looks like this:
> > 
> > In file included from kernel/ksysfs.c:22:0:
> > kernel/rcu/rcu.h: In function '__rcu_reclaim':
> > kernel/rcu/rcu.h:107:3: error: implicit declaration of function 
> > 'trace_rcu_invoke_kfree_callback' [-Werror=implicit-function-declaration]
> > kernel/rcu/rcu.h:112:3: error: implicit declaration of function 
> > 'trace_rcu_invoke_callback' [-Werror=implicit-function-declaration]
> > cc1: some warnings being treated as errors
> > 
> > Looking at other rcu.h users, we can find that they all
> > were sourcing the trace header in advance of rcu.h itself,
> > as seen in the context of this diff.  There were also some
> > inconsistencies as to whether it was or wasn't sourced based
> > on the parent tracing Kconfig.
> > 
> > Rather than "fix" it at each use site, and have inconsistent
> > use based on whether "#ifdef CONFIG_RCU_TRACE" was used or not,
> > lets just source the trace header just once, in the actual consumer
> > of it, which is rcu.h itself.  We include it unconditionally, as
> > build testing shows us that is a hard requirement for some files.
> > 
> > Reported-by: kbuild test robot 
> > Signed-off-by: Paul Gortmaker 
> 
> Queued for 3.16, thank you, Paul!

Thanks!

I'm assuming you meant 3.15 -- unless of course you are allowing
for an insurance policy for me possibly breaking the build.  ;)

P.
--

> 
>   Thanx, Paul
> 
> > ---
> > 
> > [v2: move the #include  outside of the scope
> >  of #ifdef CONFIG_RCU_TRACE so it is unconditionally included.]
> > 
> >  kernel/rcu/rcu.h| 1 +
> >  kernel/rcu/srcu.c   | 2 --
> >  kernel/rcu/tiny.c   | 4 
> >  kernel/rcu/tree.c   | 2 --
> >  kernel/rcu/update.c | 1 -
> >  5 files changed, 1 insertion(+), 9 deletions(-)
> > 
> > diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> > index 1bd787fddcb2..3d2a037332b2 100644
> > --- a/kernel/rcu/rcu.h
> > +++ b/kernel/rcu/rcu.h
> > @@ -23,6 +23,7 @@
> >  #ifndef __LINUX_RCU_H
> >  #define __LINUX_RCU_H
> > 
> > +#include 
> >  #ifdef CONFIG_RCU_TRACE
> >  #define RCU_TRACE(stmt) stmt
> >  #else /* #ifdef CONFIG_RCU_TRACE */
> > diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
> > index 5db7e9272d37..8e66b05bfd82 100644
> > --- a/kernel/rcu/srcu.c
> > +++ b/kernel/rcu/srcu.c
> > @@ -36,8 +36,6 @@
> >  #include 
> >  #include 
> > 
> > -#include 
> > -
> >  #include "rcu.h"
> > 
> >  /*
> > diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
> > index 53b95bbf4abb..d9efcc13008c 100644
> > --- a/kernel/rcu/tiny.c
> > +++ b/kernel/rcu/tiny.c
> > @@ -37,10 +37,6 @@
> >  #include 
> >  #include 
> > 
> > -#ifdef CONFIG_RCU_TRACE
> > -#include 
> > -#endif /* #else #ifdef CONFIG_RCU_TRACE */
> > -
> >  #include "rcu.h"
> > 
> >  /* Forward declarations for tiny_plugin.h. */
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index c7a00dbe768b..351faba48b91 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -58,8 +58,6 @@
> >  #include 
> > 
> >  #include "tree.h"
> > -#include 
> > -
> >  #include "rcu.h"
> > 
> >  MODULE_ALIAS("rcutree");
> > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> > index fd0d5b5b8e7c..4c0a9b0af469 100644
> > --- a/kernel/rcu/update.c
> > +++ b/kernel/rcu/update.c
> > @@ -49,7 +49,6 @@
> >  #include 
> > 
> >  #define CREATE_TRACE_POINTS
> > -#include 
> > 
> >  #include "rcu.h"
> > 
> > -- 
> > 1.8.5.2
> > 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] workqueue: Fix possible unexpectedly worker wakeup before started

[Lai Jiangshan]

On 02/20/2014 09:50 AM, Lai Jiangshan wrote:
> On 02/20/2014 08:11 AM, Tejun Heo wrote:
>> Hello, Lai.
>>
>> On Wed, Feb 19, 2014 at 11:47:58AM +0800, Lai Jiangshan wrote:
>>> If a worker is wokenup unexpectedly, it will start to work incorretly.
>>> Although it hardly happen, we should catch it and wait for being started
>>> if it does happen.
>>
>> Can this actually happen?  If so, how?
> 
> I don't think it can happen.
> It depends on the system outside of workqueue.
> 
> I'm afraid someone see the task and wake up it.
> workqueue protect itself.

I was extremely nervously, please drop the patch.
I also don't like too much protective code in workqueue.

> 
>>
>>> Signed-off-by: Lai Jiangshan 
>>> ---
>>>  kernel/workqueue.c |6 ++
>>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>>> index 82ef9f3..bee5fe1 100644
>>> --- a/kernel/workqueue.c
>>> +++ b/kernel/workqueue.c
>>> @@ -2284,6 +2284,12 @@ static int worker_thread(void *__worker)
>>> struct worker *worker = __worker;
>>> struct worker_pool *pool = worker->pool;
>>>  
>>> +   if (WARN_ON_ONCE(!(worker->flags & WORKER_STARTED))) {
>>
>> And if this is something which can legitimately happen, why are we
>> triggering WARN on it?
> 
> If it happens, it means there is something wrong in the system.
> 
>>
>>> +   /* The worker is wokenup unexpectedly before started */
>>> +   mutex_lock(>manager_mutex);
>>> +   mutex_unlock(>manager_mutex);
>>
>> And what does these mutex cycling achieve (they need comment)?
> 
> Synchronize the manager to finish.
> 
>>
>> Thanks.
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

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

[PATCH Resend] regmap: fix _regmap_update_bits()

[Xiubo Li]

Since sometimes the 'config' parameter has no use, it should be NULL.
And make the code simplifier.

Signed-off-by: Xiubo Li 
---

This resend version just rewrites the commit comment.


 drivers/base/regmap/regmap.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 6a19515..099522b 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1966,9 +1966,11 @@ static int _regmap_update_bits(struct regmap *map, 
unsigned int reg,
 
if (tmp != orig) {
ret = _regmap_write(map, reg, tmp);
-   *change = true;
+   if (change)
+   *change = true;
} else {
-   *change = false;
+   if (change)
+   *change = false;
}
 
return ret;
@@ -1987,11 +1989,10 @@ static int _regmap_update_bits(struct regmap *map, 
unsigned int reg,
 int regmap_update_bits(struct regmap *map, unsigned int reg,
   unsigned int mask, unsigned int val)
 {
-   bool change;
int ret;
 
map->lock(map->lock_arg);
-   ret = _regmap_update_bits(map, reg, mask, val, );
+   ret = _regmap_update_bits(map, reg, mask, val, NULL);
map->unlock(map->lock_arg);
 
return ret;
@@ -2016,14 +2017,13 @@ EXPORT_SYMBOL_GPL(regmap_update_bits);
 int regmap_update_bits_async(struct regmap *map, unsigned int reg,
 unsigned int mask, unsigned int val)
 {
-   bool change;
int ret;
 
map->lock(map->lock_arg);
 
map->async = true;
 
-   ret = _regmap_update_bits(map, reg, mask, val, );
+   ret = _regmap_update_bits(map, reg, mask, val, NULL);
 
map->async = false;
 
-- 
1.8.4


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

Re: [PATCH v2] rcu: ensure kernel/rcu/rcu.h can be sourced/used stand-alone

[Paul E. McKenney]

On Wed, Feb 19, 2014 at 02:33:27PM -0500, Paul Gortmaker wrote:
> The kbuild test bot uncovered an implicit dependence on the
> trace header being present before rcu.h in ia64 allmodconfig
> that looks like this:
> 
> In file included from kernel/ksysfs.c:22:0:
> kernel/rcu/rcu.h: In function '__rcu_reclaim':
> kernel/rcu/rcu.h:107:3: error: implicit declaration of function 
> 'trace_rcu_invoke_kfree_callback' [-Werror=implicit-function-declaration]
> kernel/rcu/rcu.h:112:3: error: implicit declaration of function 
> 'trace_rcu_invoke_callback' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> 
> Looking at other rcu.h users, we can find that they all
> were sourcing the trace header in advance of rcu.h itself,
> as seen in the context of this diff.  There were also some
> inconsistencies as to whether it was or wasn't sourced based
> on the parent tracing Kconfig.
> 
> Rather than "fix" it at each use site, and have inconsistent
> use based on whether "#ifdef CONFIG_RCU_TRACE" was used or not,
> lets just source the trace header just once, in the actual consumer
> of it, which is rcu.h itself.  We include it unconditionally, as
> build testing shows us that is a hard requirement for some files.
> 
> Reported-by: kbuild test robot 
> Signed-off-by: Paul Gortmaker 

Queued for 3.16, thank you, Paul!

Thanx, Paul

> ---
> 
> [v2: move the #include  outside of the scope
>  of #ifdef CONFIG_RCU_TRACE so it is unconditionally included.]
> 
>  kernel/rcu/rcu.h| 1 +
>  kernel/rcu/srcu.c   | 2 --
>  kernel/rcu/tiny.c   | 4 
>  kernel/rcu/tree.c   | 2 --
>  kernel/rcu/update.c | 1 -
>  5 files changed, 1 insertion(+), 9 deletions(-)
> 
> diff --git a/kernel/rcu/rcu.h b/kernel/rcu/rcu.h
> index 1bd787fddcb2..3d2a037332b2 100644
> --- a/kernel/rcu/rcu.h
> +++ b/kernel/rcu/rcu.h
> @@ -23,6 +23,7 @@
>  #ifndef __LINUX_RCU_H
>  #define __LINUX_RCU_H
> 
> +#include 
>  #ifdef CONFIG_RCU_TRACE
>  #define RCU_TRACE(stmt) stmt
>  #else /* #ifdef CONFIG_RCU_TRACE */
> diff --git a/kernel/rcu/srcu.c b/kernel/rcu/srcu.c
> index 5db7e9272d37..8e66b05bfd82 100644
> --- a/kernel/rcu/srcu.c
> +++ b/kernel/rcu/srcu.c
> @@ -36,8 +36,6 @@
>  #include 
>  #include 
> 
> -#include 
> -
>  #include "rcu.h"
> 
>  /*
> diff --git a/kernel/rcu/tiny.c b/kernel/rcu/tiny.c
> index 53b95bbf4abb..d9efcc13008c 100644
> --- a/kernel/rcu/tiny.c
> +++ b/kernel/rcu/tiny.c
> @@ -37,10 +37,6 @@
>  #include 
>  #include 
> 
> -#ifdef CONFIG_RCU_TRACE
> -#include 
> -#endif /* #else #ifdef CONFIG_RCU_TRACE */
> -
>  #include "rcu.h"
> 
>  /* Forward declarations for tiny_plugin.h. */
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index c7a00dbe768b..351faba48b91 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -58,8 +58,6 @@
>  #include 
> 
>  #include "tree.h"
> -#include 
> -
>  #include "rcu.h"
> 
>  MODULE_ALIAS("rcutree");
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index fd0d5b5b8e7c..4c0a9b0af469 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -49,7 +49,6 @@
>  #include 
> 
>  #define CREATE_TRACE_POINTS
> -#include 
> 
>  #include "rcu.h"
> 
> -- 
> 1.8.5.2
> 

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

Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

[Linaro]

> On 20-Feb-2014, at 7:19 am, Linaro  wrote:
> 
> 
> 
>>> On 19-Feb-2014, at 10:56 pm, Stephen Warren  wrote:
>>> 
 On 02/18/2014 09:15 PM, Viresh Kumar wrote:
> On 19-Feb-2014 1:48 AM, "Stephen Warren"  wrote:
> 
>> On 02/17/2014 02:20 AM, Viresh Kumar wrote:
>> On 15 February 2014 05:33, Stephen Warren  wrote:
>> On 02/14/2014 03:23 PM, Rafael J. Wysocki wrote:
> 
>>> Well, it would be good to verify which part, then.
>> 
>> Patch 2/7 appears to stop that message from being printed during
>> suspend, and perhaps reduce the number of times it's printed during
>> resume. Patch 7/7 stops the message being printed at all.
>> 
>> Looking at patch 7, I wonder if it's simply because tegra_target() was
>> modified never to return -EBUSY, so the bug is still there, but it's
>> just been hidden.
> 
> No, the bug is removed now. Its hidden in current linus/master :)
 
 I'm not sure what that means; I still see the message:
>>> 
>>> I have given a better reply in one of the earlier mails in this thread.
>>> And skipped a more elaborative reply now.
>>> 
>>> So this failure was always there since long time, as you disable your
>>> target() fn early in suspend. But the message wasn't printed earlier.
>>> 
>>> A recently added core patch started printing this, so not a new bug.
>>> But this series fixes suspend resume completely and you wouldn't see it
>>> anymore.
>> 
>> OK, so I suppose we have two options:
>> 
>> a) Just ignore the kernel error spew since it's a known issue.
>> 
>> b) If I make the Tegra driver return 0 rather than -EBUSY, would that
>> work? It would certainly silence the error. However, I wonder if it
>> would cause the cpufreq core to get out of sync with HW; the core would
>> think that it'd set some frequency, which the driver ignored, and if it
>> later wanted to switch frequency, the call might get skipped because the
>> core thought the HW was already set to that frequency?
> 
> Option is the one you need.

Option a..--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V5 0/7] cpufreq: suspend early/resume late: dpm_{suspend|resume}()

[Linaro]

> On 19-Feb-2014, at 10:56 pm, Stephen Warren  wrote:
> 
>> On 02/18/2014 09:15 PM, Viresh Kumar wrote:
>>> On 19-Feb-2014 1:48 AM, "Stephen Warren"  wrote:
>>> 
 On 02/17/2014 02:20 AM, Viresh Kumar wrote:
> On 15 February 2014 05:33, Stephen Warren  wrote:
> On 02/14/2014 03:23 PM, Rafael J. Wysocki wrote:
 
>> Well, it would be good to verify which part, then.
> 
> Patch 2/7 appears to stop that message from being printed during
> suspend, and perhaps reduce the number of times it's printed during
> resume. Patch 7/7 stops the message being printed at all.
> 
> Looking at patch 7, I wonder if it's simply because tegra_target() was
> modified never to return -EBUSY, so the bug is still there, but it's
> just been hidden.
 
 No, the bug is removed now. Its hidden in current linus/master :)
>>> 
>>> I'm not sure what that means; I still see the message:
>> 
>> I have given a better reply in one of the earlier mails in this thread.
>> And skipped a more elaborative reply now.
>> 
>> So this failure was always there since long time, as you disable your
>> target() fn early in suspend. But the message wasn't printed earlier.
>> 
>> A recently added core patch started printing this, so not a new bug.
>> But this series fixes suspend resume completely and you wouldn't see it
>> anymore.
> 
> OK, so I suppose we have two options:
> 
> a) Just ignore the kernel error spew since it's a known issue.
> 
> b) If I make the Tegra driver return 0 rather than -EBUSY, would that
> work? It would certainly silence the error. However, I wonder if it
> would cause the cpufreq core to get out of sync with HW; the core would
> think that it'd set some frequency, which the driver ignored, and if it
> later wanted to switch frequency, the call might get skipped because the
> core thought the HW was already set to that frequency?

Option is the one you need.--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] workqueue: Fix possible unexpectedly worker wakeup before started

[Lai Jiangshan]

On 02/20/2014 08:11 AM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Wed, Feb 19, 2014 at 11:47:58AM +0800, Lai Jiangshan wrote:
>> If a worker is wokenup unexpectedly, it will start to work incorretly.
>> Although it hardly happen, we should catch it and wait for being started
>> if it does happen.
> 
> Can this actually happen?  If so, how?

I don't think it can happen.
It depends on the system outside of workqueue.

I'm afraid someone see the task and wake up it.
workqueue protect itself.

> 
>> Signed-off-by: Lai Jiangshan 
>> ---
>>  kernel/workqueue.c |6 ++
>>  1 files changed, 6 insertions(+), 0 deletions(-)
>>
>> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
>> index 82ef9f3..bee5fe1 100644
>> --- a/kernel/workqueue.c
>> +++ b/kernel/workqueue.c
>> @@ -2284,6 +2284,12 @@ static int worker_thread(void *__worker)
>>  struct worker *worker = __worker;
>>  struct worker_pool *pool = worker->pool;
>>  
>> +if (WARN_ON_ONCE(!(worker->flags & WORKER_STARTED))) {
> 
> And if this is something which can legitimately happen, why are we
> triggering WARN on it?

If it happens, it means there is something wrong in the system.

> 
>> +/* The worker is wokenup unexpectedly before started */
>> +mutex_lock(>manager_mutex);
>> +mutex_unlock(>manager_mutex);
> 
> And what does these mutex cycling achieve (they need comment)?

Synchronize the manager to finish.

> 
> Thanks.
> 

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

Re: [PATCH v6 4/4] i2c, i2c_imc: Add DIMM bus code

[Andy Lutomirski]

On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony  wrote:
>> (I'm c/c Tony here, as he also shared the same concern that I had on a
>> previous feedback about using I2C to talk with the DIMM).
>
> Correct - I've heard the same issues that reads on I2C can be misinterpreted
> as writes ... and oops, you have a brick.

Is this true on DDR3 DIMMs, i.e. anything that's compatible with
LGA2011?  If you plug a DIMM into an LGA2011 board's memory slot,
then, one way or another, it's very likely that there will be TSOD
traffic, if for no other purpose than to determine that there is no
TSOD present.  TSOD traffic consists of reads and writes, both with
and without register numbers.  (Sorry, I can never remember the smbus
terminology here -- the relevant transactions are two-byte reads and
two-byte writes, both with a command specified and without one.  One
of the bits in the iMC SMBUS registers tells the controller which kind
of read to use to probe the thermometer.)

>
> What is the larger context/  What problem are we trying to solve?

NV-DIMM control registers are exposed via i2c, presumably because
trying to access them through the memory pins would be a giant mess.
So, one way or another, something needs to be able to initiate
transactions to access those registers.  BIOS will do some initial
setup, but the OS will need to poke at these registers, too.  (The
actual docs are covered by NDA.  I suspect that this will change if
the manufacturers ever want these things to be widely used, though,
since these things really want a full-featured kernel driver so that
things like pmfs will work cleanly.)

As a secondary benefit, having access to the TSOD and SPD is nice,
albeit far from critical.

AFAICT Intel actively working on NV-DIMM-related things, so maybe
Intel will contribute an engineer who help :)

--Andy

>
> -Tony



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/4] Add audio card DT node support for Vybird-TWR board

[Shawn Guo]

On Wed, Feb 19, 2014 at 03:42:27PM +0800, Xiubo Li wrote:
> Xiubo Li (4):
>   ARM: dts: vf610: Add edma mux Tx and Rx support for SAI node.
>   ARM: dts: vf610-twr: Enable SAI ALSA SoC DAI device
>   ARM: dts: vf610-twr: Enable SGTL5000 codec.
>   ARM: dts: vf610-twr: Add simple-card support.

Applied all, thanks.

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

[PATCH 3/4] perf tools: Check return value of filename__read_debuglink()

[Namhyung Kim]

From: Stephane Eranian 

When dso__read_binary_type_filename() called, it doesn't check the
return value of filename__read_debuglink() so that it'll try to open
the debuglink file even if it doesn't exist.

Also fix return value of the filename__read_debuglink() as it always
return -1 regardless of the result.

Cc: Cody P Schafer 
Signed-off-by: Namhyung Kim 
---
Stephane, can I add your s-o-b here?

 tools/perf/util/dso.c| 4 ++--
 tools/perf/util/symbol-elf.c | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 4045d086d9d9..64453d63b971 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -45,8 +45,8 @@ int dso__read_binary_type_filename(const struct dso *dso,
debuglink--;
if (*debuglink == '/')
debuglink++;
-   filename__read_debuglink(dso->long_name, debuglink,
-size - (debuglink - filename));
+   ret = filename__read_debuglink(dso->long_name, debuglink,
+  size - (debuglink - filename));
}
break;
case DSO_BINARY_TYPE__BUILD_ID_CACHE:
diff --git a/tools/perf/util/symbol-elf.c b/tools/perf/util/symbol-elf.c
index 3e9f336740fa..8ac4a4fe2abd 100644
--- a/tools/perf/util/symbol-elf.c
+++ b/tools/perf/util/symbol-elf.c
@@ -506,6 +506,8 @@ int filename__read_debuglink(const char *filename, char 
*debuglink,
/* the start of this section is a zero-terminated string */
strncpy(debuglink, data->d_buf, size);
 
+   err = 0;
+
 out_elf_end:
elf_end(elf);
 out_close:
-- 
1.7.11.7

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

[PATCH 1/4] perf tools: Check availability of annotate when processing samples

[Namhyung Kim]

The TUI of perf report and top support annotation, but stdio and GTK
don't.  So it should be checked before calling hist_entry__inc_addr_
samples() since perf annotate need it regardless of UI and sort keys.

It caused perf annotate on ppc64 to produce zero output.

Reported-by: Anton Blanchard 
Cc: Anton Blanchard 
Signed-off-by: Namhyung Kim 
---
 tools/perf/builtin-report.c | 45 +
 tools/perf/builtin-top.c| 11 +--
 tools/perf/util/annotate.c  |  2 +-
 3 files changed, 39 insertions(+), 19 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index d882b6f96411..bab762bdeb0d 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -75,6 +75,11 @@ static int report__config(const char *var, const char 
*value, void *cb)
return perf_default_config(var, value, cb);
 }
 
+static bool report_needs_annotate(void)
+{
+   return use_browser == 1 && sort__has_sym;
+}
+
 static int report__add_mem_hist_entry(struct report *rep, struct addr_location 
*al,
  struct perf_sample *sample, struct 
perf_evsel *evsel)
 {
@@ -110,14 +115,16 @@ static int report__add_mem_hist_entry(struct report *rep, 
struct addr_location *
if (!he)
return -ENOMEM;
 
-   err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
-   if (err)
-   goto out;
+   if (report_needs_annotate()) {
+   err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+   if (err)
+   goto out;
 
-   mx = he->mem_info;
-   err = addr_map_symbol__inc_samples(>daddr, evsel->idx);
-   if (err)
-   goto out;
+   mx = he->mem_info;
+   err = addr_map_symbol__inc_samples(>daddr, evsel->idx);
+   if (err)
+   goto out;
+   }
 
evsel->hists.stats.total_period += cost;
hists__inc_nr_events(>hists, PERF_RECORD_SAMPLE);
@@ -159,14 +166,18 @@ static int report__add_branch_hist_entry(struct report 
*rep, struct addr_locatio
he = __hists__add_entry(>hists, al, parent, [i], NULL,
1, 1, 0);
if (he) {
-   bx = he->branch_info;
-   err = addr_map_symbol__inc_samples(>from, 
evsel->idx);
-   if (err)
-   goto out;
-
-   err = addr_map_symbol__inc_samples(>to, evsel->idx);
-   if (err)
-   goto out;
+   if (report_needs_annotate()) {
+   bx = he->branch_info;
+   err = addr_map_symbol__inc_samples(>from,
+  evsel->idx);
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(>to,
+  evsel->idx);
+   if (err)
+   goto out;
+   }
 
evsel->hists.stats.total_period += 1;
hists__inc_nr_events(>hists, PERF_RECORD_SAMPLE);
@@ -199,7 +210,9 @@ static int report__add_hist_entry(struct report *rep, 
struct perf_evsel *evsel,
if (err)
goto out;
 
-   err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+   if (report_needs_annotate())
+   err = hist_entry__inc_addr_samples(he, evsel->idx, al->addr);
+
evsel->hists.stats.total_period += sample->period;
hists__inc_nr_events(>hists, PERF_RECORD_SAMPLE);
 out:
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index ed99ec4a309f..a19c3afcfa0e 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -87,6 +87,11 @@ static void perf_top__sig_winch(int sig __maybe_unused,
perf_top__update_print_entries(top);
 }
 
+static bool top_needs_annotate(void)
+{
+   return use_browser == 1 && sort__has_sym;
+}
+
 static int perf_top__parse_source(struct perf_top *top, struct hist_entry *he)
 {
struct symbol *sym;
@@ -176,7 +181,7 @@ static void perf_top__record_precise_ip(struct perf_top 
*top,
 {
struct annotation *notes;
struct symbol *sym;
-   int err;
+   int err = 0;
 
if (he == NULL || he->ms.sym == NULL ||
((top->sym_filter_entry == NULL ||
@@ -190,7 +195,9 @@ static void perf_top__record_precise_ip(struct perf_top 
*top,
return;
 
ip = he->ms.map->map_ip(he->ms.map, ip);
-   err = hist_entry__inc_addr_samples(he, counter, ip);
+
+   if (top_needs_annotate())
+   err = hist_entry__inc_addr_samples(he, counter, ip);
 

[PATCH 4/4] perf tools: Check compatible symtab type before loading dso

[Namhyung Kim]

When loading a dso it'll look for symbol tables of all possible types.
However it's just wasted of time to check incompatible types - like
trying kernel module when loading user library.

Cc: Stephane Eranian 
Cc: Adrian Hunter 
Cc: Cody P Schafer 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 61 +---
 1 file changed, 52 insertions(+), 9 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index c3b014712fce..95e249779931 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1251,6 +1251,46 @@ out_failure:
return -1;
 }
 
+static bool dso__is_compatible_symtab_type(struct dso *dso, bool kmod,
+  enum dso_binary_type type)
+{
+   switch (type) {
+   case DSO_BINARY_TYPE__JAVA_JIT:
+   case DSO_BINARY_TYPE__DEBUGLINK:
+   case DSO_BINARY_TYPE__SYSTEM_PATH_DSO:
+   case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
+   case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
+   case DSO_BINARY_TYPE__BUILDID_DEBUGINFO:
+   case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
+   return !kmod && dso->kernel == DSO_TYPE_USER;
+
+   case DSO_BINARY_TYPE__KALLSYMS:
+   case DSO_BINARY_TYPE__VMLINUX:
+   case DSO_BINARY_TYPE__KCORE:
+   return dso->kernel == DSO_TYPE_KERNEL;
+
+   case DSO_BINARY_TYPE__GUEST_KALLSYMS:
+   case DSO_BINARY_TYPE__GUEST_VMLINUX:
+   case DSO_BINARY_TYPE__GUEST_KCORE:
+   return dso->kernel == DSO_TYPE_GUEST_KERNEL;
+
+   case DSO_BINARY_TYPE__GUEST_KMODULE:
+   case DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE:
+   /*
+* kernel modules know their symtab type - it's set when
+* creating a module dso in machine__new_module().
+*/
+   return kmod && dso->symtab_type == type;
+
+   case DSO_BINARY_TYPE__BUILD_ID_CACHE:
+   return true;
+
+   case DSO_BINARY_TYPE__NOT_FOUND:
+   default:
+   return false;
+   }
+}
+
 int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
 {
char *name;
@@ -1261,6 +1301,7 @@ int dso__load(struct dso *dso, struct map *map, 
symbol_filter_t filter)
int ss_pos = 0;
struct symsrc ss_[2];
struct symsrc *syms_ss = NULL, *runtime_ss = NULL;
+   bool kmod;
 
dso__set_loaded(dso, map->type);
 
@@ -1301,7 +1342,11 @@ int dso__load(struct dso *dso, struct map *map, 
symbol_filter_t filter)
if (!name)
return -1;
 
-   /* Iterate over candidate debug images.
+   kmod = dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ||
+   dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE;
+
+   /*
+* Iterate over candidate debug images.
 * Keep track of "interesting" ones (those which have a symtab, dynsym,
 * and/or opd section) for processing.
 */
@@ -1311,6 +1356,9 @@ int dso__load(struct dso *dso, struct map *map, 
symbol_filter_t filter)
 
enum dso_binary_type symtab_type = binary_type_symtab[i];
 
+   if (!dso__is_compatible_symtab_type(dso, kmod, symtab_type))
+   continue;
+
if (dso__read_binary_type_filename(dso, symtab_type,
   root_dir, name, PATH_MAX))
continue;
@@ -1353,15 +1401,10 @@ int dso__load(struct dso *dso, struct map *map, 
symbol_filter_t filter)
if (!runtime_ss && syms_ss)
runtime_ss = syms_ss;
 
-   if (syms_ss) {
-   int km;
-
-   km = dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE ||
-dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE;
-   ret = dso__load_sym(dso, map, syms_ss, runtime_ss, filter, km);
-   } else {
+   if (syms_ss)
+   ret = dso__load_sym(dso, map, syms_ss, runtime_ss, filter, 
kmod);
+   else
ret = -1;
-   }
 
if (ret > 0) {
int nr_plt;
-- 
1.7.11.7

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

[PATCH 2/4] perf tools: Destroy unused symsrcs

[Namhyung Kim]

Stephane reported that perf report and annotate failed to process data
using lots of (> 500) shared libraries.  It was because of the limit
on number of open files (ulimit -n).

Currently when perf loads dso, it'll look for normal and dynamic
symbol tables.  And if it failed to find out both tables, it'll
iterate all of possible symtab types.  But many of them are useless
since they have no additional information and the problem is that it's
not close those files even though they're not used.  Fix it.

Reported-by: Stephane Eranian 
Cc: Cody P Schafer 
Signed-off-by: Namhyung Kim 
---
 tools/perf/util/symbol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 46e2ede12c51..c3b014712fce 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1336,6 +1336,8 @@ int dso__load(struct dso *dso, struct map *map, 
symbol_filter_t filter)
 
if (syms_ss && runtime_ss)
break;
+   } else {
+   symsrc__destroy(ss);
}
 
}
-- 
1.7.11.7

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

[Update][PATCH 6/9] ACPI / ATA: Add hotplug contexts to ACPI companions of SATA devices

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

Modify the SATA subsystem to add hotplug contexts to ACPI companions
of SATA devices and ports instead of registering special ACPI dock
operations using register_hotplug_dock_device().

That change will allow the entire code handling those special ACPI
dock operations to be dropped in the next commit.

Signed-off-by: Rafael J. Wysocki 
---

As noted by Aaron, the hotplug contexts are not freed during ATA device
unregistration, but that is not necessary, because the struct acpi_device
things they are attached to never go away.  However, they obviously should
not be created more than once per struct acpi_device, so I've modified the
patch to skip the creation of hotplug contexts for devices that already
have them.

Thanks,
Rafael

---
 drivers/ata/libata-acpi.c |   76 +-
 1 file changed, 49 insertions(+), 27 deletions(-)

Index: linux-pm/drivers/ata/libata-acpi.c
===
--- linux-pm.orig/drivers/ata/libata-acpi.c
+++ linux-pm/drivers/ata/libata-acpi.c
@@ -38,6 +38,16 @@ static void ata_acpi_clear_gtf(struct at
dev->gtf_cache = NULL;
 }
 
+struct ata_acpi_hotplug_context {
+   struct acpi_hotplug_context hp;
+   union {
+   struct ata_port *ap;
+   struct ata_device *dev;
+   } data;
+};
+
+#define ata_hotplug_data(context) (container_of((context), struct 
ata_acpi_hotplug_context, hp)->data)
+
 /**
  * ata_dev_acpi_handle - provide the acpi_handle for an ata_device
  * @dev: the acpi_handle returned will correspond to this device
@@ -121,18 +131,17 @@ static void ata_acpi_handle_hotplug(stru
ata_port_wait_eh(ap);
 }
 
-static void ata_acpi_dev_notify_dock(acpi_handle handle, u32 event, void *data)
+static int ata_acpi_dev_notify_dock(struct acpi_device *adev, u32 event)
 {
-   struct ata_device *dev = data;
-
+   struct ata_device *dev = ata_hotplug_data(adev->hp).dev;
ata_acpi_handle_hotplug(dev->link->ap, dev, event);
+   return 0;
 }
 
-static void ata_acpi_ap_notify_dock(acpi_handle handle, u32 event, void *data)
+static int ata_acpi_ap_notify_dock(struct acpi_device *adev, u32 event)
 {
-   struct ata_port *ap = data;
-
-   ata_acpi_handle_hotplug(ap, NULL, event);
+   ata_acpi_handle_hotplug(ata_hotplug_data(adev->hp).ap, NULL, event);
+   return 0;
 }
 
 static void ata_acpi_uevent(struct ata_port *ap, struct ata_device *dev,
@@ -154,31 +163,23 @@ static void ata_acpi_uevent(struct ata_p
}
 }
 
-static void ata_acpi_ap_uevent(acpi_handle handle, u32 event, void *data)
+static void ata_acpi_ap_uevent(struct acpi_device *adev, u32 event)
 {
-   ata_acpi_uevent(data, NULL, event);
+   ata_acpi_uevent(ata_hotplug_data(adev->hp).ap, NULL, event);
 }
 
-static void ata_acpi_dev_uevent(acpi_handle handle, u32 event, void *data)
+static void ata_acpi_dev_uevent(struct acpi_device *adev, u32 event)
 {
-   struct ata_device *dev = data;
+   struct ata_device *dev = ata_hotplug_data(adev->hp).dev;
ata_acpi_uevent(dev->link->ap, dev, event);
 }
 
-static const struct acpi_dock_ops ata_acpi_dev_dock_ops = {
-   .handler = ata_acpi_dev_notify_dock,
-   .uevent = ata_acpi_dev_uevent,
-};
-
-static const struct acpi_dock_ops ata_acpi_ap_dock_ops = {
-   .handler = ata_acpi_ap_notify_dock,
-   .uevent = ata_acpi_ap_uevent,
-};
-
 /* bind acpi handle to pata port */
 void ata_acpi_bind_port(struct ata_port *ap)
 {
struct acpi_device *host_companion = ACPI_COMPANION(ap->host->dev);
+   struct acpi_device *adev;
+   struct ata_acpi_hotplug_context *context;
 
if (libata_noacpi || ap->flags & ATA_FLAG_ACPI_SATA || !host_companion)
return;
@@ -188,9 +189,19 @@ void ata_acpi_bind_port(struct ata_port
if (ata_acpi_gtm(ap, >__acpi_init_gtm) == 0)
ap->pflags |= ATA_PFLAG_INIT_GTM_VALID;
 
-   /* we might be on a docking station */
-   register_hotplug_dock_device(ACPI_HANDLE(>tdev),
-_acpi_ap_dock_ops, ap, NULL, NULL);
+   adev = ACPI_COMPANION(>tdev);
+   if (!adev || adev->hp)
+   return;
+
+   context = kzalloc(sizeof(*context), GFP_KERNEL);
+   if (!context)
+   return;
+
+   context->data.ap = ap;
+   acpi_lock_hp_context();
+   acpi_set_hp_context(adev, >hp, ata_acpi_ap_notify_dock,
+   ata_acpi_ap_uevent, NULL);
+   acpi_unlock_hp_context();
 }
 
 void ata_acpi_bind_dev(struct ata_device *dev)
@@ -198,7 +209,8 @@ void ata_acpi_bind_dev(struct ata_device
struct ata_port *ap = dev->link->ap;
struct acpi_device *port_companion = ACPI_COMPANION(>tdev);
struct acpi_device *host_companion = ACPI_COMPANION(ap->host->dev);
-   struct acpi_device *parent;
+   struct acpi_device *parent, *adev;
+   struct ata_acpi_hotplug_context *context;

Re: linux-next: manual merge of the imx-mxs tree with the arm-soc tree

[Shawn Guo]

On Thu, Feb 20, 2014 at 11:42:42AM +1100, Stephen Rothwell wrote:
> Hi Shawn,
> 
> Today's linux-next merge of the imx-mxs tree got conflicts in
> arch/arm/mach-imx/Makefile and arch/arm/mach-imx/common.h between commit
> 28a9f3b078c5 ("ARM: imx6: build pm-imx6q.c independently of CONFIG_PM")
> from the arm-soc tree and commits 8dd751932545 ("ARM: imx: add suspend in
> ocram support for i.mx6q") and 79a8eef47d12 ("RM: imx: add suspend in
> ocram support for i.mx6sl") from the imx-mxs tree.
> 
> I fixed it up (I think, see below) and can carry the fix as necessary (no
> action is required).

Thanks, Stephen.  Once "ARM: imx6: build pm-imx6q.c independently of
CONFIG_PM" hits mainline, I will rebase my branch against the latest -rc
to get rid of the conflicts.

Shawn

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

Re: [PATCH v6 4/4] i2c, i2c_imc: Add DIMM bus code

[Andy Lutomirski]

On Wed, Feb 19, 2014 at 11:26 AM, One Thousand Gnomes
 wrote:
>> example, lots of graphics drivers provide i2c busses, and those busses
>> often contain eeproms, and, in theory, things should know that the
>> eeprom is associated with a particular graphics port, for example.
>> Unfortunately, the i2c core does not know that, things like
>> decode-dimms will try to decode it, sensors-detect will scan graphics
>> ports for motherboard sensors, etc.
>
> ACPI does now try to describe what is on an i²c bus. We perhaps don't use
> that information well but on a modern PC class box at least for onboard
> devices most of the info is there for the munching.

I'm discussing the in-kernel representation, not where the information
comes from.  Presumably there should be something in the kernel that
works for ACPI, DT, and directly-enumerated busses (see below).

>
>> For extra fun, there could be drivers for different types of i2c_port.
>>  One of them could be the "DIMM bus" driver, which would know how to
>> probe the i2c adapter associated with a DIMM port.  Another could be
>> the graphics port driver, which (maybe with some extra configuration
>> hints from the graphics driver) could look for EDID-related things.
>
> Busses are not necessarily that tidily organised. There isn't anything
> saying you can't sneak multiple things on the same bus. In the graphics
> case its unlikely but I wouldn't rule even that out for a display panel.
> Once you get onto phones and tablets it seems anything goes 8)
>

I'm suggesting identifying a range of addresses on a bus with a "port"
(or whatever it should be called).  Multiple ports could claim
non-overlapping ranges on the same bus.

>> I wonder if this would fit in well with the device tree stuff, too --
>> DT has ways to say "this node links to that one", right?
>
> ACPI basically tries to describe the heirarchy of devices on the bus, but
> as you say the "real" device can be a rambling mix of GPIO, I²C, SPI,
> PCI (quite probably fake PCI at that) and other resources.
>
> If there is a legitimate use case for poking around with memory dimm i2c
> on these boards then really there needs to be a proper defined interface
> for doing so that covers firmware and OS users.

The legitimate use case is NV-DIMMs.  They have control registers that
are accessed via smbus.  BIOS is likely to poke at those registers
early in boot, but the kernel and/or userspace will need them, too.
It would be nice to know which DIMM slot they map to.

In this particular case (Intel LGA2011 systems), there's only one sane
way to wire up the busses, since the memory controller *is* the smbus
master.  According to the JEDEC spec, each DIMM slot is has three pins
that indicate which slot it is on its channel, and the onboard smbus
hardware uses those pins to select its addresses.  (This maps directly
to three of the seven address bits.)  Each memory controller supports
two RAM channels and two i2c channels, and, if you wire them backwards
(or mix them up between controllers), then I would be amazed if the
system works.  So this particular driver really does know the topology
a priori.

On the other hand, nothing rules out having NV-DIMMs in non-LGA2011
systems where the smbus/i2c topology is less certain.  But I think it
would be silly for an eventual NVDIMM driver to specifically depend on
ACPI, since ACPI isn't needed for existing LGA2011 NVDIMM systems.

(Knowing which physical memory addresses map to which DIMM is a
different story.  I think that the sb-edac driver knows the mapping,
though.)

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] PM / sleep: New flag to speed up suspend-resume of suspended devices

[Rafael J. Wysocki]

On Thursday, February 20, 2014 02:23:30 AM Rafael J. Wysocki wrote:
> On Wednesday, February 19, 2014 12:01:20 PM Alan Stern wrote:
> > On Mon, 17 Feb 2014, Rafael J. Wysocki wrote:
> > 
> > > From: Rafael J. Wysocki 
> > > 
> > > Currently, some subsystems (e.g. PCI and the ACPI PM domain) have to
> > > resume all runtime-suspended devices during system suspend, mostly
> > > because those devices may need to be reprogrammed due to different
> > > wakeup settings for system sleep and for runtime PM.  However, at
> > > least in some cases, that isn't really necessary, because the wakeup
> > > settings may not be really different.
> > > 
> > > The idea here is that subsystems should know whether or not it is
> > > necessary to reprogram a given device during system suspend and they
> > > should be able to tell the PM core about that.  For this reason,
> > > modify the PM core so that if the .prepare() callback returns a
> > > positive value for certain device, the core will set a new
> > > power.fast_suspend flag for it.  Then, if that flag is set, the core
> > > will skip all of the subsequent suspend callbacks for that device.
> > > It also will skip all of the system resume callbacks for the device
> > > during the subsequent system resume and pm_request_resume() will be
> > > executed to trigger a runtime PM resume of the device after the
> > > system device resume sequence has been finished.
> 
> I was worried that you wouldn't comment at all. ;-)
> 
> > Does the PM core really need to get involved in this?
> 
> Yes, it does, in my opinion, and the reason is because it may be necessary
> to resume parents in order to reprogram their children and the parents and
> the children may be on different bus types.
> 
> > Can't the subsystem do the right thing on its own?
> 
> No, I don't think so.
> 
> > In the USB subsystem, the .suspend routine checks the required wakeup
> > settings.  If they are different for runtime suspend and system
> > suspend, and if the device is runtime suspended, then we call
> > pm_runtime_resume.  After that, if the device is still in runtime
> > suspend then we return immediately.
> > 
> > Of course, this addresses only the suspend side of the issue.  Skipping 
> > the resume callbacks is a separate matter, and the USB subsystem 
> > doesn't try to do it.  Still, I don't see any reason why we couldn't 
> > take care of that as well.
> 
> What about USB controllers that are PCI devices?
> 
> > > However, since parents may need to be resumed so that their children
> > > can be reprogrammed, make the PM core clear power.fast_suspend for
> > > devices whose children don't have power.fast_suspend set (the
> > > power.ignore_children flag doesn't matter here, because a parent
> > > whose children are normally ignored for runtime PM may still need to
> > > be accessible for their children to be prepare for system suspend
> > > properly).
> > 
> > I have run across a similar issue.  It's a general problem that a
> > device may try to remain in runtime suspend during a system resume, but
> > a descendant of the device may need to perform I/O as part of its own
> > resume routine.  A natural solution would be to use the regular runtime
> > PM facilities to wake up the device.  But since the PM work queue is
> > frozen, we can't rely on pm_runtime_get or the equivalent.  I'm not
> > sure what the best solution will be.
> 
> We can rely on pm_runtime_get_sync(), though, which would be the right thing 
> to
> use here.
> 
> However, given that the parent's .prepare() has run already, I'm not sure
> if we want runtime PM to be involved at all.
> 
> > After a quick look, I noticed a couple of questionable things in this
> > patch.  This is after reading just the second half...
> > 
> > > @@ -1296,8 +1301,10 @@ static int __device_suspend(struct devic
> > >* for it, this is equivalent to the device signaling wakeup, so the
> > >* system suspend operation should be aborted.
> > >*/
> > > - if (pm_runtime_barrier(dev) && device_may_wakeup(dev))
> > > + if (pm_runtime_barrier(dev) && device_may_wakeup(dev)) {
> > >   pm_wakeup_event(dev, 0);
> > > + dev->power.fast_suspend = false;
> > > + }
> > 
> > Is this change needed?  We're aborting the sleep transition anyway, 
> > right?
> 
> Yes, we are.  The goal was to ensure that power.fast_suspend would be cleared
> in that case, but dpm_resume_end() should take care of this anyway.

Sorry, I wanted to say "the clearing of it in device_prepare()", not sure why
I mentioned dpm_resume_end().  Well, maybe I'm too tired ...

Rafael

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

Re: [PATCH 3.13 00/40] 3.13.4-stable review

[Shuah Khan]

On 02/19/2014 05:36 PM, Mark Brown wrote:

On Wed, Feb 19, 2014 at 05:16:22PM -0700, Shuah Khan wrote:


On Intel systems, there are no dmesg regressions: emerg, crit,
alert, err are clean. No regressions in warn.



On AMD systems, the following new error messages - suspect is to
drivers/regulator/core.c - patch



3.13.4 - amd:

sdhci-pci :02:00.1: dummy supplies not allowed
sdhci-pci :02:00.1: dummy supplies not allowed

drivers/regulator/core.c - patch


This is nothing to do with AMD or Intel, it's to do with if your system
has a sdhci-pci device in it.  This shouldn't result in a change in
actual behaviour, it's just a warning caused by the fact that we now do
provide dummies for other devices.



Right. I think this message should be a warning instead of an error. 
Error is too alarming, unless there is a good reason for it to be an error.


-- Shuah

--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah...@samsung.com | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/