Re: [PATCH] namespace:unmount pid_namespace's proc_mnt when copy_net_ns failed
Gao feng writes:
> we should call pid_ns_release_proc to unmount pid_namespace's
> proc_mnt when copy_net_ns failed in function create_new_namespaces.
>
> otherwise,the proc_mnt will not be freed and because the super_block
> of proc_mnt also add the reference of the pid_namespace,so this
> pid_namespace will never be released too.
Ouch!
Have you encountered this failure in practice or is this just from
review?
I'm trying to gauge the severity of this leak.
Eric
> Signed-off-by: Gao feng
> ---
> kernel/nsproxy.c |5 -
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> index b576f7f..d536480 100644
> --- a/kernel/nsproxy.c
> +++ b/kernel/nsproxy.c
> @@ -99,8 +99,11 @@ static struct nsproxy *create_new_namespaces(unsigned long
> flags,
> return new_nsp;
>
> out_net:
> - if (new_nsp->pid_ns)
> + if (new_nsp->pid_ns) {
> + if (flags & CLONE_NEWPID)
> + pid_ns_release_proc(new_nsp->pid_ns);
> put_pid_ns(new_nsp->pid_ns);
> + }
> out_pid:
> if (new_nsp->ipc_ns)
> put_ipc_ns(new_nsp->ipc_ns);
--
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 v4 0/3] zram/zsmalloc promotion
This patchset promotes zram/zsmalloc from staging. Both are very clean and zram have been used by many embedded product for a long time. It's time to go out of staging. Greg, Jens is already OK that zram is located under driver/blocks/. The issue remained is where we put zsmalloc. The candidate is two under mm/ or under lib/ Konrad and Nitin wanted to put zsmalloc into lib/ instead of mm/. Quote from Nitin " I think mm/ directory should only contain the code which is intended for global use such as the slab allocator, page reclaim code etc. zsmalloc is used by only one (or possibly two) drivers, so lib/ seems to be the right place. " Quote from Konrand " I like the idea of keeping it in /lib or /mm. Actually 'lib' sounds more appropriate since it is dealing with storing a bunch of pages in a nice layout for great density purposes. " In fact, there is some history about that. Why I put zsmalloc into under mm firstly was that Andrew had a concern about using strut page's some fields freely in zsmalloc so he wanted to maintain it in mm/ if I remember correctly. So I and Nitin tried to ask the opinion to akpm several times (at least 6 and even I sent such patch a few month ago) but didn't get any reply from him or any mm guys so I guess mm guys doesn't have any concern about that any more. In point of view that it's an another slab-like allocator, it might be proper under mm but it's not popular as current mm's allocators(/SLUB/SLOB and page allocator). Frankly speaking, I don't care whether we put it to mm/ or lib/. It seems contributors(ex, Nitin, Konrad, Seth and Dan) like lib/ and mm guys are still silent. That's why I am biased into lib/ now. If someone yell we should keep it to mm/ by logical claim, I can change my mind easily. Please raise your hand. If Andrew doesn't have a concern about that any more, I would like to locate it into /lib. This patchset is based on next-20121102. Minchan Kim (3): zsmalloc: promote to lib/ zram: promote zram from staging zram: select ZSMALLOC when ZRAM is configured drivers/block/Kconfig|1 + drivers/block/Makefile |1 + drivers/block/zram/Kconfig | 26 + drivers/block/zram/Makefile |3 + drivers/block/zram/zram.txt | 76 +++ drivers/block/zram/zram_drv.c| 776 ++ drivers/block/zram/zram_drv.h| 119 drivers/block/zram/zram_sysfs.c | 225 +++ drivers/staging/Kconfig |4 - drivers/staging/Makefile |2 - drivers/staging/zcache/zcache-main.c |4 +- drivers/staging/zram/Kconfig | 25 - drivers/staging/zram/Makefile|3 - drivers/staging/zram/zram.txt| 76 --- drivers/staging/zram/zram_drv.c | 776 -- drivers/staging/zram/zram_drv.h | 120 drivers/staging/zram/zram_sysfs.c| 225 --- drivers/staging/zsmalloc/Kconfig | 10 - drivers/staging/zsmalloc/Makefile|3 - drivers/staging/zsmalloc/zsmalloc-main.c | 1064 -- drivers/staging/zsmalloc/zsmalloc.h | 43 -- include/linux/zsmalloc.h | 43 ++ lib/Kconfig | 18 + lib/Makefile |1 + lib/zsmalloc.c | 1064 ++ 25 files changed, 2355 insertions(+), 2353 deletions(-) create mode 100644 drivers/block/zram/Kconfig create mode 100644 drivers/block/zram/Makefile create mode 100644 drivers/block/zram/zram.txt create mode 100644 drivers/block/zram/zram_drv.c create mode 100644 drivers/block/zram/zram_drv.h create mode 100644 drivers/block/zram/zram_sysfs.c delete mode 100644 drivers/staging/zram/Kconfig delete mode 100644 drivers/staging/zram/Makefile delete mode 100644 drivers/staging/zram/zram.txt delete mode 100644 drivers/staging/zram/zram_drv.c delete mode 100644 drivers/staging/zram/zram_drv.h delete mode 100644 drivers/staging/zram/zram_sysfs.c delete mode 100644 drivers/staging/zsmalloc/Kconfig delete mode 100644 drivers/staging/zsmalloc/Makefile delete mode 100644 drivers/staging/zsmalloc/zsmalloc-main.c delete mode 100644 drivers/staging/zsmalloc/zsmalloc.h create mode 100644 include/linux/zsmalloc.h create mode 100644 lib/zsmalloc.c -- 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 v4 3/3] zram: select ZSMALLOC when ZRAM is configured
At the monent, we can configure zram in driver/block once zsmalloc in /lib menu is configured firstly. It's not convenient. User can configure zram in driver/block regardless of zsmalloc enabling by this patch. Signed-off-by: Minchan Kim --- drivers/block/zram/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig index be5abe8..ee23a86 100644 --- a/drivers/block/zram/Kconfig +++ b/drivers/block/zram/Kconfig @@ -1,6 +1,7 @@ config ZRAM tristate "Compressed RAM block device support" - depends on BLOCK && SYSFS && ZSMALLOC + depends on BLOCK && SYSFS + select ZSMALLOC select LZO_COMPRESS select LZO_DECOMPRESS default n -- 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] staging: iio: adc: ad7280a.c: fixed macro coding style
remove unnecessary semicolon from the macro definition
Signed-off-by: Kumar Amit Mehta
---
drivers/staging/iio/adc/ad7280a.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/iio/adc/ad7280a.c
b/drivers/staging/iio/adc/ad7280a.c
index cfc39a7..e7cb3b2 100644
--- a/drivers/staging/iio/adc/ad7280a.c
+++ b/drivers/staging/iio/adc/ad7280a.c
@@ -117,7 +117,7 @@
*/
#define POLYNOM0x2F
#define POLYNOM_ORDER 8
-#define HIGHBIT1 << (POLYNOM_ORDER - 1);
+#define HIGHBIT(1 << (POLYNOM_ORDER - 1))
struct ad7280_state {
struct spi_device *spi;
--
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] namespace:unmount pid_namespace's proc_mnt when copy_net_ns failed
于 2012年11月02日 15:02, Eric W. Biederman 写道:
> Gao feng writes:
>
>> we should call pid_ns_release_proc to unmount pid_namespace's
>> proc_mnt when copy_net_ns failed in function create_new_namespaces.
>>
>> otherwise,the proc_mnt will not be freed and because the super_block
>> of proc_mnt also add the reference of the pid_namespace,so this
>> pid_namespace will never be released too.
>
> Ouch!
>
> Have you encountered this failure in practice or is this just from
> review?
I add some printk in pid_ns_release_proc,it's not called in above case.
when copy_net_ns failed,this pid_namespace is not used by any task,
so proc_flush_task can't call pid_ns_release_proc to umount this
pidns->proc_mnt.
it's the only chance we can unmount this pindns->proc_mnt.
With this patch,everything runs well.
Thanks
Gao
>
> I'm trying to gauge the severity of this leak.
>
> Eric
>
>
>> Signed-off-by: Gao feng
>> ---
>> kernel/nsproxy.c |5 -
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
>> index b576f7f..d536480 100644
>> --- a/kernel/nsproxy.c
>> +++ b/kernel/nsproxy.c
>> @@ -99,8 +99,11 @@ static struct nsproxy *create_new_namespaces(unsigned
>> long flags,
>> return new_nsp;
>>
>> out_net:
>> -if (new_nsp->pid_ns)
>> +if (new_nsp->pid_ns) {
>> +if (flags & CLONE_NEWPID)
>> +pid_ns_release_proc(new_nsp->pid_ns);
>> put_pid_ns(new_nsp->pid_ns);
>> +}
>> out_pid:
>> if (new_nsp->ipc_ns)
>> put_ipc_ns(new_nsp->ipc_ns);
> --
> 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: [PART3 Patch 00/14] introduce N_MEMORY
At 11/02/2012 05:36 AM, David Rientjes Wrote:
> On Thu, 1 Nov 2012, Wen Congyang wrote:
>
>>> This doesn't describe why we need the new node state, unfortunately. It
>>
>> 1. Somethimes, we use the node which contains the memory that can be used by
>>kernel.
>> 2. Sometimes, we use the node which contains the memory.
>>
>> In case1, we use N_HIGH_MEMORY, and we use N_MEMORY in case2.
>>
>
> Yeah, that's clear, but the question is still _why_ we want two different
> nodemasks. I know that this part of the patchset simply introduces the
> new nodemask because the name "N_MEMORY" is more clear than
> "N_HIGH_MEMORY", but there's no real incentive for making that change by
> introducing a new nodemask where a simple rename would suffice.
>
> I can only assume that you want to later use one of them for a different
> purpose: those that do not include nodes that consist of only
> ZONE_MOVABLE. But that change for MPOL_BIND is nacked since it
> significantly changes the semantics of set_mempolicy() and you can't break
> userspace (see my response to that from yesterday). Until that problem is
> addressed, then there's no reason for the additional nodemask so nack on
> this series as well.
>
I still think that we need two nodemasks: one store the node which has memory
that the kernel can use, and one store the node which has memory.
For example:
==
static void *__meminit alloc_page_cgroup(size_t size, int nid)
{
gfp_t flags = GFP_KERNEL | __GFP_ZERO | __GFP_NOWARN;
void *addr = NULL;
addr = alloc_pages_exact_nid(nid, size, flags);
if (addr) {
kmemleak_alloc(addr, size, 1, flags);
return addr;
}
if (node_state(nid, N_HIGH_MEMORY))
addr = vzalloc_node(size, nid);
else
addr = vzalloc(size);
return addr;
}
==
If the node only has ZONE_MOVABLE memory, we should use vzalloc().
So we should have a mask that stores the node which has memory that
the kernel can use.
==
static int mpol_set_nodemask(struct mempolicy *pol,
const nodemask_t *nodes, struct nodemask_scratch *nsc)
{
int ret;
/* if mode is MPOL_DEFAULT, pol is NULL. This is right. */
if (pol == NULL)
return 0;
/* Check N_HIGH_MEMORY */
nodes_and(nsc->mask1,
cpuset_current_mems_allowed, node_states[N_HIGH_MEMORY]);
...
if (pol->flags & MPOL_F_RELATIVE_NODES)
mpol_relative_nodemask(&nsc->mask2, nodes,&nsc->mask1);
else
nodes_and(nsc->mask2, *nodes, nsc->mask1);
...
}
==
If the user specifies 2 nodes: one has ZONE_MOVABLE memory, and the other one
doesn't.
nsc->mask2 should contain these 2 nodes. So we should hava a mask that store
the node
which has memory.
There maybe something wrong in the change for MPOL_BIND. But this patchset is
needed.
Thanks
Wen Congyang
--
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: gdm72xx: wm_ioctl.h: fixed a macro coding style
On Fri, Nov 02, 2012 at 09:55:55AM +0300, Dan Carpenter wrote: > On Thu, Nov 01, 2012 at 11:42:59PM -0700, Kumar Amit Mehta wrote: > > fix for macro coding style. > > > > No. The parenthesis are not needed. I assume this is a > checkpatch.pl warning? > > regards, > dan carpenter > Running checkpatch.pl on this file (wm_ioctl.h) returns error. Thanks, Amit -- 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 00/29] kmem controller for memcg.
On 11/02/2012 04:04 AM, Andrew Morton wrote: > On Thu, 1 Nov 2012 16:07:16 +0400 > Glauber Costa wrote: > >> Hi, >> >> This work introduces the kernel memory controller for memcg. Unlike previous >> submissions, this includes the whole controller, comprised of slab and stack >> memory. > > I'm in the middle of (re)reading all this. Meanwhile I'll push it all > out to http://ozlabs.org/~akpm/mmots/ for the crazier testers. > > One thing: > >> Numbers can be found at https://lkml.org/lkml/2012/9/13/239 > > You claim in the above that the fork worload is 'slab intensive". Or > at least, you seem to - it's a bit fuzzy. > > But how slab intensive is it, really? > > What is extremely slab intensive is networking. The networking guys > are very sensitive to slab performance. If this hasn't already been > done, could you please determine what impact this has upon networking? > I expect Eric Dumazet, Dave Miller and Tom Herbert could suggest > testing approaches. > I can test it, but unfortunately I am unlikely to get to prepare a good environment before Barcelona. I know, however, that Greg Thelen was testing netperf in his setup. Greg, do you have any publishable numbers you could share? -- 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 23/29] memcg: destroy memcg caches
On 11/02/2012 04:05 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:39 +0400
> Glauber Costa wrote:
>
>> This patch implements destruction of memcg caches. Right now,
>> only caches where our reference counter is the last remaining are
>> deleted. If there are any other reference counters around, we just
>> leave the caches lying around until they go away.
>>
>> When that happen, a destruction function is called from the cache
>> code. Caches are only destroyed in process context, so we queue them
>> up for later processing in the general case.
>>
>>
>> ...
>>
>> @@ -5950,6 +6012,7 @@ static int mem_cgroup_pre_destroy(struct cgroup *cont)
>> {
>> struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
>>
>> +mem_cgroup_destroy_all_caches(memcg);
>> return mem_cgroup_force_empty(memcg, false);
>> }
>>
>
> Conflicts with linux-next cgroup changes. Looks pretty simple:
>
>
> static int mem_cgroup_pre_destroy(struct cgroup *cont)
> {
> struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
> int ret;
>
> css_get(&memcg->css);
> ret = mem_cgroup_reparent_charges(memcg);
> mem_cgroup_destroy_all_caches(memcg);
> css_put(&memcg->css);
>
> return ret;
> }
>
There is one significant difference between the code I had and the code
after your fix up.
In my patch, caches were destroyed before the call to
mem_cgroup_force_empty. In the final, version, they are destroyed after it.
I am here thinking, but I am not sure if this have any significant
impact... If we run mem_cgroup_destroy_all_caches() before reparenting,
we'll have shrunk a lot of the pending caches, and we will have less
pages to reparent. But we only reparent pages in the lru anyway, and
then expect kmem and remaining umem to match. So *in theory* it should
be fine.
Where can I grab your final tree so I can test it and make sure it is
all good ?
--
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: kernel BUG at fs/lockd/mon.c:150, was Re: [PATCH v2 3/3] lockd: create and ...
On 30-10-12 14:04, Kees Bakker wrote: On 18-09-12 11:37, Stanislav Kinsbursky wrote: NSM RPC client can be required on NFSv3 umount, when child reaper is dying (and destroying it's mount namespace). It means, that current nsproxy is set to NULL already, but creation of RPC client requires UTS namespace for gaining hostname string. This patch creates reference-counted per-net NSM client on first monitor request and destroys it after last unmonitor request. We're hitting the BUG_ON that was added in this patch. I've tried it with 3.6.3 and 3.6.4 It happens almost immediate when I do apt-get update (the archive is on NFS). To follow up (just talking to myself I guess), stable v3.6.5 solves the problem, thanks. I did try v3.6.4 first but the patch inthere was not sufficient. -- Kees -- 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/
sysfs crashes while recursively checking file permissions
Hi, I am running one test on my ARM system which checks the sysfs file system's whole directory recursively and checks its file permission. While I perform this test, I face random (as in varies the nature of crash sometimes) crashes like one mentioned below. <1>[ 67.442660] Unable to handle kernel paging request at virtual address efd3d794 <1>[ 67.448840] pgd = da364000 <1>[ 67.451529] [efd3d794] *pgd= <0>[ 67.455092] Internal error: Oops: 5 [#1] PREEMPT SMP ARM <4>[ 67.460385] Modules linked in: <4>[ 67.463424] CPU: 1Not tainted (3.4.0-perf-g45c04fe-6-g8a5c5e2 #27) <4>[ 67.470382] PC is at rb_next+0x38/0x60 <4>[ 67.474103] LR is at sysfs_readdir+0x1f8/0x288 <4>[ 67.478528] pc : []lr : []psr: a013 <4>[ 67.478532] sp : d90adf10 ip : 0078 fp : 000b <4>[ 67.489984] r10: 4a0e r9 : 0004 r8 : <4>[ 67.495193] r7 : dbea2e00 r6 : r5 : db9385c0 r4 : d8ada0c0 <4>[ 67.501704] r3 : efd3d790 r2 : efd3d790 r1 : db9385d0 r0 : dbea2e50 <4>[ 67.508216] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user <4>[ 67.515333] Control: 10c5787d Table: 5a56406a DAC: 0015 <4>[ 67.521061] <4>[ 67.521063] PC: 0xc02f7bd0: <4>[ 67.525313] 7bd0 e152 05813008 15813004 e5902008 e352 15921000 12011003 11831001 <4>[ 67.533473] 7bf0 15821000 e5902004 e352 15921000 12011003 11831001 15821000 e897 <4>[ 67.541632] 7c10 e8830007 e12fff1e e5903000 e3c33003 e153 03a03000 0a10 e5903004 <4>[ 67.549791] 7c30 e353 1a0a ea00 e1a2 e5902000 e3c22003 e2523000 0a07 <4>[ 67.557951] 7c50 e5921004 e151 0af7 ea03 e1a03002 e5932008 e352 1afb <4>[ 67.566112] 7c70 e1a3 e12fff1e e92d4010 e1a04000 e5903004 e5902008 e353 1a03 <4>[ 67.574271] 7c90 e2523000 05903000 03c33003 ea0b e352 0a09 ebda e5902004 <4>[ 67.582430] 7cb0 e1a03000 e352 11a03002 1a03 e5932000 e3c22003 e1540002 11a03002 <4>[ 67.590592] <4>[ 67.590594] LR: 0xc01c1f68: <4>[ 67.594844] 1f68 e2833001 e1852f93 e332 1afa e59f00ec e5845078 eb16e059 e1c422d8 <4>[ 67.603003] 1f88 e1a01008 e58da008 e58d600c e1cd20f0 e1a0200b e59d3024 e58d9010 e59d0020 <4>[ 67.611163] 1fa8 e12fff33 e1a08000 e59f00b4 eb16e0fe e358 ba15 e5942028 e1a01007 <4>[ 67.619323] 1fc8 e59d001c e3a03000 e58d5000 eb33 e2505000 0a0d e2850010 eb04d70b <4>[ 67.627483] 1fe8 e350 0a05 e5903010 e2405010 e59d101c e1530001 1af6 ea01 <4>[ 67.635643] 2008 e1a05000 ea01 e355 1abf e59f004c eb16e032 e1c422d8 e3520002 <4>[ 67.643803] 2028 e2d31000 b3a03000 a3a03001 e355 13a05000 02035001 e355 13a03000 <4>[ 67.651963] 2048 13e02102 11c422f8 13a03000 15843078 e3a0 e28dd02c e8bd8ff0 c09e096e <4>[ 67.660123] <4>[ 67.660125] SP: 0xd90ade90: <4>[ 67.664376] de90 0007 205bdf78 37362020 3234342e 5d363436 d90a0020 d90ac000 c016f80c <4>[ 67.672535] deb0 d90adebc c02f7c50 a013 d90adefc c077ca58 dbea2e50 db9385d0 <4>[ 67.680694] ded0 efd3d790 efd3d790 d8ada0c0 db9385c0 dbea2e00 0004 <4>[ 67.688854] def0 4a0e 000b 0078 d90adf10 c01c1fe8 c02f7c50 a013 <4>[ 67.697014] df10 db9385c0 4a0e 0004 dbe02480 <4>[ 67.705175] df30 d90adf80 c0172598 d8d87f08 d8ada0c0 dbdbe068 c0172598 dbdbe000 <4>[ 67.713334] df50 d90ac000 d90adf80 cb6c c017282c 83068137 420670d0 1068 <4>[ 67.721493] df70 d8ada0c0 c000e068 c01729b4 420671e0 420671c0 0f58 ffea <4>[ 67.729654] <4>[ 67.729656] R0: 0xdbea2dd0: <4>[ 67.733907] 2dd0 dbe98300 daaf9b10 dbebb1d0 2c53e300 c0c69208 0003 <4>[ 67.742067] 2df0 dbea2f50 40ed0001 01e3 0012 dbe30c40 dbea2dc0 <4>[ 67.750226] 2e10 dbe98391 daad60d0 dbebb210 2c53e300 c0c69208 0003 <4>[ 67.758385] 2e30 dbea2f90 41ed0001 01e3 0003 dbea2e00 c0a10df6 <4>[ 67.766547] 2e50 efd3d791 db9385d0 db938010 57c6bb9d c0c9c8a4 <4>[ 67.774706] 2e70 81a40002 01e4 0001 efd3d600 c09cd4b0 <4>[ 67.782865] 2e90 dbea2f91 db937e10 dbea4010 27692f8b c0c9cb78 <4>[ 67.791024] 2eb0 81240002 01e5 5f6d736d 5f6d6163 76726573 302e7265 <4>[ 67.799185] <4>[ 67.799187] R1: 0xdb938550: <4>[ 67.803439] 8550 <4>[ 67.811598] 8570 65646976 696c346f 0078756e <4>[ 67.819758] 8590 0080 <4>[ 67.827916] 85b0 000
Re: [PATCH v6 11/29] memcg: allow a memcg with kmem charges to be destructed.
On 11/02/2012 04:05 AM, Andrew Morton wrote:
> On Thu, 1 Nov 2012 16:07:27 +0400
> Glauber Costa wrote:
>
>> Because the ultimate goal of the kmem tracking in memcg is to track slab
>> pages as well, we can't guarantee that we'll always be able to point a
>> page to a particular process, and migrate the charges along with it -
>> since in the common case, a page will contain data belonging to multiple
>> processes.
>>
>> Because of that, when we destroy a memcg, we only make sure the
>> destruction will succeed by discounting the kmem charges from the user
>> charges when we try to empty the cgroup.
>
> There was a significant conflict with the sched/numa changes in
> linux-next, which I resolved as below. Please check it.
>
> static int mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
> {
> struct cgroup *cgrp = memcg->css.cgroup;
> int node, zid;
> u64 usage;
>
> do {
> if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children))
> return -EBUSY;
> /* This is for making all *used* pages to be on LRU. */
> lru_add_drain_all();
> drain_all_stock_sync(memcg);
> mem_cgroup_start_move(memcg);
> for_each_node_state(node, N_HIGH_MEMORY) {
> for (zid = 0; zid < MAX_NR_ZONES; zid++) {
> enum lru_list lru;
> for_each_lru(lru) {
> mem_cgroup_force_empty_list(memcg,
> node, zid, lru);
> }
> }
> }
> mem_cgroup_end_move(memcg);
> memcg_oom_recover(memcg);
> cond_resched();
>
> /*
>* Kernel memory may not necessarily be trackable to a specific
>* process. So they are not migrated, and therefore we can't
>* expect their value to drop to 0 here.
>* Having res filled up with kmem only is enough.
>*
>* This is a safety check because mem_cgroup_force_empty_list
>* could have raced with mem_cgroup_replace_page_cache callers
>* so the lru seemed empty but the page could have been added
>* right after the check. RES_USAGE should be safe as we always
>* charge before adding to the LRU.
>*/
> usage = res_counter_read_u64(&memcg->res, RES_USAGE) -
> res_counter_read_u64(&memcg->kmem, RES_USAGE);
> } while (usage > 0);
>
> return 0;
> }
>
Andrew,
It looks fine.
One thing: Open code reading makes very difficult to spot which exactly
the conflict is. Any chance you could send those in some kind of diff
format?
In this case, it appears to me that the reason for the conflict is that
the loop conditional "while (usage > 0 || ret)" was changed to "while
(usage > 0)". Being this the case, and because kmemcg has no business
with that "ret" value, this resolution is appropriate.
--
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: gdm72xx: wm_ioctl.h: fixed a macro coding style
On Fri, Nov 02, 2012 at 12:36:30AM -0700, Kumar amit mehta wrote: > On Fri, Nov 02, 2012 at 09:55:55AM +0300, Dan Carpenter wrote: > > On Thu, Nov 01, 2012 at 11:42:59PM -0700, Kumar Amit Mehta wrote: > > > fix for macro coding style. > > > > > > > No. The parenthesis are not needed. I assume this is a > > checkpatch.pl warning? > > > > regards, > > dan carpenter > > > Running checkpatch.pl on this file (wm_ioctl.h) returns error. > I think there are patches which fix checkpatch.pl for this but they haven't been merged yet? $ ./scripts/checkpatch.pl -f drivers/staging/gdm72xx/wm_ioctl.h ERROR: Macros with complex values should be enclosed in parenthesis #94: FILE: staging/gdm72xx/wm_ioctl.h:94: +#define ifr_name ifr_ifrn.ifrn_name total: 1 errors, 0 warnings, 97 lines checked regards, dan carpenter -- 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 v4 3/3] ARM: OMAP: ocp2scp: create omap device for ocp2scp
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/devices.c | 79 +
1 file changed, 79 insertions(+)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cba60e0..c72b5a7 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
@@ -613,6 +614,83 @@ static void omap_init_vout(void)
static inline void omap_init_vout(void) {}
#endif
+#if defined(CONFIG_OMAP_OCP2SCP) || defined(CONFIG_OMAP_OCP2SCP_MODULE)
+static int count_ocp2scp_devices(struct omap_ocp2scp_dev *ocp2scp_dev)
+{
+ int cnt = 0;
+
+ while (ocp2scp_dev->drv_name != NULL) {
+ cnt++;
+ ocp2scp_dev++;
+ }
+
+ return cnt;
+}
+
+static void omap_init_ocp2scp(void)
+{
+ struct omap_hwmod *oh;
+ struct platform_device *pdev;
+ int bus_id = -1, dev_cnt = 0, i;
+ struct omap_ocp2scp_dev *ocp2scp_dev;
+ const char *oh_name, *name;
+ struct omap_ocp2scp_platform_data *pdata;
+
+ if (!cpu_is_omap44xx())
+ return;
+
+ oh_name = "ocp2scp_usb_phy";
+ name= "omap-ocp2scp";
+
+ oh = omap_hwmod_lookup(oh_name);
+ if (!oh) {
+ pr_err("%s: could not find omap_hwmod for %s\n", __func__,
+ oh_name);
+ return;
+ }
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ pr_err("%s: No memory for ocp2scp pdata\n", __func__);
+ return;
+ }
+
+ ocp2scp_dev = oh->dev_attr;
+ dev_cnt = count_ocp2scp_devices(ocp2scp_dev);
+
+ if (!dev_cnt) {
+ pr_err("%s: No devices connected to ocp2scp\n", __func__);
+ kfree(pdata);
+ return;
+ }
+
+ pdata->devices = kzalloc(sizeof(struct omap_ocp2scp_dev *)
+ * dev_cnt, GFP_KERNEL);
+ if (!pdata->devices) {
+ pr_err("%s: No memory for ocp2scp pdata devices\n", __func__);
+ kfree(pdata);
+ return;
+ }
+
+ for (i = 0; i < dev_cnt; i++, ocp2scp_dev++)
+ pdata->devices[i] = ocp2scp_dev;
+
+ pdata->dev_cnt = dev_cnt;
+
+ pdev = omap_device_build(name, bus_id, oh, pdata, sizeof(*pdata), NULL,
+ 0, false);
+ if (IS_ERR(pdev)) {
+ pr_err("Could not build omap_device for %s %s\n",
+ name, oh_name);
+ kfree(pdata->devices);
+ kfree(pdata);
+ return;
+ }
+}
+#else
+static inline void omap_init_ocp2scp(void) { }
+#endif
+
/*-*/
static int __init omap2_init_devices(void)
@@ -640,6 +718,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_ocp2scp();
return 0;
}
--
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 v4 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
is assigned a device attribute to represent the attached devices.
Signed-off-by: Kishon Vijay Abraham I
Cc: Benoit Cousson
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..cf579b5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2681,6 +2682,32 @@ static struct omap_hwmod_class
omap44xx_ocp2scp_hwmod_class = {
.sysc = &omap44xx_ocp2scp_sysc,
};
+/* ocp2scp dev_attr */
+static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
+ {
+ .name = "usb_phy",
+ .start = 0x4a0ad080,
+ .end= 0x4a0ae000,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* XXX: Remove this once control module driver is in place */
+ .name = "ctrl_dev",
+ .start = 0x4a002300,
+ .end= 0x4a002303,
+ .flags = IORESOURCE_MEM,
+ },
+ { }
+};
+
+static struct omap_ocp2scp_dev ocp2scp_dev_attr[] = {
+ {
+ .drv_name = "omap-usb2",
+ .res= omap44xx_usb_phy_and_pll_addrs,
+ },
+ { }
+};
+
/* ocp2scp_usb_phy */
static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod = {
.name = "ocp2scp_usb_phy",
@@ -2694,6 +2721,7 @@ static struct omap_hwmod omap44xx_ocp2scp_usb_phy_hwmod =
{
.modulemode = MODULEMODE_HWCTRL,
},
},
+ .dev_attr = ocp2scp_dev_attr,
};
/*
--
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 v4 0/3] ocp2scp: add non-dt support
This patch series allows ocp2scp driver to create its child devices from the platform data. In omap platforms, usb phy is connected to ocp2scp and usb phy is needed for MUSB to be functional. When ocp2scp driver was added, it had only dt support which means it wont create usb phy devices for non-dt boot. This patch series adds non-dt support to ocp2scp and this series is needed for getting MUSB functional in non-dt boot. Changes from v3: used PLATFORM_DEVID_AUTO while creating a device using platform_device_alloc Changes from v2: *if cpu is not 44xx, dont create ocp2scp device in mach-omap2/devices.c Changes from v1: * Fixed Sergei's comments on memory leaks Kishon Vijay Abraham I (3): drivers: bus: ocp2scp: add pdata support ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy ARM: OMAP: ocp2scp: create omap device for ocp2scp arch/arm/mach-omap2/devices.c | 79 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 ++ drivers/bus/omap-ocp2scp.c | 68 ++-- include/linux/platform_data/omap_ocp2scp.h | 31 +++ 4 files changed, 203 insertions(+), 3 deletions(-) create mode 100644 include/linux/platform_data/omap_ocp2scp.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/
[PATCH v4 1/3] drivers: bus: ocp2scp: add pdata support
ocp2scp was not having pdata support which makes *musb* fail for non-dt
boot in OMAP platform. The pdata will have information about the devices
that is connected to ocp2scp. ocp2scp driver will now make use of this
information to create the devices that is attached to ocp2scp.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/bus/omap-ocp2scp.c | 68 ++--
include/linux/platform_data/omap_ocp2scp.h | 31 +
2 files changed, 96 insertions(+), 3 deletions(-)
create mode 100644 include/linux/platform_data/omap_ocp2scp.h
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index ff63560..0c48b0e 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -22,6 +22,26 @@
#include
#include
#include
+#include
+
+/**
+ * _count_resources - count for the number of resources
+ * @res: struct resource *
+ *
+ * Count and return the number of resources populated for the device that is
+ * connected to ocp2scp.
+ */
+static unsigned _count_resources(struct resource *res)
+{
+ int cnt = 0;
+
+ while (res->start != res->end) {
+ cnt++;
+ res++;
+ }
+
+ return cnt;
+}
static int ocp2scp_remove_devices(struct device *dev, void *c)
{
@@ -34,20 +54,62 @@ static int ocp2scp_remove_devices(struct device *dev, void
*c)
static int __devinit omap_ocp2scp_probe(struct platform_device *pdev)
{
- int ret;
- struct device_node *np = pdev->dev.of_node;
+ int ret;
+ unsigned res_cnt, i;
+ struct device_node *np = pdev->dev.of_node;
+ struct platform_device *pdev_child;
+ struct omap_ocp2scp_platform_data *pdata = pdev->dev.platform_data;
+ struct omap_ocp2scp_dev *dev;
if (np) {
ret = of_platform_populate(np, NULL, NULL, &pdev->dev);
if (ret) {
- dev_err(&pdev->dev, "failed to add resources for
ocp2scp child\n");
+ dev_err(&pdev->dev,
+ "failed to add resources for ocp2scp child\n");
goto err0;
}
+ } else if (pdata) {
+ for (i = 0, dev = *pdata->devices; i < pdata->dev_cnt; i++,
+ dev++) {
+ res_cnt = _count_resources(dev->res);
+
+ pdev_child = platform_device_alloc(dev->drv_name,
+ PLATFORM_DEVID_AUTO);
+ if (!pdev_child) {
+ dev_err(&pdev->dev,
+ "failed to allocate mem for ocp2scp child\n");
+ goto err0;
+ }
+
+ ret = platform_device_add_resources(pdev_child,
+ dev->res, res_cnt);
+ if (ret) {
+ dev_err(&pdev->dev,
+"failed to add resources for ocp2scp child\n");
+ goto err1;
+ }
+
+ pdev_child->dev.parent = &pdev->dev;
+
+ ret = platform_device_add(pdev_child);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "failed to register ocp2scp child device\n");
+ goto err1;
+ }
+ }
+ } else {
+ dev_err(&pdev->dev, "OCP2SCP initialized without plat data\n");
+ return -EINVAL;
}
+
pm_runtime_enable(&pdev->dev);
return 0;
+err1:
+ platform_device_put(pdev_child);
+
err0:
device_for_each_child(&pdev->dev, NULL, ocp2scp_remove_devices);
diff --git a/include/linux/platform_data/omap_ocp2scp.h
b/include/linux/platform_data/omap_ocp2scp.h
new file mode 100644
index 000..5c6c393
--- /dev/null
+++ b/include/linux/platform_data/omap_ocp2scp.h
@@ -0,0 +1,31 @@
+/*
+ * omap_ocp2scp.h -- ocp2scp header file
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * Author: Kishon Vijay Abraham I
+ *
+ * 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.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_OCP2SCP_H
+#define __DRIVERS_OMAP_OCP2SCP_H
+
+struct omap_ocp2scp_dev {
+ const char *drv_name;
+ struct resource *res;
+};
+
+struct omap_ocp2scp_platform_data {
+ int
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On 11/1/2012 1:00 PM, Koen Kooi wrote: tl;dr: please suggest an actual solution that allows plug&play when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" het volgende geschreven: Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = "disabled" for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever
Re: [patch] x86, xen: fix build dependency when USB_SUPPORT is not enabled
>>> On 01.11.12 at 23:05, Konrad Rzeszutek Wilk wrote: > On Thu, Nov 01, 2012 at 08:04:58PM +, Jan Beulich wrote: >> >>> Konrad Rzeszutek Wilk 11/01/12 1:49 PM >>> >> >On Wed, Oct 31, 2012 at 10:42:30PM -0700, David Rientjes wrote: >> >> CONFIG_XEN_DOM0 must depend on CONFIG_USB_SUPPORT, otherwise there is no >> >> definition of xen_dbgp_reset_prep() and xen_dbgp_external_startup() >> >> resulting in the following link error: >> >> >> >> drivers/built-in.o: In function `dbgp_reset_prep': >> >> (.text+0x1e03c5): undefined reference to `xen_dbgp_reset_prep' >> >> drivers/built-in.o: In function `dbgp_external_startup': >> >> (.text+0x1e0d55): undefined reference to `xen_dbgp_external_startup' >> > >> >There is another patch that needs to be Acked and picked up by >> >Greg KH that fixes this. >> > >> >Let me poke Jan Beulich to repost it with the appropiate Acks. >> >> It's been picked up already, but another dependency problem was found with >> it (due to not having used CONFIG_USB_SUPPORT as dependency, as I had >> first submitted). > > Oh. I missed that part - so do you think that this patch should also > be used? Or do you think there is another way to fix this? > > I am in transit right now so I can't prep a patch (and the laptop I've > is extremely slow to even do a test compile). Alan and I settled on relaxing the condition in ehci-dbgp.c to IS_ENABLED(USB). But it's not clear to me if I should send an incremental patch or a replacement one (neither he nor Greg answered my respective inquiry). Jan -- 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 v4 1/3] zsmalloc: promote to lib/
On Fri, Nov 2, 2012 at 9:12 AM, Minchan Kim wrote: > This patch promotes the slab-based zsmalloc memory allocator > from the staging tree to lib/ > > zcache/zram depends on this allocator for storing compressed RAM pages > in an efficient way under system wide memory pressure where > high-order (greater than 0) page allocation are very likely to > fail. > > For more information on zsmalloc and its internals, read the > documentation at the top of the zsmalloc.c file. > > Signed-off-by: Minchan Kim Acked-by: Pekka Enberg -- 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 v4 3/3] zram: select ZSMALLOC when ZRAM is configured
On Fri, Nov 2, 2012 at 9:12 AM, Minchan Kim wrote: > At the monent, we can configure zram in driver/block once zsmalloc > in /lib menu is configured firstly. It's not convenient. > > User can configure zram in driver/block regardless of zsmalloc enabling > by this patch. > > Signed-off-by: Minchan Kim Acked-by: Pekka Enberg -- 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 00/29] kmem controller for memcg.
On Fri, Nov 2, 2012 at 2:04 AM, Andrew Morton wrote: > One thing: > >> Numbers can be found at https://lkml.org/lkml/2012/9/13/239 > > You claim in the above that the fork worload is 'slab intensive". Or > at least, you seem to - it's a bit fuzzy. > > But how slab intensive is it, really? > > What is extremely slab intensive is networking. The networking guys > are very sensitive to slab performance. If this hasn't already been > done, could you please determine what impact this has upon networking? > I expect Eric Dumazet, Dave Miller and Tom Herbert could suggest > testing approaches. IIRC, networking guys have reduced their dependency on slab performance recently. Few simple benchmarks to run are hackbench, netperf, and Christoph's famous microbenchmarks. The sad reality is that you usually have to wait for few release cycles before people notice that you've destroyed performance of their favourite workload. :-/ -- 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 0/3] capebus moving omap_devices to mach-omap2
Hi Benoit, On Nov 2, 2012, at 10:15 AM, Cousson, Benoit wrote: > On 11/1/2012 1:00 PM, Koen Kooi wrote: >> tl;dr: please suggest an actual solution that allows plug&play when plugging >> in multiple capes and applying power after that. Preferably one that doesn't >> pass the buck to u-boot. >> >> Op 1 nov. 2012, om 12:26 heeft "Cousson, Benoit" het >> volgende geschreven: >> >>> Hi Panto, >>> >>> On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: > On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: >> Hi Felibe, >> >> On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: >> >>> Hi, >>> >>> On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: > * Pantelis Antoniou [121031 13:14]: >> On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: >>> >>> Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM >>> control >>> could have an hwmod and thus must be handled by an omap_device. >>> >>> Any devices that is created later cannot be omap_device. The DT core >>> will create regular platform_device for them. >>> >>> Since cape is an external board, it should have nothing to do with >>> omap_device. >>> >>> Looking at your patch: >>> da8xx-dt: Create da8xx DT adapter device >>> >>> I understand why you do that, but in fact that patch does not make >>> sense >>> to me :-( >>> >>> Why do you have to create an omap_device from the driver probe? >>> >> >> The problem is that capes are not external boards in the normal sense >> as a PCI board is. In the PCI case the hardware that implements the >> desired functionality is on the PCI board, while in the cape case the >> hardware module is in the SoC. The cape most of the times is quite >> simple and contains passive components, leds or some kind of I2C/SPI >> devices. > > Ah now I see, you're talking about the beaglebone extension > boards :) > > The way to deal with those properly is to just edit the > board .dts entry to include omap-beaglebone-cape-xyz.dtsi > whatever. > That is what is being done... This is the fallout. >> You can't instantiate the omap_device early in the boot process like >> it was done up to >> now in the board file. You can only do that later in the boot >> process (for built-in >> cape drivers), or even after user-space has booted and the matching >> cape driver module >> has been loaded. > > Yes you can, just edit the .dts file for the extension > board you have connected. This stuff should be DT > only for sure, let's not even start adding platform_data > entries for that. > > The omap_device entries for the omap internal devices > will be created automatically during startup based on the > .dts. Note that you can set status = "disabled" for the > omap internal devices in the .dts file, the devices are > there in the hardware. > > If you are sure the extension boards are safely hot > pluggable, then all you need is some interface to enable > and disable devices after booting. But that should be > done in Linux generic way. > > So we should not export any omap_hwmod or omap_device > things, and want to keep it __init only, and local to > arch/arm/mach-omap2. > I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. >>> >>> when you have an actual bus, that'd be correct. >> >> What do you think capebus is? It is an actual bus that allows you >> to do so. >> >>> We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. >>> >>> why this requirement of instantiating them only after reading EEPROMs ? >>> >>> It's unnecessary to add that requirement, just do what Tony said >>> (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices >>> should be created automatically. >>> >>> The thing is that there is no such thing as a cape-device. The cape is >>> just a collection of I2C, 1-wire and SPI devices anyway. What we should >
[PATCH] staging/media: Use dev_ printks in cxd2099/cxd2099.[ch]
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
pr_warn(... to printk(KERN_WARNING ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/media/cxd2099/cxd2099.c | 29 +++--
drivers/staging/media/cxd2099/cxd2099.h |2 +-
2 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 0ff1972..822c487 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -66,8 +66,9 @@ static int i2c_write_reg(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, .len = 2};
if (i2c_transfer(adapter, &msg, 1) != 1) {
- printk(KERN_ERR "Failed to write to I2C register %02x@%02x!\n",
- reg, adr);
+ dev_err(&adapter->dev,
+ "Failed to write to I2C register %02x@%02x!\n",
+ reg, adr);
return -1;
}
return 0;
@@ -79,7 +80,7 @@ static int i2c_write(struct i2c_adapter *adapter, u8 adr,
struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = data, .len = len};
if (i2c_transfer(adapter, &msg, 1) != 1) {
- printk(KERN_ERR "Failed to write to I2C!\n");
+ dev_err(&adapter->dev, "Failed to write to I2C!\n");
return -1;
}
return 0;
@@ -94,7 +95,7 @@ static int i2c_read_reg(struct i2c_adapter *adapter, u8 adr,
.buf = val, .len = 1} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- printk(KERN_ERR "error in i2c_read_reg\n");
+ dev_err(&adapter->dev, "error in i2c_read_reg\n");
return -1;
}
return 0;
@@ -109,7 +110,7 @@ static int i2c_read(struct i2c_adapter *adapter, u8 adr,
.buf = data, .len = n} };
if (i2c_transfer(adapter, msgs, 2) != 2) {
- printk(KERN_ERR "error in i2c_read\n");
+ dev_err(&adapter->dev, "error in i2c_read\n");
return -1;
}
return 0;
@@ -277,7 +278,7 @@ static void cam_mode(struct cxd *ci, int mode)
#ifdef BUFFER_MODE
if (!ci->en.read_data)
return;
- printk(KERN_INFO "enable cam buffer mode\n");
+ dev_info(&ci->i2c->dev, "enable cam buffer mode\n");
/* write_reg(ci, 0x0d, 0x00); */
/* write_reg(ci, 0x0e, 0x01); */
write_regm(ci, 0x08, 0x40, 0x40);
@@ -524,7 +525,7 @@ static int slot_reset(struct dvb_ca_en50221 *ca, int slot)
msleep(10);
#if 0
read_reg(ci, 0x06, &val);
- printk(KERN_INFO "%d:%02x\n", i, val);
+ dev_info(&ci->i2c->dev, "%d:%02x\n", i, val);
if (!(val&0x10))
break;
#else
@@ -542,7 +543,7 @@ static int slot_shutdown(struct dvb_ca_en50221 *ca, int
slot)
{
struct cxd *ci = ca->data;
- printk(KERN_INFO "slot_shutdown\n");
+ dev_info(&ci->i2c->dev, "slot_shutdown\n");
mutex_lock(&ci->lock);
write_regm(ci, 0x09, 0x08, 0x08);
write_regm(ci, 0x20, 0x80, 0x80); /* Reset CAM Mode */
@@ -578,10 +579,10 @@ static int campoll(struct cxd *ci)
if (istat&0x40) {
ci->dr = 1;
- printk(KERN_INFO "DR\n");
+ dev_info(&ci->i2c->dev, "DR\n");
}
if (istat&0x20)
- printk(KERN_INFO "WC\n");
+ dev_info(&ci->i2c->dev, "WC\n");
if (istat&2) {
u8 slotstat;
@@ -597,7 +598,7 @@ static int campoll(struct cxd *ci)
if (ci->slot_stat) {
ci->slot_stat = 0;
write_regm(ci, 0x03, 0x00, 0x08);
- printk(KERN_INFO "NO CAM\n");
+ dev_info(&ci->i2c->dev, "NO CAM\n");
ci->ready = 0;
}
}
@@ -634,7 +635,7 @@ static int read_data(struct dvb_ca_en50221 *ca, int slot,
u8 *ebuf, int ecount)
campoll(ci);
mutex_unlock(&ci->lock);
- printk(KERN_INFO "read_data\n");
+ dev_info(&ci->i2c->dev, "read_data\n");
if (!ci->dr)
return 0;
@@ -687,7 +688,7 @@ struct dvb_ca_en50221 *cxd2099_attach(struct cxd2099_cfg
*cfg,
u8 val;
if (i2c_read_reg(i2c, cfg->adr, 0, &val) < 0) {
- printk(KERN_INFO "No CXD2099 detected at %02x\n", cfg->adr);
+
Re: [RFC] Second attempt at kernel secure boot support
Matthew Garrett writes: > On Thu, Nov 01, 2012 at 09:58:17PM +, Alan Cox wrote: >> On Thu, 1 Nov 2012 21:34:52 + >> Matthew Garrett wrote: >> > I think you've misunderstood. Blacklist updates are append only. >> >> I think you've misunderstood - thats a technical detail that merely >> alters the cost to the people who did something improper. > > Winning a case is cold comfort if your software has been uninstallable > for the years it took to get through the courts. If others want to take > that risk, fine. When the goal is to secure Linux I don't see how any of this helps. Windows 8 compromises are already available so if we turn most of these arguments around I am certain clever attackers can go through windows to run compromised kernel on a linux system, at least as easily as the reverse. Short of instructing UEFI to stop trusting the Microsoft signing key I don't see any of the secureboot dance gaining any security of computers running linux or security from keys being revoked for non-sense reasons. Eric -- 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 v1 1/2] mfd: i2c issue fix for DA9052/53 and support for DA9053-BC
On Thu, 2012-11-01 at 14:31 +, Mark Brown wrote: > On Thu, Nov 01, 2012 at 11:48:42AM +0530, Ashish Jangam wrote: > > > This patch fixes this issue to by following any read or write with a dummy > > read > > to a safe register address. A safe register address is one where the > > contents > > will not affect the operation of the system. > > > Apart from this the patch also adds support to the DA9053-BC PMIC chip > > This is two separate changes and so should be two separate patches (one > is a bugfix and one isn't...). I merged these two changes since I2C fix has got some dependency on DA9053-BC PMIC. But I can separate out the things, its better. -- 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] namespace:unmount pid_namespace's proc_mnt when copy_net_ns failed
Gao feng writes: > 于 2012年11月02日 15:02, Eric W. Biederman 写道: >> Gao feng writes: >> >>> we should call pid_ns_release_proc to unmount pid_namespace's >>> proc_mnt when copy_net_ns failed in function create_new_namespaces. >>> >>> otherwise,the proc_mnt will not be freed and because the super_block >>> of proc_mnt also add the reference of the pid_namespace,so this >>> pid_namespace will never be released too. >> >> Ouch! >> >> Have you encountered this failure in practice or is this just from >> review? > > I add some printk in pid_ns_release_proc,it's not called in above case. > when copy_net_ns failed,this pid_namespace is not used by any task, > so proc_flush_task can't call pid_ns_release_proc to umount this > pidns->proc_mnt. > it's the only chance we can unmount this pindns->proc_mnt. > > With this patch,everything runs well. I have reviewed the code and I don't doubt that this is necessary. What caused you to look into this failure? Is there some semi-practical real world case that someone is hitting? Eric -- 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] Devfreq: Add debugfs node for representing frequency transition information
This patch adds debugfs node to measure transition of frequency on runtime.
It will be creted under '/sys/kernel/debugfs/devfreq/'dev name'/' as the name
of 'trans_table'. It contains number of transition of each frequency level,
time spent on each level, and also total transition count.
It inspired by CPUFREQ's cpufreq_stats method.
=
time spent
* n12 n13 t1
n21 n23 t2
n31 n32 t3
Total transition : N (= n12 + n13 + n21 + n23 + n31 + n32)
==
(n12 : Number of transition from level 1 to level 2)
('*' : The last changed frequency when you inspect the node.)
This patch also includes documentation.
Signed-off-by: Jonghwa Lee
---
Documentation/devfreq/transition_status_table | 265 +
drivers/devfreq/devfreq.c | 123
include/linux/devfreq.h | 23 +++
3 files changed, 411 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devfreq/transition_status_table
diff --git a/Documentation/devfreq/transition_status_table
b/Documentation/devfreq/transition_status_table
new file mode 100644
index 000..8b92391
--- /dev/null
+++ b/Documentation/devfreq/transition_status_table
@@ -0,0 +1,265 @@
+DEVFREQ Transition status table
+=
+
+Copyright (C) 2012 Samsung Electronics
+
+Written by Jonghwa Lee
+
+1. Description
+
+
+DEVFREQ Transition status table represents all of transition information up to
now. Transition information
+includes number of transition which has been occured and time spent on the
each of frequencies.
+This implementation is ispired by CPUFREQ's cpufreq_stats method.
+
+
+
+ time spent
+
+* Number of transitionNumber
of transition t1
+ from freq1 to freq2 from
freq1 to freq3
+
+Number of transitionNumber
of transition t2
+ from freq2 to freq1 from
freq2 to freq3
+
+Number of transitionNumber of transition
t3
+ from freq3 to freq1 from freq3 to freq2
+
+Total transition : N
+=
+('*' : The last changed frequency when you inspect the node.)
+
+It may be used for measuring performance or debug use.
+
+
+2. Requirement to use
+---
+
+There is no kernel configuration option for creating this node at this moment.
Only CONFIG_DEBUG_FS is required.
+It will be created automatically when devfreq device created successfully.
+(under /sys/kernel/debug/devfreq/'each devfreq device name'/ by the name of
'trans_table'.)
+
+By the way, it's going to show nothing unless you go through the below steps.
+To show appropriate information about frequency transition, each devfreq
device must hand over their own list of
+available frequency and total count of frequency levels to the framework.
Because at the devfreq core side,
+system doesn't know how many freqeuncy levels are available and what value of
each level exactly is.
+In devfreq_dev_profile structure, freq_list and freq_levs will play the role
carrying the those requirement data.
+
+To guarantee trans_table working, following two steps are required.
+(1) Initialize the freq_list of devfreq_dev_profile with all available
freqeuncy data
+(2) Initialize the freq_levs of devfreq_dev_profile with total number of
available freqeuncy level.
+
+3. Guage performance
+--
+
+This program is user space program that measures the frequency transition
during the certain interval you set.
+When the program starts, it parses the trans_table contents and stores it for
later comparison at the end.
+And when you stop the gauging, the program will calculate transition
information happened during the interval given.
+The result is also formed like transition status table. However it can be used
for more specific purpose and usefully
+than trans_table itself. By analyzing its data, we can get an indicator of
performance of various situations or
+performance of governor and others also.
+
+HOW TO USE
+---
+1. Set the device name correctly in the code to the variable 'dev_name[]'
before the compile.
+ This will be used to get the path of debugfs node. (Default is
'exynos4412-busfreq').
+2. Run the program, and you'll see c
Re: [PATCH] fs: notify: Fix race condition between umount and inotify_rm_watch
2012/11/2, Al Viro : > On Fri, Nov 02, 2012 at 12:51:36AM +0900, Namjae Jeon wrote: >> When a user is monitoring an FS_UMOUNT watch using the inotify framework, >> there can be a potential race condition between the umount path & >> inotify_rm_watch. This scenario can be like- >> = >> user does the following calls- >> fd = inotify_init(); >> inotify_add_watch(path, IN_UNMOUNT); /* added a watch to path*/ >> read(fd); /* wait for the event */ >> inotify_rm_watch(); /* as soon as event came, remove the >> watch tag from the selected path */ >> >> Now as we trigger the umount command on the above mentioned path, >> it will trigger a fsnotification for all the waiting inotify watches, >> and then userspace will find that event came, it does the required >> action and remove the watch. >> Now while watch is being removed, there is possibility that umount >> process is still under execution & in not complete and on the other >> path inotify_rm_watch() will call an iput() on the watched inode, >> then there can be a race whether the inode's superblock is valid >> at that moment or its gone. >> So some time we end up in this race very badly and we try to access >> the super_block which now not in a valid memory and kernel dies. Trace >> is like shown below >> >> 138.892000] [] (do_raw_spin_trylock+0x0/0x54) from >> [] (__raw_spin_lock+0x34/0x90) >> [ 138.90] [] (__raw_spin_lock+0x0/0x90) from >> [] (_raw_spin_lock+0x18/0x1c) >> [ 138.908000] r5:00bc r4:e3db94f0 >> [ 138.912000] [] (_raw_spin_lock+0x0/0x1c) from >> [] (fat_detach+0x3c/0x80) >> [ 138.92] [] (fat_detach+0x0/0x80) from [] >> (fat_evict_inode+0x68/0x6c) >> [ 138.932000] r5:c0459cc0 r4:e3db94f0 >> [ 138.932000] [] (fat_evict_inode+0x0/0x6c) from >> [] (evict+0x94/0x154) >> [ 138.94] r4:e3db94f0 r3:c01e3cd8 >> [ 138.944000] [] (evict+0x0/0x154) from [] >> (iput+0x17c/0x18c) >> [ 138.952000] r5:e3db9504 r4:e3db94f0 >> [ 138.956000] [] (iput+0x0/0x18c) from [] >> (fsnotify_destroy_mark+0x15c/0x19c) >> [ 138.964000] r6:e3db94f0 r5:e3017540 r4:e41882a0 r3:271aed08 >> [ 138.972000] [] (fsnotify_destroy_mark+0x0/0x19c) from >> [] (sys_inotify_rm_watch+0x88/0xc0) >> [ 138.98] r8:c004aba8 r7:e3017540 r6:e41882a0 r5: >> r4:e3017300 >> [ 138.988000] r3: >> [ 138.988000] [] (sys_inotify_rm_watch+0x0/0xc0) from >> [] (ret_fast_syscall+0x0/0x30 >> >> So we can see inside the fat_detach function we are accessing illegal >> inode->i_sb->s_fs_info and we end up in above crash. >> >> To solve this race, we must have some sort of serialized access to >> superblock structure in umount path and fsnotification path. Now since >> the umount path takes an exclusive lock on s_umount of superblock. >> So if umount is in progress, this lock will not be free. >> >> Hence we may try to take a shared access to super block's s_umount lock >> inside the inotify_rm_watch() & if lock is free, means no one is doing >> write operation on this superblock. So we can then just go ahead and >> then before calling iput on the concerned inode, first we should check >> whether this inode's superblock is still valid( e.g s_count is >= 1) or >> not. >> So based on this condition we can choose our action and prevent the race. > Hi. Al. > NAK. The bug is real, but proposed fix is broken. AFAICS, your variant > is going to deadlock if watch removal request comes in the middle of > umount, > when ->s_umount has already been taken. I did not understand, how there would be dead lock between umount and inotify_rm_watch(). lets us suppose umount is inside the generic_shutdown_super() with holding s_count, and if in between inotify_rm_watch() comes, it will try to do a down_read(s_umount) and will be blocked until generic_shutdown_super exists and while exiting it will do up_write() and inotify_rm_watch() will get the lock. Please let me know if i am missing some thing here. > > Moreover, ->s_count doesn't do what you seem to think it does. If you ever > see a superblock with ->s_count being 0, you've already lost. It might've > been dereferencing already kfree()'d memory, for all you know. And yes, there might be a situation,that we might end up in dereferencing the kfree()'s memory, which is not good. Let me think more.. Thanks for review!. > -- 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] namespace:unmount pid_namespace's proc_mnt when copy_net_ns failed
于 2012年11月02日 16:54, Eric W. Biederman 写道: > Gao feng writes: > >> 于 2012年11月02日 15:02, Eric W. Biederman 写道: >>> Gao feng writes: >>> we should call pid_ns_release_proc to unmount pid_namespace's proc_mnt when copy_net_ns failed in function create_new_namespaces. otherwise,the proc_mnt will not be freed and because the super_block of proc_mnt also add the reference of the pid_namespace,so this pid_namespace will never be released too. >>> >>> Ouch! >>> >>> Have you encountered this failure in practice or is this just from >>> review? >> >> I add some printk in pid_ns_release_proc,it's not called in above case. >> when copy_net_ns failed,this pid_namespace is not used by any task, >> so proc_flush_task can't call pid_ns_release_proc to umount this >> pidns->proc_mnt. >> it's the only chance we can unmount this pindns->proc_mnt. >> >> With this patch,everything runs well. > > I have reviewed the code and I don't doubt that this is necessary. > > What caused you to look into this failure? Is there some semi-practical > real world case that someone is hitting? > So far,there is no case hitting this problem. 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 0/3] capebus moving omap_devices to mach-omap2
Hi, On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote: > On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote: > > HI, > > > > On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: > >> Hi Alan, > >> > >> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: > >> > >> >> What they want, and what every user wants, is I plug this board in, and > >> >> the driver make sure everything is loaded and ready. No, the end users > >> >> don't want to see any of the implementation details of how the bitfile > >> >> is transported; the driver can handle it. > >> > > >> > That doesn't necessarily make it a bus merely some kind of hotplug > >> > enumeration of devices. That should all work properly both for devices > >> > and busses with spi and i²c as the final bits needed for it got fixed > >> > some time ago. > >> > > >> > In an ideal world you don't want to be writing custom drivers for stuff. > >> > If your cape routes an i²c serial device to the existing system i²c > >> > busses then you want to just create an instance of any existing driver on > >> > the existing i²c bus not create a whole new layer of goop. > >> > > >> > It does need to do the plumbing and resource management for the plumbing > >> > but thats not the same as being a bus. > >> > > >> > Alan > >> > >> > >> Fair enough. But there's no such thing a 'hotplug enumeration > >> construct' in Linux yet, and a bus is the closest thing to it. It does > >> take advantage of the nice way device code matches drivers and devices > >> though. > >> > >> I'm afraid that having the I2C/SPI drivers doing the detection won't > >> work. The capes can have arbitrary I2C/SPI devices (and even more > >> weird components). There is no way to assure for example that the I2C > >> device responding to address 'foo' in cape A is the same I2C device > >> responding to the same address in cape B. > > > > your ->detect() method should take care of that. > > There isn't some magical serial number in I²C devices that a > ->detect() method can read and the implementation of I²C is somewhat > flexible. One devices read may be another devices write. A detect look at what other drivers do. You can read a revision register, you can write a command and see if the device responds as expected, it doesn't matter. > method that only performs reads could easily toggle a gpio that resets > the board, rewrite and eeprom, or set the printer on fire. If you how ? It's just a read. > browse through various detect functions, yes, some of them key off an > ID, but a lot of them just check various registers to see if certain > bits are zero, or certain bits are one. A lot of I²C devices I've > dealt with have no good way of probing them, especially GPIO chips > (you'll notice none of the I²C GPIO expanders have detect functions) it doesn't mean it can't be done. > On top of all this the detect routine does not tell you if the alert > pin is connected to some IRQ, or in the case of a GPIO expander, what > those GPIOs are connected to, etc, etc. so what ? All you want to do with detect is figure out if the far end is who you think it is, not what it's doing. -- balbi signature.asc Description: Digital signature
Re: [PATCH] namespace:unmount pid_namespace's proc_mnt when copy_net_ns failed
Gao feng writes: > 于 2012年11月02日 16:54, Eric W. Biederman 写道: >> Gao feng writes: >> >>> 于 2012年11月02日 15:02, Eric W. Biederman 写道: Gao feng writes: > we should call pid_ns_release_proc to unmount pid_namespace's > proc_mnt when copy_net_ns failed in function create_new_namespaces. > > otherwise,the proc_mnt will not be freed and because the super_block > of proc_mnt also add the reference of the pid_namespace,so this > pid_namespace will never be released too. Ouch! Have you encountered this failure in practice or is this just from review? >>> >>> I add some printk in pid_ns_release_proc,it's not called in above case. >>> when copy_net_ns failed,this pid_namespace is not used by any task, >>> so proc_flush_task can't call pid_ns_release_proc to umount this >>> pidns->proc_mnt. >>> it's the only chance we can unmount this pindns->proc_mnt. >>> >>> With this patch,everything runs well. >> >> I have reviewed the code and I don't doubt that this is necessary. >> >> What caused you to look into this failure? Is there some semi-practical >> real world case that someone is hitting? >> > > So far,there is no case hitting this problem. I think what I want to do is to push the changes in my userns development tree instead of solving it the way you have solved it. The way things are currently structured I don't think we can be certain of finding all of the corner cases. Would you be interesting in confirming that problem does not exist in my userns development branch? Eric -- 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 warning after merge of the usb tree
Hi,
On Fri, Nov 02, 2012 at 03:08:28PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the usb tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> WARNING: drivers/usb/host/ehci-hcd: 'ehci_init_driver' exported twice.
> Previous export was in drivers/usb/chipidea/ci_hdrc.ko
> WARNING: drivers/usb/host/ehci-hcd: 'ehci_resume' exported twice. Previous
> export was in drivers/usb/chipidea/ci_hdrc.ko
> WARNING: drivers/usb/host/ehci-hcd: 'ehci_suspend' exported twice. Previous
> export was in drivers/usb/chipidea/ci_hdrc.ko
> WARNING: drivers/usb/host/ehci-hcd: 'ehci_setup' exported twice. Previous
> export was in drivers/usb/chipidea/ci_hdrc.ko
>
> Introduced by commit 3e0232039967 ("USB: EHCI: prepare to make ehci-hcd a
> library module").
Alex, why on earth is chipidea exporting symbols it doesn't own ?
--
balbi
signature.asc
Description: Digital signature
[PATCH] staging: wlan-ng: hfa384x_usb.c: fixed a coding style issue
checkpatch.pl throws error message for the current code. This patch fixes
coding style issue.
Signed-off-by: Kumar Amit Mehta
---
drivers/staging/wlan-ng/hfa384x_usb.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/wlan-ng/hfa384x_usb.c
b/drivers/staging/wlan-ng/hfa384x_usb.c
index f180c3d..c1a8cb6 100644
--- a/drivers/staging/wlan-ng/hfa384x_usb.c
+++ b/drivers/staging/wlan-ng/hfa384x_usb.c
@@ -171,11 +171,11 @@ static void hfa384x_ctlxout_callback(struct urb *urb);
static void hfa384x_usbin_callback(struct urb *urb);
static void
-hfa384x_usbin_txcompl(wlandevice_t *wlandev, hfa384x_usbin_t * usbin);
+hfa384x_usbin_txcompl(wlandevice_t *wlandev, hfa384x_usbin_t *usbin);
static void hfa384x_usbin_rx(wlandevice_t *wlandev, struct sk_buff *skb);
-static void hfa384x_usbin_info(wlandevice_t *wlandev, hfa384x_usbin_t * usbin);
+static void hfa384x_usbin_info(wlandevice_t *wlandev, hfa384x_usbin_t *usbin);
static void
hfa384x_usbout_tx(wlandevice_t *wlandev, hfa384x_usbout_t *usbout);
@@ -285,7 +285,7 @@ static inline const char *ctlxstr(CTLX_STATE s)
return ctlx_str[s];
};
-static inline hfa384x_usbctlx_t *get_active_ctlx(hfa384x_t * hw)
+static inline hfa384x_usbctlx_t *get_active_ctlx(hfa384x_t *hw)
{
return list_entry(hw->ctlxq.active.next, hfa384x_usbctlx_t, list);
}
--
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 7/8] serial: xilinx_uartps: get clock rate info from dts
On 10/31/2012 08:28 PM, Josh Cartwright wrote:
> Add support for specifying clock information for the uart clk via the
> device tree. This eliminates the need to hardcode rates in the device
> tree.
>
> Signed-off-by: Josh Cartwright
> ---
> arch/arm/boot/dts/zynq-7000.dtsi | 4 ++--
> drivers/tty/serial/xilinx_uartps.c | 30 +-
> 2 files changed, 19 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm/boot/dts/zynq-7000.dtsi
> b/arch/arm/boot/dts/zynq-7000.dtsi
> index bb3085c..5fb763f 100644
> --- a/arch/arm/boot/dts/zynq-7000.dtsi
> +++ b/arch/arm/boot/dts/zynq-7000.dtsi
> @@ -44,14 +44,14 @@
> compatible = "xlnx,xuartps";
> reg = <0xE000 0x1000>;
> interrupts = <0 27 4>;
> - clock = <5000>;
> + clocks = <&uart_clk 0>;
> };
>
> uart1: uart@e0001000 {
> compatible = "xlnx,xuartps";
> reg = <0xE0001000 0x1000>;
> interrupts = <0 50 4>;
> - clock = <5000>;
> + clocks = <&uart_clk 0>;
Shouldn't this be <&uart_clk 1>?
> };
>
> slcr: slcr@f800 {
--
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 RESEND 1/5 v6] gpio: Add a block GPIO API to gpiolib
On 10/31/2012 07:59 PM, Grant Likely wrote: >> Pin direction currently needs to be set up separately, analogous to >> requesting gpios. Need to document this better, right. The assumption is >> that I/O needs to be efficient primarily, before bloating the API with >> direction functions. Or should I add functions for this? > > Since this is a userspace facing ABI, once it is merged it cannot be > changed in an incompatible way. I cannot merge it until there is at > least a plan for how to handle all of the reasonable use cases. That > means it must support set/clear or mask operations. Also, if it sticks > with the design of grouping pins from multiple controllers, then it > needs to handle explicitly constraining what order operations are > performed in at the time of the operation. At the time of setup > doesn't work since constraints between pins may not always be in the > same order. > > I really think you should consider implementing a command stream type > of interface. Yes, understand. What do you consider a good example of a command stream type interface? Link or hint appreciated! There was already mentioned the idea of a device node which can be interfaced to via ioctl() for the various operations. Can it be a "struct miscdevice" or do you require sth. more sophisticated? Thanks in advance, Roland -- 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/
[pull] drm-intel-next for 3.8
Hi Dave, Quite a pile since this is 4 weeks worth of patches: - tons of hsw dp prep patches form Paulo - round scheduled work items and timers to nearest second (Chris) - some hw workarounds (Jesse&Damien) - vlv dp support and related fixups (Vijay et al.) - basic haswell dp support, not yet wired up for external ports (Paulo) - edp support (Paulo) - tons of refactorings to prepare for the above (Paulo) - panel rework, unifiying code between lvds and edp panels (Jani) - panel fitter scaling modes (Jani + Yuly Novikov) - panel power improvements, should now work without the BIOS setting it up - extracting some dp helpers from radeon/i915 and move them to drm_dp_helper.c - randome pile of workarounds (Damien, Ben, ...) - some cleanups for the register restore code for suspend/resume - secure batchbuffer support, should enable tear-free blits on gen6+ (Chris) - random smaller fixlets and cleanups. For Haswell display support, this is not yet everything, big things still missing are: - hdmi/dp encoder unification, otherwise we can't enable non-eDP outputs - vga fixes (which essentially required forking all the fdi/pch code) Both are already in -next-queued, so for the next pull I plan to move Haswell out of experimental support. Note that this also contains a -rc2 backmerge, which I've botched up slightly:( Luckily Jani caught me and fixed things up, his patch is included on top of what QA beat on. For drm core stuff I have two series outstanding: - kerneldoc/DocBook patches demanded by Lauren Pinchart. Note that the last patch in that series depends upon the dp helper refactoring included in here. - relaunched hpd rework, requested&reviewed by Alex Deucher. Can you please look into slurping these into drm-next, too? Yours, Daniel The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel for-airlied for you to fetch changes up to c8241969b44438c9335b59d375b627214bc36483: drm/i915: pass adjusted_mode to intel_choose_pipe_bpp_dither(), again (2012-11-02 09:57:28 +0100) Adam Jackson (6): drm: Export drm_probe_ddc() drm/dp: Update DPCD defines drm/i915/dp: Fetch downstream port info if needed during DPCD fetch drm/i915/dp: Be smarter about connection sense for branch devices drm/dp: Document DP spec versions for various DPCD registers drm/dp: Make sink count DP 1.2 aware Ben Widawsky (3): drm/i915: Extract PCU communication drm/i915: Workaround to bump rc6 voltage to 450 drm/i915: Add rc6vids to debugfs Chris Wilson (5): drm/i915: Align the hangcheck wakeup to the nearest second drm/i915: Align the retire_requests worker to the nearest second drm/i915: Allow DRM_ROOT_ONLY|DRM_MASTER to submit privileged batchbuffers drm/i915: Document the multi-threaded FORCEWAKE bits drm/i915: Clear FORCEWAKE when taking over from BIOS Damien Lespiau (9): drm/i915: Remove the disabling of VHR unit clock gating for HSW drm/i915: Document that we are implementing WaDisableBackToBackFlipFix drm/i915: Remove the WaDisableBackToBackFlipFix w/a for Haswell drm/i915: Fix the SCC/SSC typo in the SPLL bits definition drm/i915: Consolidate ILK_DSPCLK_GATE and PCH_DSPCLK_GATE drm/i915: Program DSPCLK_GATE_D only once on Ironlake drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLV drm/i915: Don't try to use SPR_SCALE when we don't have a sprite scaler drm/i915: VLV does not have a sprite scaler Daniel Vetter (24): drm/i915: s/DRM_IRQ_ARGS/int irq, void *arg drm/i915: move hpd handling to (ibx|cpt)_irq_handler drm/i915: don't save/restore DP regs for kms drm/i915: don't save/restore irq regs for kms drm/i915: don't save/restore HWS_PGA reg for kms drm/i915/crt: don't set HOTPLUG bits on !PCH drm/i915/crt: explicitly set up HOTPLUG_BITS on resume drm/i915: don't save/restor ADPA for kms drm/i915: unconditionally use mt forcewake on hsw/ivb Merge tag 'v3.7-rc2' into drm-intel-next-queued drm: rename drm_dp_i2c_helper.c to drm_dp_helper.c drm: dp helper: extract drm_dp_channel_eq_ok drm: dp helper: extract drm_dp_clock_recovery_ok drm: extract helpers to compute new training values from sink request drm: extract dp link train delay functions from radeon drm/i915: use the new dp train delay helpers drm: extract dp link bw helpers drm: extract drm_dp_max_lane_count helper drm/i915/dp: actually nack test request drm/i915: make edp panel power sequence setup more robust drm/i915: enable/disable backlight for eDP drm/i915/eDP: compute the panel power clock divisor from the pch rawclock drm/i915/dp: compute the pch dp aux divider fro
Re: [PATCH 1/8] cgroup: kill cgroup_subsys->__DEPRECATED_clear_css_refs
(2012/10/31 13:22), Tejun Heo wrote:
> 2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
> handling") removed the last user of __DEPRECATED_clear_css_refs. This
> patch removes __DEPRECATED_clear_css_refs and mechanisms to support
> it.
>
> * Conditionals dependent on __DEPRECATED_clear_css_refs removed.
>
> * ->pre_destroy() now can only fail if a new task is attached or child
>cgroup is created while ->pre_destroy()s are being called. As the
>condition is checked again after re-acquiring cgroup_mutex
>afterwards, we don't need to take any immediate action on
>->pre_destroy() failures. This reduces cgroup_call_pre_destroy() to
>a simple loop surrounding ->pre_destory(). Remove
>cgroup_call_pre_destroy() and open-code the loop into
>cgroup_rmdir().
>
> * cgroup_clear_css_refs() can no longer fail. All that needs to be
>done are deactivating refcnts, setting CSS_REMOVED and putting the
>base reference on each css. Remove cgroup_clear_css_refs() and the
>failure path, and open-code the loops into cgroup_rmdir().
>
> Note that cgroup_rmdir() will see more cleanup soon.
>
> Signed-off-by: Tejun Heo
I thank you and Michal for this work.
Reviewed-by: KAMEZAWA Hiroyuki
--
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 0/3] capebus moving omap_devices to mach-omap2
Hi Jason, On 11/1/2012 7:50 PM, Jason Kridner wrote: My apologies for starting a new thread, but I don't have this thread in my Inbox. http://www.spinics.net/lists/linux-omap/msg81034.html Tony Lindgren wrote: * Pantelis Antoniou [121031 15:02]: So when device's node is 'disabled' of_platform_device_create_pdata() will not create the device. Now, of course it is possible to re-trigger the platform's probe method to be called, and in fact I do so in the capebus patches. You should fix this in generic way then rather than working around it in capebus. The same problem exists changing between different functionality for the shared pins, let's say between USB pins and UART pins if you want a serial debug console on some phone. The current capebus solution goes a long way to fixing a huge issue for BeagleBone users and I don't understand what seems to be a push-back on principle. On BeagleBone capes, these conflicts cannot be resolved early. I don't think there is any push-back on the principle. It is a very valid problem that does not have any solution today. The comments are more on the implementation. Do you have suggestions on some more generic method? It seems to me the proposed capebus approach strikes a good balance. Well, yeah, that's a generic DT issue, not a beagle-cape issue. We should not necessarily handle it by introducing some fake bus and some new binding like spi-dt / i2c-dt that does not mean anything in term of HW. DT is about pure HW representation. Introducing some fake hierarchy to make SW life easier is not necessarily the good approach. Adding the version information in the nodes is potentially a good idea, but should clearly be well thought and part of the DT core. Regards, Benoit -- 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/8] cgroup: kill CSS_REMOVED
(2012/10/31 13:22), Tejun Heo wrote: > CSS_REMOVED is one of the several contortions which were necessary to > support css reference draining on cgroup removal. All css->refcnts > which need draining should be deactivated and verified to equal zero > atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts > needed to be re-activated and css_tryget() shouldn't fail in the > process. > > This was achieved by letting css_tryget() busy-loop until either the > refcnt is reactivated (failed removal attempt) or CSS_REMOVED is set > (committing to removal). > > Now that css refcnt draining is no longer used, there's no need for > atomic rollback mechanism. css_tryget() simply can look at the > reference count and fail if the it's deactivated - it's never getting > re-activated. > > This patch removes CSS_REMOVED and updates __css_tryget() to fail if > the refcnt is deactivated. > > Note that this removes css_is_removed() whose only user is VM_BUG_ON() > in memcontrol.c. We can replace it with a check on the refcnt but > given that the only use case is a debug assert, I think it's better to > simply unexport it. > > Signed-off-by: Tejun Heo > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Balbir Singh > Cc: KAMEZAWA Hiroyuki Reviewed-by: KAMEZAWA Hiroyuki -- 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: iio: adc: ad7280a.c: fixed macro coding style
On 11/02/2012 07:28 AM, Kumar Amit Mehta wrote:
> remove unnecessary semicolon from the macro definition
>
> Signed-off-by: Kumar Amit Mehta
Thanks, added to togreg branch of iio.git
> ---
> drivers/staging/iio/adc/ad7280a.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/staging/iio/adc/ad7280a.c
> b/drivers/staging/iio/adc/ad7280a.c
> index cfc39a7..e7cb3b2 100644
> --- a/drivers/staging/iio/adc/ad7280a.c
> +++ b/drivers/staging/iio/adc/ad7280a.c
> @@ -117,7 +117,7 @@
> */
> #define POLYNOM 0x2F
> #define POLYNOM_ORDER8
> -#define HIGHBIT 1 << (POLYNOM_ORDER - 1);
> +#define HIGHBIT (1 << (POLYNOM_ORDER - 1))
>
> struct ad7280_state {
> struct spi_device *spi;
>
--
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/2 v5] block/throttle: remove redundant type transition
From: Robin Dong
We don't need to convert tg to blkg and then convert it back in
throtl_update_dispatch_stats().
Signed-off-by: Robin Dong
---
block/blk-throttle.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index a9664fa..46ddeff 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -674,10 +674,9 @@ static bool tg_may_dispatch(struct throtl_data *td, struct
throtl_grp *tg,
return 0;
}
-static void throtl_update_dispatch_stats(struct blkcg_gq *blkg, u64 bytes,
+static void throtl_update_dispatch_stats(struct throtl_grp *tg, u64 bytes,
int rw)
{
- struct throtl_grp *tg = blkg_to_tg(blkg);
struct tg_stats_cpu *stats_cpu;
unsigned long flags;
@@ -708,7 +707,7 @@ static void throtl_charge_bio(struct throtl_grp *tg, struct
bio *bio)
tg->bytes_disp[rw] += bio->bi_size;
tg->io_disp[rw]++;
- throtl_update_dispatch_stats(tg_to_blkg(tg), bio->bi_size, bio->bi_rw);
+ throtl_update_dispatch_stats(tg, bio->bi_size, bio->bi_rw);
}
static void throtl_add_bio_tg(struct throtl_data *td, struct throtl_grp *tg,
@@ -1127,7 +1126,7 @@ bool blk_throtl_bio(struct request_queue *q, struct bio
*bio)
tg = throtl_lookup_tg(td, blkcg);
if (tg) {
if (tg_no_rule_group(tg, rw)) {
- throtl_update_dispatch_stats(tg_to_blkg(tg),
+ throtl_update_dispatch_stats(tg,
bio->bi_size, bio->bi_rw);
goto out_unlock_rcu;
}
--
1.7.1
--
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/2 v5] block/throttle: Add IO submitted information in blkio.throttle
From: Robin Dong
Currently, if the IO is throttled by io-throttle, the system admin has no idea
of the situation and can't report it to the real application user about that
he/she has to do something.
So this patch adds a new interface named blkio.throttle.io_submitted which
exposes the number of bios that have been sent into blk-throttle therefore the
user could calculate the difference from throttle.io_serviced to see how many
IOs are currently throttled.
Cc: Tejun Heo
Cc: Vivek Goyal
Cc: Jens Axboe
Signed-off-by: Tao Ma
Signed-off-by: Robin Dong
---
v3 <-- v2:
- Use nr-queued[] of struct throtl_grp for stats instaed of adding new
blkg_rwstat.
v4 <-- v3:
- Add two new blkg_rwstat arguments to count total bios be sent into
blk_throttle.
v5 <-- v4:
- Change name "io_submit_bytes" to "io_submitted_bytes".
block/blk-throttle.c | 43 +++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/block/blk-throttle.c b/block/blk-throttle.c
index 46ddeff..c6391b5 100644
--- a/block/blk-throttle.c
+++ b/block/blk-throttle.c
@@ -46,6 +46,10 @@ struct tg_stats_cpu {
struct blkg_rwstat service_bytes;
/* total IOs serviced, post merge */
struct blkg_rwstat serviced;
+ /* total bytes submitted into blk-throttle */
+ struct blkg_rwstat submit_bytes;
+ /* total IOs submitted into blk-throttle */
+ struct blkg_rwstat submitted;
};
struct throtl_grp {
@@ -266,6 +270,8 @@ static void throtl_pd_reset_stats(struct blkcg_gq *blkg)
blkg_rwstat_reset(&sc->service_bytes);
blkg_rwstat_reset(&sc->serviced);
+ blkg_rwstat_reset(&sc->submit_bytes);
+ blkg_rwstat_reset(&sc->submitted);
}
}
@@ -699,6 +705,30 @@ static void throtl_update_dispatch_stats(struct throtl_grp
*tg, u64 bytes,
local_irq_restore(flags);
}
+static void throtl_update_submit_stats(struct throtl_grp *tg, u64 bytes, int
rw)
+{
+ struct tg_stats_cpu *stats_cpu;
+ unsigned long flags;
+
+ /* If per cpu stats are not allocated yet, don't do any accounting. */
+ if (tg->stats_cpu == NULL)
+ return;
+
+ /*
+* Disabling interrupts to provide mutual exclusion between two
+* writes on same cpu. It probably is not needed for 64bit. Not
+* optimizing that case yet.
+*/
+ local_irq_save(flags);
+
+ stats_cpu = this_cpu_ptr(tg->stats_cpu);
+
+ blkg_rwstat_add(&stats_cpu->submitted, rw, 1);
+ blkg_rwstat_add(&stats_cpu->submit_bytes, rw, bytes);
+
+ local_irq_restore(flags);
+}
+
static void throtl_charge_bio(struct throtl_grp *tg, struct bio *bio)
{
bool rw = bio_data_dir(bio);
@@ -1084,6 +1114,16 @@ static struct cftype throtl_files[] = {
.private = offsetof(struct tg_stats_cpu, serviced),
.read_seq_string = tg_print_cpu_rwstat,
},
+ {
+ .name = "throttle.io_submitted_bytes",
+ .private = offsetof(struct tg_stats_cpu, submit_bytes),
+ .read_seq_string = tg_print_cpu_rwstat,
+ },
+ {
+ .name = "throttle.io_submitted",
+ .private = offsetof(struct tg_stats_cpu, submitted),
+ .read_seq_string = tg_print_cpu_rwstat,
+ },
{ } /* terminate */
};
@@ -1128,6 +1168,8 @@ bool blk_throtl_bio(struct request_queue *q, struct bio
*bio)
if (tg_no_rule_group(tg, rw)) {
throtl_update_dispatch_stats(tg,
bio->bi_size, bio->bi_rw);
+ throtl_update_submit_stats(tg,
+ bio->bi_size, bio->bi_rw);
goto out_unlock_rcu;
}
}
@@ -1141,6 +1183,7 @@ bool blk_throtl_bio(struct request_queue *q, struct bio
*bio)
if (unlikely(!tg))
goto out_unlock;
+ throtl_update_submit_stats(tg, bio->bi_size, bio->bi_rw);
if (tg->nr_queued[rw]) {
/*
* There is already another bio queued in same dir. No
--
1.7.1
--
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 5/8] ARM: zynq: add COMMON_CLK support
On 10/31/2012 07:58 PM, Josh Cartwright wrote:
> [...]
> +#define PERIPH_CLK_CTRL_SRC(x) (periph_clk_parent_map[((x)&3)>>4])
> +#define PERIPH_CLK_CTRL_DIV(x) (((x)&0x3F00)>>8)
A few more spaces wouldn't hurt ;)
> [...]
> +static void __init zynq_periph_clk_setup(struct device_node *np)
> +{
> + struct zynq_periph_clk *periph;
> + const char *parent_names[3];
> + struct clk_init_data init;
> + struct clk *clk;
> + int err;
> + u32 reg;
> + int i;
> +
> + err = of_property_read_u32(np, "reg", ®);
> + WARN_ON(err);
Shouldn't the function abort if a error happens somewhere? Continuing here
will lead to undefined behavior. Same is probably true for the other WARN_ONs.
> +
> + periph = kzalloc(sizeof(*periph), GFP_KERNEL);
> + WARN_ON(!periph);
> +
> + periph->clk_ctrl = slcr_base + reg;
> + spin_lock_init(&periph->clkact_lock);
> +
> + init.name = np->name;
> + init.ops = &zynq_periph_clk_ops;
> + for (i = 0; i < ARRAY_SIZE(parent_names); i++)
> + parent_names[i] = of_clk_get_parent_name(np, i);
> + init.parent_names = parent_names;
> + init.num_parents = ARRAY_SIZE(parent_names);
> +
> + periph->hw.init = &init;
> +
> + clk = clk_register(NULL, &periph->hw);
> + WARN_ON(IS_ERR(clk));
> +
> + err = of_clk_add_provider(np, of_clk_src_simple_get, clk);
> + WARN_ON(err);
> +
> + for (i = 0; i < 2; i++) {
Not all of the peripheral clock generators have two output clocks. I think
it makes sense to use the number entries in clock-output-names here.
> + const char *name;
> +
> + err = of_property_read_string_index(np, "clock-output-names", i,
> + &name);
> + WARN_ON(err);
> +
> + periph->gates[i] = clk_register_gate(NULL, name, np->name, 0,
> + periph->clk_ctrl, i, 0,
> + &periph->clkact_lock);
> + WARN_ON(IS_ERR(periph->gates[i]));
> + }
> +
> + periph->onecell_data.clks = periph->gates;
> + periph->onecell_data.clk_num = i;
> +
> + err = of_clk_add_provider(np, of_clk_src_onecell_get,
> + &periph->onecell_data);
> + WARN_ON(err);
> +}
> [...]
--
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/
[GIT PULL REQUEST] UniCore32 update for v3.7-rc3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The following changes since commit 8c23f406c6d86808726ace580657186bc3b44587:
Linus Torvalds (1):
Merge git://git.kernel.org/pub/scm/virt/kvm/kvm
are available in the git repository at:
git://github.com/gxt/linux.git unicore32
Al Viro (2):
unicore32: switch to generic kernel_thread()/kernel_execve()
unicore32: switch to generic sys_execve()
David Howells (1):
UAPI: (Scripted) Disintegrate arch/unicore32/include/asm
Guan Xuetao (4):
UniCore32 bugfix: add missed CONFIG_ZONE_DMA
UniCore32-bugfix: fix mismatch return value of __xchg_bad_pointer
UniCore32-bugfix: Remove definitions in asm/bug.h to solve difference
between native and cross compiler
unicore32: Use Kbuild infrastructure for kvm_para.h
Kautuk Consul (1):
unicore32/mm/fault.c: Port OOM changes to do_pf
Kees Cook (1):
arch/unicore32: remove CONFIG_EXPERIMENTAL
arch/unicore32/Kconfig |7 ++-
arch/unicore32/include/asm/Kbuild |1 -
arch/unicore32/include/asm/bug.h |5 -
arch/unicore32/include/asm/cmpxchg.h |2 +-
arch/unicore32/include/asm/kvm_para.h |1 -
arch/unicore32/include/asm/processor.h |5 -
arch/unicore32/include/asm/ptrace.h| 76 +
arch/unicore32/include/uapi/asm/Kbuild |7 ++
arch/unicore32/include/{ => uapi}/asm/byteorder.h |0
arch/unicore32/include/uapi/asm/ptrace.h | 90
arch/unicore32/include/{ => uapi}/asm/sigcontext.h |0
arch/unicore32/include/{ => uapi}/asm/unistd.h |1 +
arch/unicore32/kernel/entry.S | 20 ++---
arch/unicore32/kernel/process.c| 58 +++--
arch/unicore32/kernel/setup.h |6 ++
arch/unicore32/kernel/sys.c| 63 --
arch/unicore32/mm/fault.c | 37 ++--
17 files changed, 160 insertions(+), 219 deletions(-)
delete mode 100644 arch/unicore32/include/asm/kvm_para.h
rename arch/unicore32/include/{ => uapi}/asm/byteorder.h (100%)
create mode 100644 arch/unicore32/include/uapi/asm/ptrace.h
rename arch/unicore32/include/{ => uapi}/asm/sigcontext.h (100%)
rename arch/unicore32/include/{ => uapi}/asm/unistd.h (92%)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJQk5LlAAoJENFylnOm3dTbo1EP/1n+OguOJgzt9Xo3B8Y9ZO0I
abbA44rYzCutWrrXbnwh6/Yb84w+L8VN5Wts+OW4L6P5f751SPkDxWTMS3ObpP8X
h3YxW0qVfItGKeJv2jv390TrFUmgS+bXRc26NIUr7iwi1y8DMJ7X6tiLH9agRu2r
c/e5+IC0zmtRfhKlFYdEHY8KD+Eee4gKAg8ZsB+SMql9xqx3mh/FCxE2fTshvA6v
djx0gLohUanBJWeyIc8lFZyLP5uvbfaSVfn5Qf3T43i+2uGMnX34PhZaWj3UNG8c
yvl5x0DnC2bx96Vg8iuJLIZAgi0mqqZcGMH5YDBnKzjHCEJFvEvLL2udqp/5/f6Q
27AxC9krOiXfx6DWhyPw3mRp38IhR8nApCo8dNXES+ePjZiRiDHSRqY3ZIo+QbzN
b7prxiHKYP9OLewXbNVRGQvKSy8hNGhyL+hCXUIR/azfZ8dBm6eni2cdIO11pHPm
dYqvT4UrU5R3zP4Nq4ZIPMV88vjknCJp5l5cTZol7j7niOEvaSuU5TYezUF2FA/I
RI2ZEsDzltKR+o7G6hYd+swlQCs/R7o3pYYwWEe7/YZp88lA3+0fj3V1wdmwaeuP
/ZKNWoiMV7ZINCkwaFCtJRhC0pCvh4lndw83SPzFKrNyKDgTH3ANH3g7q2wLZ0ha
4sevLKaEHJJPI00wSXiS
=pUws
-END PGP 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/
Re: [PATCH 2/3] ti_tscadc: Match mfd sub devices to regmap interface
On 11/01/2012 03:24 PM, Pantelis Antoniou wrote:
> The MFD parent device now uses a regmap, instead of direct
> memory access. Use the same method in the sub devices to avoid
> nasty surprises.
>
> Please not that this driver can't really deal with the case of the regmap
> call failing in anyway. So that's why there's no error handling.
>
> I think it's best to patch this up, until the driver maintainers deal
> with this properly.
This should be split in two as it's touching two different drivers in
different subsystems and may merge through them.
>
> Signed-off-by: Pantelis Antoniou
> ---
> drivers/iio/adc/ti_am335x_adc.c | 10 --
> drivers/input/touchscreen/ti_am335x_tsc.c | 9 +++--
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index 8595a90..44806f9 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -23,7 +23,9 @@
> #include
> #include
> #include
> +#include
>
> +#include
> #include
> #include
>
> @@ -36,13 +38,17 @@ struct tiadc_device {
>
> static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
> {
> - return readl(adc->mfd_tscadc->tscadc_base + reg);
> + unsigned int val;
> +
> + val = (unsigned int)-1;
> + regmap_read(adc->mfd_tscadc->regmap_tscadc, reg, &val);
> + return val;
> }
>
> static void tiadc_writel(struct tiadc_device *adc, unsigned int reg,
> unsigned int val)
> {
> - writel(val, adc->mfd_tscadc->tscadc_base + reg);
> + regmap_write(adc->mfd_tscadc->regmap_tscadc, reg, val);
> }
>
> static void tiadc_step_config(struct tiadc_device *adc_dev)
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
> b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 7a26810..5723957 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -26,6 +26,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -64,13 +65,17 @@ struct titsc {
>
> static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
> {
> - return readl(ts->mfd_tscadc->tscadc_base + reg);
> + unsigned int val;
> +
> + val = (unsigned int)-1;
> + regmap_read(ts->mfd_tscadc->regmap_tscadc, reg, &val);
> + return val;
> }
>
> static void titsc_writel(struct titsc *tsc, unsigned int reg,
> unsigned int val)
> {
> - writel(val, tsc->mfd_tscadc->tscadc_base + reg);
> + regmap_write(tsc->mfd_tscadc->regmap_tscadc, reg, val);
> }
>
> /*
>
--
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/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create()
(2012/10/31 13:22), Tejun Heo wrote:
> This patch makes cgroup_create() fail if @parent is marked removed.
> This is to prepare for further updates to cgroup_rmdir() path.
>
> Note that this change isn't strictly necessary. cgroup can only be
> created via mkdir and the removed marking and dentry removal happen
> without releasing cgroup_mutex, so cgroup_create() can never race with
> cgroup_rmdir(). Even after the scheduled updates to cgroup_rmdir(),
> cgroup_mkdir() and cgroup_rmdir() are synchronized by i_mutex
> rendering the added liveliness check unnecessary.
>
> Do it anyway such that locking is contained inside cgroup proper and
> we don't get nasty surprises if we ever grow another caller of
> cgroup_create().
>
> Signed-off-by: Tejun Heo
I welcome this change.
Reviewed-by: KAMEZAWA Hiroyuki
> ---
> kernel/cgroup.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index a49cdbc..b3010ae 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -3906,6 +3906,18 @@ static long cgroup_create(struct cgroup *parent,
> struct dentry *dentry,
> if (!cgrp)
> return -ENOMEM;
>
> + /*
> + * Only live parents can have children. Note that the liveliness
> + * check isn't strictly necessary because cgroup_mkdir() and
> + * cgroup_rmdir() are fully synchronized by i_mutex; however, do it
> + * anyway so that locking is contained inside cgroup proper and we
> + * don't get nasty surprises if we ever grow another caller.
> + */
> + if (!cgroup_lock_live_group(parent)) {
> + err = -ENODEV;
> + goto err_free;
> + }
> +
> /* Grab a reference on the superblock so the hierarchy doesn't
>* get deleted on unmount if there are child cgroups. This
>* can be done outside cgroup_mutex, since the sb can't
> @@ -3913,8 +3925,6 @@ static long cgroup_create(struct cgroup *parent, struct
> dentry *dentry,
>* fs */
> atomic_inc(&sb->s_active);
>
> - mutex_lock(&cgroup_mutex);
> -
> init_cgroup_housekeeping(cgrp);
>
> cgrp->parent = parent;
> @@ -3985,7 +3995,7 @@ static long cgroup_create(struct cgroup *parent, struct
> dentry *dentry,
>
> /* Release the reference count that we took on the superblock */
> deactivate_super(sb);
> -
> +err_free:
> kfree(cgrp);
> return err;
> }
>
--
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 5/5] drivers/iio/industrialio-event.c: eliminate possible double free
On 10/21/2012 11:52 AM, Julia Lawall wrote:
> From: Julia Lawall
>
> The function __iio_add_event_config_attrs is only called once, by the
> function iio_device_register_eventset. If the call fails,
> iio_device_register_eventset calls __iio_remove_event_config_attrs. There
> is thus no need for __iio_add_event_config_attrs to also call
> __iio_remove_event_config_attrs on failure.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> //
> @r@
> identifier f,free,a;
> parameter list[n] ps;
> type T;
> expression e;
> @@
>
> f(ps,T a,...) {
> ... when any
> when != a = e
> if(...) { ... free(a); ... return ...; }
> ... when any
> }
>
> @@
> identifier r.f,r.free;
> expression x,a;
> expression list[r.n] xs;
> @@
>
> * x = f(xs,a,...);
> if (...) { ... free(a); ... return ...; }
> //
>
> Signed-off-by: Julia Lawall
Thanks - merged to fixes-togreg branch of iio.git
Jonathan
>
> ---
> __iio_remove_event_config_attrs kfrees the elements of a list, but doesn't
> actually remove them from the list. Perhaps for safety this should be
> cleaned up as well. Not tested.
>
> drivers/iio/industrialio-event.c |7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/iio/industrialio-event.c
> b/drivers/iio/industrialio-event.c
> index fa6543b..78570c7 100644
> --- a/drivers/iio/industrialio-event.c
> +++ b/drivers/iio/industrialio-event.c
> @@ -350,15 +350,10 @@ static inline int __iio_add_event_config_attrs(struct
> iio_dev *indio_dev)
> ret = iio_device_add_event_sysfs(indio_dev,
>&indio_dev->channels[j]);
> if (ret < 0)
> - goto error_clear_attrs;
> + return ret;
> attrcount += ret;
> }
> return attrcount;
> -
> -error_clear_attrs:
> - __iio_remove_event_config_attrs(indio_dev);
> -
> - return ret;
> }
>
> static bool iio_check_for_dynamic_events(struct iio_dev *indio_dev)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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 2/3] pppoatm: fix race condition with destroying of vcc
On Thu, Nov 01, 2012 at 10:26:28AM -0400, chas williams - CONTRACTOR wrote:
> On Wed, 31 Oct 2012 23:04:35 +0100
> Krzysztof Mazur wrote:
>
> > There are also some minor potential issues in pppoatm driver:
> >
> > - locking issues, but now only between pppoatm_send() and
> > vcc_sendmsg() and maybe some other functions,
>
> these have been around for a while. i agree that something should be
> done about it. just not sure what should be synchronizing this mess.
I think the ATM socket lock should be used. I'm sending the latest
patch that adds this locking after David Woodhouse's comments. The vcc->flags
check is now probably unnecessary.
>
> > - missing check for SS_CONNECTED in pppoatm_ioctl,
>
> in practice you will never run into this because a pvc is immediately
> put into SS_CONNECTED mode (right before the userspace open()
> returns). however, should it check? yes. i dont see anything
> preventing you from running ppp on svc's.
I can confirm that the problem really exists, without connect() in pppoatm
plugin in pppd, I have seen an Oops and panic. I will send appropriate
patch.
Thanks.
Krzysiek
-- >8 --
diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c
index f27a07a..ef19436 100644
--- a/net/atm/pppoatm.c
+++ b/net/atm/pppoatm.c
@@ -269,10 +269,23 @@ static inline int pppoatm_may_send(struct pppoatm_vcc
*pvcc, int size)
static int pppoatm_send(struct ppp_channel *chan, struct sk_buff *skb)
{
struct pppoatm_vcc *pvcc = chan_to_pvcc(chan);
+ struct atm_vcc *vcc;
+ int ret;
+
ATM_SKB(skb)->vcc = pvcc->atmvcc;
pr_debug("(skb=0x%p, vcc=0x%p)\n", skb, pvcc->atmvcc);
if (skb->data[0] == '\0' && (pvcc->flags & SC_COMP_PROT))
(void) skb_pull(skb, 1);
+
+ vcc = ATM_SKB(skb)->vcc;
+ bh_lock_sock(sk_atm(vcc));
+ if (sock_owned_by_user(sk_atm(vcc)))
+ goto nospace;
+ if (test_bit(ATM_VF_RELEASED, &vcc->flags)
+ || test_bit(ATM_VF_CLOSE, &vcc->flags)
+ || !test_bit(ATM_VF_READY, &vcc->flags))
+ goto nospace;
+
switch (pvcc->encaps) { /* LLC encapsulation needed */
case e_llc:
if (skb_headroom(skb) < LLC_LEN) {
@@ -285,8 +298,10 @@ static int pppoatm_send(struct ppp_channel *chan, struct
sk_buff *skb)
}
consume_skb(skb);
skb = n;
- if (skb == NULL)
+ if (skb == NULL) {
+ bh_unlock_sock(sk_atm(vcc));
return DROP_PACKET;
+ }
} else if (!pppoatm_may_send(pvcc, skb->truesize))
goto nospace;
memcpy(skb_push(skb, LLC_LEN), pppllc, LLC_LEN);
@@ -296,6 +311,7 @@ static int pppoatm_send(struct ppp_channel *chan, struct
sk_buff *skb)
goto nospace;
break;
case e_autodetect:
+ bh_unlock_sock(sk_atm(vcc));
pr_debug("Trying to send without setting encaps!\n");
kfree_skb(skb);
return 1;
@@ -305,9 +321,12 @@ static int pppoatm_send(struct ppp_channel *chan, struct
sk_buff *skb)
ATM_SKB(skb)->atm_options = ATM_SKB(skb)->vcc->atm_options;
pr_debug("atm_skb(%p)->vcc(%p)->dev(%p)\n",
skb, ATM_SKB(skb)->vcc, ATM_SKB(skb)->vcc->dev);
- return ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
+ ret = ATM_SKB(skb)->vcc->send(ATM_SKB(skb)->vcc, skb)
? DROP_PACKET : 1;
+ bh_unlock_sock(sk_atm(vcc));
+ return ret;
nospace:
+ bh_unlock_sock(sk_atm(vcc));
/*
* We don't have space to send this SKB now, but we might have
* already applied SC_COMP_PROT compression, so may need to undo
--
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 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi wrote: > Hi, > > On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote: >> On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote: >> > HI, >> > >> > On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: >> >> Hi Alan, >> >> >> >> On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: >> >> >> >> >> What they want, and what every user wants, is I plug this board in, and >> >> >> the driver make sure everything is loaded and ready. No, the end users >> >> >> don't want to see any of the implementation details of how the bitfile >> >> >> is transported; the driver can handle it. >> >> > >> >> > That doesn't necessarily make it a bus merely some kind of hotplug >> >> > enumeration of devices. That should all work properly both for devices >> >> > and busses with spi and i²c as the final bits needed for it got fixed >> >> > some time ago. >> >> > >> >> > In an ideal world you don't want to be writing custom drivers for stuff. >> >> > If your cape routes an i²c serial device to the existing system i²c >> >> > busses then you want to just create an instance of any existing driver >> >> > on >> >> > the existing i²c bus not create a whole new layer of goop. >> >> > >> >> > It does need to do the plumbing and resource management for the plumbing >> >> > but thats not the same as being a bus. >> >> > >> >> > Alan >> >> >> >> >> >> Fair enough. But there's no such thing a 'hotplug enumeration >> >> construct' in Linux yet, and a bus is the closest thing to it. It does >> >> take advantage of the nice way device code matches drivers and devices >> >> though. >> >> >> >> I'm afraid that having the I2C/SPI drivers doing the detection won't >> >> work. The capes can have arbitrary I2C/SPI devices (and even more >> >> weird components). There is no way to assure for example that the I2C >> >> device responding to address 'foo' in cape A is the same I2C device >> >> responding to the same address in cape B. >> > >> > your ->detect() method should take care of that. >> >> There isn't some magical serial number in I²C devices that a >> ->detect() method can read and the implementation of I²C is somewhat >> flexible. One devices read may be another devices write. A detect > > look at what other drivers do. You can read a revision register, you can > write a command and see if the device responds as expected, it doesn't > matter. Since a "revision" register isn't required by the I²C spec, it isn't implemented on a huge number of chips. Also, having a few dozen probe routines come though and write to random address of every single I²C device can a) take a really long time, and b) have quite a few unintended side effects. >> method that only performs reads could easily toggle a gpio that resets >> the board, rewrite and eeprom, or set the printer on fire. If you > > how ? It's just a read. Because the I²C spec is incredibly flexible. For a lot of devices, reading from a register is done by writing the register address, and then reading the contents. For devices that don't implement registers in that way (such as many eeproms), this is just a write. >> browse through various detect functions, yes, some of them key off an >> ID, but a lot of them just check various registers to see if certain >> bits are zero, or certain bits are one. A lot of I²C devices I've >> dealt with have no good way of probing them, especially GPIO chips >> (you'll notice none of the I²C GPIO expanders have detect functions) > > it doesn't mean it can't be done. Really? Please, do tell how you would write a detect function for a PCA9534. It has 4 registers, an input port registers, an output port register, a polarity inversion register, and a configuration register. And don't forget, since we are probing, every detect routine for every I²C driver will have to run with every I²C address on every bus, possibly with both address formats. >> On top of all this the detect routine does not tell you if the alert >> pin is connected to some IRQ, or in the case of a GPIO expander, what >> those GPIOs are connected to, etc, etc. > > so what ? All you want to do with detect is figure out if the far end is > who you think it is, not what it's doing. If we already knew who was there, we wouldn't need a detect routine. -- 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/8] cgroup: deactivate CSS's and mark cgroup dead before invoking ->pre_destroy()
(2012/10/31 13:22), Tejun Heo wrote: > Because ->pre_destroy() could fail and can't be called under > cgroup_mutex, cgroup destruction did something very ugly. > >1. Grab cgroup_mutex and verify it can be destroyed; fail otherwise. > >2. Release cgroup_mutex and call ->pre_destroy(). > >3. Re-grab cgroup_mutex and verify it can still be destroyed; fail > otherwise. > >4. Continue destroying. > > In addition to being ugly, it has been always broken in various ways. > For example, memcg ->pre_destroy() expects the cgroup to be inactive > after it's done but tasks can be attached and detached between #2 and > #3 and the conditions that memcg verified in ->pre_destroy() might no > longer hold by the time control reaches #3. > > Now that ->pre_destroy() is no longer allowed to fail. We can switch > to the following. > >1. Grab cgroup_mutex and fail if it can't be destroyed; fail > otherwise. > >2. Deactivate CSS's and mark the cgroup removed thus preventing any > further operations which can invalidate the verification from #1. > >3. Release cgroup_mutex and call ->pre_destroy(). > >4. Re-grab cgroup_mutex and continue destroying. > > After this change, controllers can safely assume that ->pre_destroy() > will only be called only once for a given cgroup and, once > ->pre_destroy() is called, the cgroup will stay dormant till it's > destroyed. > > Signed-off-by: Tejun Heo Reviewed-by: KAMEZAWA Hiroyuki Ok, cgroup_lock_live_group() will work synchronously against attach_task(). I welcome this. -- 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: MIPS ASID type conflicts
On Mon, Apr 23, 2012 at 01:49:26PM +0200, Jean-Christophe PINCE wrote:
> I am analyzing Linux MIPS tasks memory spaces and found out what I
> think is a bug in the ASID management.
>
> The structure "struct cpuinfo_mips" defined in
> arch/mips/include/asm/cpu-info.h uses a "unsigned int" field for
> asid_cache while the context field defined in
> arch/mips/include/asm/mmu.h is a "unsigned long".
>
> This is ok with 32bits kernel but leads to 4bytes vs 8bytes fields
> with a 64bits kernel. And when the scheduler checks if the ASID is of
> an older ASID_VERSION, the test will always return that the version
> differs when the context bits above bit31 will be set.
>
> I imagine this should be a quite rare issue but could likely happen on
> devices running for very long and starting processes very often (or
> running more than 256 processes per cpu). When this condition (bit 32
> or above of asid_cache is set), the effect should be that the TLB will
> be flushed on each context_switch required by the scheduler but there
> shouldn't be any crash.
A full flush of the TLB can be implemented by picking a fresh ASID as
long as there are still fresh ASIDs available. This happens fairly
frequently; a typical system has burned through the first 256 ASIDs
somewhen during bootup.
There is not much advantage to be gained from having the ASID and generation
counter in a 64-bit variable so I think I'm just going to change
mmu_context_t to:
typedef struct {
unsigned int asid[NR_CPUS];
void *vdso;
} mm_context_t;
Ralf
--
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: discrepancy while save and restore of debounce registers
On Thu, Oct 18, 2012 at 21:44:56, Hunter, Jon wrote: > Hi Gururaja, > > On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote: > > Jon, > > > > On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote: > > [snip] > > >>> My doubt/questions are > >>> 1. Why should debounce registers be updated only when it's accessed > >>> previously? > >> > >> If debounce is not being used by any of the gpios, then there is no need > >> to restore them as there are no bits set. So this makes sense and saves > >> a couple register writes. > > > > What I want to know is that other than saving register writes, is there any > > other important stuff that specifies this requirement. > > From a HW perspective, none that I can see. > > From a SW perspective, yes, as I mentioned if you restore these > registers without first initialising the context variables where these > registers are stored, then you may be restoring unknown values to the > registers and that is bad. > > >>> 2. What is the relation between updating debounce registers and crash > >>> seen on > >>> others registers? > >> > >> This I am not sure about. I gave this a quick try on my omap3430 beagle > >> board, but I did not see any side-effects from doing this. However, if > >> you are always restoring the debounce context regardless of whether > >> debounce is being used, then you could be writing bad values to the > >> debounce registers as the context variables bank->context.debouce and > >> bank->context.debouce_en may not initialised. So that is bad. However, > >> that said I am still not sure how this could cause a crash. > >> > >> Can you share more details on ... > > > > Sorry for missing below details in first post. > > > >> 1. The OMAP platform you are using? > > > > I was trying this on TI AM335x platform (repo below). On AM335x EVM board > > > > http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog; > > h=refs/heads/v3.2-staging > > > >> 2. What linux distro/environment you are using? > > > > Arago AM335x PSP release (linux 3.2 + am335x patch-set) > > > >> 3. If there are any specific steps to reproduce this 100% of the time? > > > > On top of this tree, try suspend/resume using "echo mem > /syspower/state" > > I have a beagle-bone but unfortunately, suspend does not appear to be > supported in the mainline kernel yet so I am unable to test this on the > am335x on the mainline. You can try the suspend/resume on BB from Arago tree which I mentioned above > > Have you compared the gpio driver from your v3.2 branch with the current > mainline to see how different this code is? Ideally, it would be good to > test on the mainline kernel for another data point to see if this is > local to your branch. The mainline kernel omap GPIO driver has changed a lot from current arago tree (which is at v3.2). Upon comparing is when I found out about the register access check done before restoring. > > Cheers > Jon > > > Regards, Gururaja -- 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] Devfreq: Add debugfs node for representing frequency transition information
This patch adds debugfs node to measure transition of frequency on runtime.
It will be creted under '/sys/kernel/debugfs/devfreq/'dev name'/' as the name
of 'trans_table'. It contains number of transition of each frequency level,
time spent on each level, and also total transition count.
It inspired by CPUFREQ's cpufreq_stats method.
=
time spent
* n12 n13 t1
n21 n23 t2
n31 n32 t3
Total transition : N (= n12 + n13 + n21 + n23 + n31 + n32)
==
(n12 : Number of transition from level 1 to level 2)
('*' : The last changed frequency when you inspect the node.)
This patch also includes documentation.
Signed-off-by: Jonghwa Lee
---
Documentation/devfreq/transition_status_table | 265 +
drivers/devfreq/devfreq.c | 121 +++
include/linux/devfreq.h | 23 +++
3 files changed, 409 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devfreq/transition_status_table
diff --git a/Documentation/devfreq/transition_status_table
b/Documentation/devfreq/transition_status_table
new file mode 100644
index 000..8b92391
--- /dev/null
+++ b/Documentation/devfreq/transition_status_table
@@ -0,0 +1,265 @@
+DEVFREQ Transition status table
+=
+
+Copyright (C) 2012 Samsung Electronics
+
+Written by Jonghwa Lee
+
+1. Description
+
+
+DEVFREQ Transition status table represents all of transition information up to
now. Transition information
+includes number of transition which has been occured and time spent on the
each of frequencies.
+This implementation is ispired by CPUFREQ's cpufreq_stats method.
+
+
+
+ time spent
+
+* Number of transitionNumber
of transition t1
+ from freq1 to freq2 from
freq1 to freq3
+
+Number of transitionNumber
of transition t2
+ from freq2 to freq1 from
freq2 to freq3
+
+Number of transitionNumber of transition
t3
+ from freq3 to freq1 from freq3 to freq2
+
+Total transition : N
+=
+('*' : The last changed frequency when you inspect the node.)
+
+It may be used for measuring performance or debug use.
+
+
+2. Requirement to use
+---
+
+There is no kernel configuration option for creating this node at this moment.
Only CONFIG_DEBUG_FS is required.
+It will be created automatically when devfreq device created successfully.
+(under /sys/kernel/debug/devfreq/'each devfreq device name'/ by the name of
'trans_table'.)
+
+By the way, it's going to show nothing unless you go through the below steps.
+To show appropriate information about frequency transition, each devfreq
device must hand over their own list of
+available frequency and total count of frequency levels to the framework.
Because at the devfreq core side,
+system doesn't know how many freqeuncy levels are available and what value of
each level exactly is.
+In devfreq_dev_profile structure, freq_list and freq_levs will play the role
carrying the those requirement data.
+
+To guarantee trans_table working, following two steps are required.
+(1) Initialize the freq_list of devfreq_dev_profile with all available
freqeuncy data
+(2) Initialize the freq_levs of devfreq_dev_profile with total number of
available freqeuncy level.
+
+3. Guage performance
+--
+
+This program is user space program that measures the frequency transition
during the certain interval you set.
+When the program starts, it parses the trans_table contents and stores it for
later comparison at the end.
+And when you stop the gauging, the program will calculate transition
information happened during the interval given.
+The result is also formed like transition status table. However it can be used
for more specific purpose and usefully
+than trans_table itself. By analyzing its data, we can get an indicator of
performance of various situations or
+performance of governor and others also.
+
+HOW TO USE
+---
+1. Set the device name correctly in the code to the variable 'dev_name[]'
before the compile.
+ This will be used to get the path of debugfs node. (Default is
'exynos4412-busfreq').
+2. Run the program, and you'll see co
Re: Expressing linux-next collateral evolutions in formal grammar
The way I would envision this to be easier to manage is to break them down by subsystem and the reviewer can then go and read the grammar for their own subsystem of preference. The long term benefit of this is that even if folks don't use SmPL for collateral evolutions we have a possibility here of being able to backport a collateral evolution by using the inverse of the SmPL grammar, if we can get to the point of coming up with formal and proper grammar on each collateral evolution. Thoughts? I had liked the idea of lwn, because that makes it public but doesn't bother anyone. But another option would be to just send an email to the relevant maintainer? Perhaps it would be better to send the email just to the specific maintainer for the file, and not all the way up the maintainer hierarchy, because these would be just suggestions of things to look at, and not actual patch proposals. thanks, julia -- 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 v3] linux,stdout-path helper
The following adds a helper for matching the linux,stdout-path property in the chosen node and makes use of it in the i.MX serial driver. changes since v2: - move helper to OF core and make it independent of serial devices changes since v1: - move it out of the i.MX serial driver and make it generic for serial devices. Sascha Hauer (3): OF: Add helper for matching against linux,stdout-path serial: i.MX: Make console support non optional serial: i.MX: evaluate linux,stdout-path property drivers/of/Kconfig |3 +++ drivers/of/Makefile|1 + drivers/of/of_stdout.c | 27 +++ drivers/tty/serial/Kconfig | 16 +--- drivers/tty/serial/imx.c | 12 +--- include/linux/of_stdout.h | 24 6 files changed, 61 insertions(+), 22 deletions(-) create mode 100644 drivers/of/of_stdout.c create mode 100644 include/linux/of_stdout.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/
[PATCH 3/3] serial: i.MX: evaluate linux,stdout-path property
devicetrees may have the linux,stdout-path property to specify the console. This patch adds support to the i.MX serial driver for this. Signed-off-by: Sascha Hauer --- drivers/tty/serial/imx.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 3a9337e..41be237 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -47,6 +47,7 @@ #include #include #include +#include #include #include @@ -1421,6 +1422,9 @@ static int serial_imx_probe_dt(struct imx_port *sport, sport->devdata = of_id->data; + if (of_device_is_stdout_path(np)) + add_preferred_console(imx_reg.cons->name, sport->port.line, 0); + return 0; } #else -- 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 2/3] serial: i.MX: Make console support non optional
Traditionally console support is optional for serial drivers. This
makes it non optional for the i.MX driver since it's not worth
asking questions for a feature virtually every user of this driver
wants to have.
Signed-off-by: Sascha Hauer
---
drivers/tty/serial/Kconfig | 16 +---
drivers/tty/serial/imx.c |8 +---
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 4720b4b..920dd0d 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -515,26 +515,12 @@ config SERIAL_IMX
bool "IMX serial port support"
depends on ARCH_MXC
select SERIAL_CORE
+ select SERIAL_CORE_CONSOLE
select RATIONAL
help
If you have a machine based on a Motorola IMX CPU you
can enable its onboard serial port by enabling this option.
-config SERIAL_IMX_CONSOLE
- bool "Console on IMX serial port"
- depends on SERIAL_IMX
- select SERIAL_CORE_CONSOLE
- help
- If you have enabled the serial port on the Motorola IMX
- CPU you can make it the console by answering Y to this option.
-
- Even if you say Y here, the currently visible virtual console
- (/dev/tty0) will still be used as the system console by default, but
- you can alter that using a kernel command line option such as
- "console=ttySA0". (Try "man bootparam" or see the documentation of
- your boot loader (lilo or loadlin) about how to pass options to the
- kernel at boot time.)
-
config SERIAL_UARTLITE
tristate "Xilinx uartlite serial port support"
depends on PPC32 || MICROBLAZE || MFD_TIMBERDALE
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e309e8b..3a9337e 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -1192,7 +1192,6 @@ static struct uart_ops imx_pops = {
static struct imx_port *imx_ports[UART_NR];
-#ifdef CONFIG_SERIAL_IMX_CONSOLE
static void imx_console_putchar(struct uart_port *port, int ch)
{
struct imx_port *sport = (struct imx_port *)port;
@@ -1348,11 +1347,6 @@ static struct console imx_console = {
.data = &imx_reg,
};
-#define IMX_CONSOLE&imx_console
-#else
-#define IMX_CONSOLENULL
-#endif
-
static struct uart_driver imx_reg = {
.owner = THIS_MODULE,
.driver_name= DRIVER_NAME,
@@ -1360,7 +1354,7 @@ static struct uart_driver imx_reg = {
.major = SERIAL_IMX_MAJOR,
.minor = MINOR_START,
.nr = ARRAY_SIZE(imx_ports),
- .cons = IMX_CONSOLE,
+ .cons = &imx_console,
};
static int serial_imx_suspend(struct platform_device *dev, pm_message_t state)
--
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 1/3] OF: Add helper for matching against linux,stdout-path
devicetrees may have a linux,stdout-path property in the chosen
node describing the console device. This adds a helper function
to match a device against this property so a driver can call
add_preferred_console for a matching device.
Signed-off-by: Sascha Hauer
---
drivers/of/Kconfig|3 +++
drivers/of/Makefile |1 +
drivers/of/of_stdout.c| 27 +++
include/linux/of_stdout.h | 24
4 files changed, 55 insertions(+)
create mode 100644 drivers/of/of_stdout.c
create mode 100644 include/linux/of_stdout.h
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index dfba3e6..8574ebb 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -67,6 +67,9 @@ config OF_MDIO
help
OpenFirmware MDIO bus (Ethernet PHY) accessors
+config OF_STDOUT
+ def_bool y
+
config OF_PCI
def_tristate PCI
depends on PCI
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index e027f44..c9f3f2f 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_OF_I2C)+= of_i2c.o
obj-$(CONFIG_OF_NET) += of_net.o
obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
+obj-$(CONFIG_OF_STDOUT) += of_stdout.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
obj-$(CONFIG_OF_MTD) += of_mtd.o
diff --git a/drivers/of/of_stdout.c b/drivers/of/of_stdout.c
new file mode 100644
index 000..c9e370e
--- /dev/null
+++ b/drivers/of/of_stdout.c
@@ -0,0 +1,27 @@
+/*
+ * OF helper for linux,stdoutpath property.
+ *
+ * This file is released under the GPLv2
+ */
+#include
+
+/**
+ * of_device_is_stdout_path - check if a device node matches the
+ *linux,stdout-path property
+ *
+ * Check if this device node matches the linux,stdout-path property
+ * in the chosen node. return true if yes, false otherwise.
+ */
+int of_device_is_stdout_path(struct device_node *dn)
+{
+ const char *name;
+
+ name = of_get_property(of_chosen, "linux,stdout-path", NULL);
+ if (name == NULL)
+ return 0;
+
+ if (dn == of_find_node_by_path(name))
+ return 1;
+
+ return 0;
+}
diff --git a/include/linux/of_stdout.h b/include/linux/of_stdout.h
new file mode 100644
index 000..0d80674
--- /dev/null
+++ b/include/linux/of_stdout.h
@@ -0,0 +1,24 @@
+/*
+ * OF helper for linux,stdoutpath property.
+ *
+ * This file is released under the GPLv2
+ */
+
+#ifndef __LINUX_OF_STDOUT_H
+#define __LINUX_OF_STDOUT_H
+
+#ifdef CONFIG_OF_STDOUT
+
+#include
+int of_device_is_stdout_path(struct device_node *dn);
+
+#else
+
+static inline int of_device_is_stdout_path(struct device_node *dn)
+{
+ return 0;
+}
+
+#endif
+
+#endif /* __LINUX_OF_STDOUT_H */
--
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/
Re: [PATCH] iio: isl29018: Support suspend and resume.
On 10/25/2012 12:39 AM, Bryan Freed wrote:
> The driver leaves the device in power-down state anyway,
> so there is nothing to do on suspend.
> On resume, we just have to make sure the range and ADC
> values are updated in the device since it may have been
> powered down in suspend.
>
> Signed-off-by: Bryan Freed
Added to togreg branch of iio.git
though the various uses of power down in the description had
me scratching my head for a second.
I'm guessing auto power-down means the chip is locally disabled
but in suspend it's possible the power supply will be cut
to the chip rather than it simply powering down internally...
> ---
> drivers/staging/iio/light/isl29018.c | 45
> ++
> 1 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/staging/iio/light/isl29018.c
> b/drivers/staging/iio/light/isl29018.c
> index 6ee5567..3b03f6f 100644
> --- a/drivers/staging/iio/light/isl29018.c
> +++ b/drivers/staging/iio/light/isl29018.c
> @@ -67,6 +67,7 @@ struct isl29018_chip {
> unsigned intrange;
> unsigned intadc_bit;
> int prox_scheme;
> + boolsuspended;
> };
>
> static int isl29018_set_range(struct isl29018_chip *chip, unsigned long
> range,
> @@ -368,6 +369,10 @@ static int isl29018_read_raw(struct iio_dev *indio_dev,
> struct isl29018_chip *chip = iio_priv(indio_dev);
>
> mutex_lock(&chip->lock);
> + if (chip->suspended) {
> + mutex_unlock(&chip->lock);
> + return -EBUSY;
> + }
> switch (mask) {
> case IIO_CHAN_INFO_RAW:
> case IIO_CHAN_INFO_PROCESSED:
> @@ -561,6 +566,7 @@ static int __devinit isl29018_probe(struct i2c_client
> *client,
> chip->lux_scale = 1;
> chip->range = 1000;
> chip->adc_bit = 16;
> + chip->suspended = false;
>
> chip->regmap = devm_regmap_init_i2c(client, &isl29018_regmap_config);
> if (IS_ERR(chip->regmap)) {
> @@ -603,6 +609,44 @@ static int __devexit isl29018_remove(struct i2c_client
> *client)
> return 0;
> }
>
> +#ifdef CONFIG_PM_SLEEP
> +static int isl29018_suspend(struct device *dev)
> +{
> + struct isl29018_chip *chip = iio_priv(dev_get_drvdata(dev));
> +
> + mutex_lock(&chip->lock);
> +
> + /* Since this driver uses only polling commands, we are by default in
> + * auto shutdown (ie, power-down) mode.
> + * So we do not have much to do here.
> + */
> + chip->suspended = true;
> +
> + mutex_unlock(&chip->lock);
> + return 0;
> +}
> +
> +static int isl29018_resume(struct device *dev)
> +{
> + struct isl29018_chip *chip = iio_priv(dev_get_drvdata(dev));
> + int err;
> +
> + mutex_lock(&chip->lock);
> +
> + err = isl29018_chip_init(chip);
> + if (!err)
> + chip->suspended = false;
> +
> + mutex_unlock(&chip->lock);
> + return err;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(isl29018_pm_ops, isl29018_suspend, isl29018_resume);
> +#define ISL29018_PM_OPS (&isl29018_pm_ops)
> +#else
> +#define ISL29018_PM_OPS NULL
> +#endif
> +
> static const struct i2c_device_id isl29018_id[] = {
> {"isl29018", 0},
> {}
> @@ -620,6 +664,7 @@ static struct i2c_driver isl29018_driver = {
> .class = I2C_CLASS_HWMON,
> .driver = {
> .name = "isl29018",
> + .pm = ISL29018_PM_OPS,
> .owner = THIS_MODULE,
> .of_match_table = isl29018_of_match,
> },
>
--
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 5/8] cgroup: remove CGRP_WAIT_ON_RMDIR, cgroup_exclude_rmdir() and cgroup_release_and_wakeup_rmdir()
(2012/10/31 13:22), Tejun Heo wrote:
> CGRP_WAIT_ON_RMDIR is another kludge which was added to make cgroup
> destruction rollback somewhat working. cgroup_rmdir() used to drain
> CSS references and CGRP_WAIT_ON_RMDIR and the associated waitqueue and
> helpers were used to allow the task performing rmdir to wait for the
> next relevant event.
>
> Unfortunately, the wait is visible to controllers too and the
> mechanism got exposed to memcg by 887032670d ("cgroup avoid permanent
> sleep at rmdir").
>
> Now that the draining and retries are gone, CGRP_WAIT_ON_RMDIR is
> unnecessary. Remove it and all the mechanisms supporting it. Note
> that memcontrol.c changes are essentially revert of 887032670d
> ("cgroup avoid permanent sleep at rmdir").
>
> Signed-off-by: Tejun Heo
> Cc: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
Hmm, ok...
> ---
> include/linux/cgroup.h | 21 -
> kernel/cgroup.c| 51
> --
> mm/memcontrol.c| 24 +---
> 3 files changed, 1 insertion(+), 95 deletions(-)
>
> diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
> index a309804..47868a8 100644
> --- a/include/linux/cgroup.h
> +++ b/include/linux/cgroup.h
> @@ -145,10 +145,6 @@ enum {
> /* Control Group requires release notifications to userspace */
> CGRP_NOTIFY_ON_RELEASE,
> /*
> - * A thread in rmdir() is wating for this cgroup.
> - */
> - CGRP_WAIT_ON_RMDIR,
> - /*
>* Clone cgroup values when creating a new child cgroup
>*/
> CGRP_CLONE_CHILDREN,
> @@ -412,23 +408,6 @@ int cgroup_task_count(const struct cgroup *cgrp);
> int cgroup_is_descendant(const struct cgroup *cgrp, struct task_struct
> *task);
>
> /*
> - * When the subsys has to access css and may add permanent refcnt to css,
> - * it should take care of racy conditions with rmdir(). Following set of
> - * functions, is for stop/restart rmdir if necessary.
> - * Because these will call css_get/put, "css" should be alive css.
> - *
> - * cgroup_exclude_rmdir();
> - * ...do some jobs which may access arbitrary empty cgroup
> - * cgroup_release_and_wakeup_rmdir();
> - *
> - * When someone removes a cgroup while cgroup_exclude_rmdir() holds it,
> - * it sleeps and cgroup_release_and_wakeup_rmdir() will wake him up.
> - */
> -
> -void cgroup_exclude_rmdir(struct cgroup_subsys_state *css);
> -void cgroup_release_and_wakeup_rmdir(struct cgroup_subsys_state *css);
> -
> -/*
>* Control Group taskset, used to pass around set of tasks to cgroup_subsys
>* methods.
>*/
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index 66204a6..c5f6fb2 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -966,33 +966,6 @@ static void cgroup_d_remove_dir(struct dentry *dentry)
> }
>
> /*
> - * A queue for waiters to do rmdir() cgroup. A tasks will sleep when
> - * cgroup->count == 0 && list_empty(&cgroup->children) && subsys has some
> - * reference to css->refcnt. In general, this refcnt is expected to goes down
> - * to zero, soon.
> - *
> - * CGRP_WAIT_ON_RMDIR flag is set under cgroup's inode->i_mutex;
> - */
> -static DECLARE_WAIT_QUEUE_HEAD(cgroup_rmdir_waitq);
> -
> -static void cgroup_wakeup_rmdir_waiter(struct cgroup *cgrp)
> -{
> - if (unlikely(test_and_clear_bit(CGRP_WAIT_ON_RMDIR, &cgrp->flags)))
> - wake_up_all(&cgroup_rmdir_waitq);
> -}
> -
> -void cgroup_exclude_rmdir(struct cgroup_subsys_state *css)
> -{
> - css_get(css);
> -}
> -
> -void cgroup_release_and_wakeup_rmdir(struct cgroup_subsys_state *css)
> -{
> - cgroup_wakeup_rmdir_waiter(css->cgroup);
> - css_put(css);
> -}
> -
> -/*
>* Call with cgroup_mutex held. Drops reference counts on modules, including
>* any duplicate ones that parse_cgroupfs_options took. If this function
>* returns an error, no reference counts are touched.
> @@ -1963,12 +1936,6 @@ int cgroup_attach_task(struct cgroup *cgrp, struct
> task_struct *tsk)
> }
>
> synchronize_rcu();
> -
> - /*
> - * wake up rmdir() waiter. the rmdir should fail since the cgroup
> - * is no longer empty.
> - */
> - cgroup_wakeup_rmdir_waiter(cgrp);
> out:
> if (retval) {
> for_each_subsys(root, ss) {
> @@ -2138,7 +2105,6 @@ static int cgroup_attach_proc(struct cgroup *cgrp,
> struct task_struct *leader)
>* step 5: success! and cleanup
>*/
> synchronize_rcu();
> - cgroup_wakeup_rmdir_waiter(cgrp);
> retval = 0;
> out_put_css_set_refs:
> if (retval) {
> @@ -4058,26 +4024,13 @@ static int cgroup_rmdir(struct inode *unused_dir,
> struct dentry *dentry)
> struct cgroup_event *event, *tmp;
> struct cgroup_subsys *ss;
>
> - /*
> - * In general, subsystem has no css->refcnt after pre_destroy(). But
> - * in racy cases, subsystem may have to get css->refcnt after
> - * pre_destroy() an
Re: [PATCH 6/8] memcg: make mem_cgroup_reparent_charges non failing
(2012/10/31 13:22), Tejun Heo wrote:
> From: Michal Hocko
>
> Now that pre_destroy callbacks are called from the context where neither
> any task can attach the group nor any children group can be added there
> is no other way to fail from mem_cgroup_pre_destroy.
> mem_cgroup_pre_destroy doesn't have to take a reference to memcg's css
> because all css' are marked dead already.
>
> tj: Remove now unused local variable @cgrp from
> mem_cgroup_reparent_charges().
>
> Signed-off-by: Michal Hocko
> Reviewed-by: Glauber Costa
> Signed-off-by: Tejun Heo
+1
Acked-by: KAMEZAWA Hiroyuki
> ---
> mm/memcontrol.c | 19 ++-
> 1 file changed, 6 insertions(+), 13 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 1033b2b..47c4680 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3740,14 +3740,11 @@ static void mem_cgroup_force_empty_list(struct
> mem_cgroup *memcg,
>*
>* Caller is responsible for holding css reference on the memcg.
>*/
> -static int mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
> +static void mem_cgroup_reparent_charges(struct mem_cgroup *memcg)
> {
> - struct cgroup *cgrp = memcg->css.cgroup;
> int node, zid;
>
> do {
> - if (cgroup_task_count(cgrp) || !list_empty(&cgrp->children))
> - return -EBUSY;
> /* This is for making all *used* pages to be on LRU. */
> lru_add_drain_all();
> drain_all_stock_sync(memcg);
> @@ -3773,8 +3770,6 @@ static int mem_cgroup_reparent_charges(struct
> mem_cgroup *memcg)
>* charge before adding to the LRU.
>*/
> } while (res_counter_read_u64(&memcg->res, RES_USAGE) > 0);
> -
> - return 0;
> }
>
> /*
> @@ -3811,7 +3806,9 @@ static int mem_cgroup_force_empty(struct mem_cgroup
> *memcg)
>
> }
> lru_add_drain();
> - return mem_cgroup_reparent_charges(memcg);
> + mem_cgroup_reparent_charges(memcg);
> +
> + return 0;
> }
>
> static int mem_cgroup_force_empty_write(struct cgroup *cont, unsigned int
> event)
> @@ -5008,13 +5005,9 @@ free_out:
> static int mem_cgroup_pre_destroy(struct cgroup *cont)
> {
> struct mem_cgroup *memcg = mem_cgroup_from_cont(cont);
> - int ret;
>
> - css_get(&memcg->css);
> - ret = mem_cgroup_reparent_charges(memcg);
> - css_put(&memcg->css);
> -
> - return ret;
> + mem_cgroup_reparent_charges(memcg);
> + return 0;
> }
>
> static void mem_cgroup_destroy(struct cgroup *cont)
>
--
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 7/8] hugetlb: do not fail in hugetlb_cgroup_pre_destroy
(2012/10/31 13:22), Tejun Heo wrote: > From: Michal Hocko > > Now that pre_destroy callbacks are called from the context where neither > any task can attach the group nor any children group can be added there > is no other way to fail from hugetlb_pre_destroy. > > Signed-off-by: Michal Hocko > Reviewed-by: Tejun Heo > Reviewed-by: Glauber Costa > Signed-off-by: Tejun Heo Acked-by: KAMEZAWA Hiroyuki -- 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: BUG: enabling psacct breaks fsfreeze
Il 01/11/2012 23:50, Jan Kara ha scritto: On Thu 01-11-12 15:23:25, Nikola Ciprich wrote: Nov 1 14:23:25 vmnci22 [ 1075.178123] SysRq : Show Blocked State Nov 1 14:23:25 vmnci22 [ 1075.180555] taskPC stack pid father Nov 1 14:23:25 vmnci22 [ 1075.180592] fsfreeze D 0 4215 4195 0x Nov 1 14:23:25 vmnci22 [ 1075.180599] 8800090b9b28 0046 Nov 1 14:23:25 vmnci22 [ 1075.180606] 00013780 8800090b9fd8 88000f716170 88000f715e80 Nov 1 14:23:25 vmnci22 [ 1075.180612] 88000f715dc0 81566080 88000f716170 00010002f405 Nov 1 14:23:25 vmnci22 [ 1075.180619] Call Trace: Nov 1 14:23:25 vmnci22 [ 1075.180693] [] __generic_file_aio_write+0xbb/0x420 Nov 1 14:23:25 vmnci22 [ 1075.180729] [] ? autoremove_wake_function+0x0/0x40 Nov 1 14:23:25 vmnci22 [ 1075.180736] [] generic_file_aio_write+0x5f/0xc0 Thanks. So the system isn't really deadlocked. It's just that fsfreeze command hangs, isn't it? OK, I understand that it's kind of incovenient situation because every command will hang like this when the filesystem is frozen. Now I only have to come up with a way to improve this... It isn't quite simple - to properly protect against freezing be have to communicate down into generic_file_aio_write() that we want to bail out if filesystem is frozen instead of waiting. Honza I saw this behavior (task-hang) when I tested the fsfreeze code. I was writing a little patch to replace fsfreeze's wait queue with a killable queue, in this way the user can do at least "kill -9", but since the behavior was the same before your patch I didn't send it. I don't know if we can break any previous behavior. The funny thing here is that it's like if fsfreeze freezes itself :) Marco -- 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 8/8] cgroup: make ->pre_destroy() return void
(2012/10/31 13:22), Tejun Heo wrote: > All ->pre_destory() implementations return 0 now, which is the only > allowed return value. Make it return void. > > Signed-off-by: Tejun Heo > Cc: Michal Hocko > Cc: Balbir Singh > Cc: KAMEZAWA Hiroyuki > Cc: Vivek Goyal Acked-by: KAMEZAWA Hiroyuki -- 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 1/2] kbuild: centralize .dts->.dtb rule
On Wed, Oct 31, 2012 at 04:10:30PM -0600, Stephen Warren wrote: > From: Stephen Warren > > All architectures that use cmd_dtc do so in the same way. Move the build > rule to a central location to avoid duplication. Can you fold these MIPS bits into your patch? Ralf Signed-off-by: Ralf Baechle arch/mips/cavium-octeon/Makefile | 3 --- arch/mips/netlogic/dts/Makefile | 3 --- 2 files changed, 6 deletions(-) diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile index bc96e29..6e927cf 100644 --- a/arch/mips/cavium-octeon/Makefile +++ b/arch/mips/cavium-octeon/Makefile @@ -24,9 +24,6 @@ DTB_FILES = $(patsubst %.dts, %.dtb, $(DTS_FILES)) obj-y += $(patsubst %.dts, %.dtb.o, $(DTS_FILES)) -$(obj)/%.dtb: $(src)/%.dts FORCE - $(call if_changed_dep,dtc) - # Let's keep the .dtb files around in case we want to look at them. .SECONDARY: $(addprefix $(obj)/, $(DTB_FILES)) diff --git a/arch/mips/netlogic/dts/Makefile b/arch/mips/netlogic/dts/Makefile index 67ae3fe2..d117d46 100644 --- a/arch/mips/netlogic/dts/Makefile +++ b/arch/mips/netlogic/dts/Makefile @@ -1,4 +1 @@ obj-$(CONFIG_DT_XLP_EVP) := xlp_evp.dtb.o - -$(obj)/%.dtb: $(obj)/%.dts - $(call if_changed,dtc) -- 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/8] cgroup: kill cgroup_subsys->__DEPRECATED_clear_css_refs
(2012/11/01 5:24), Tejun Heo wrote:
On Wed, Oct 31, 2012 at 09:14:16PM +0100, Michal Hocko wrote:
On Wed 31-10-12 13:11:02, Tejun Heo wrote:
Hello,
On Wed, Oct 31, 2012 at 1:08 PM, Michal Hocko wrote:
local_irq_disable doesn't guarantee atomicity, because other CPUs will
Maybe it should say atomicity on the local CPU.
That would be more clear but being more verbose doesn't hurt either :P
see the change in steps so this is a bit misleading. The real reason
AFAICS is that we do not want to hang in css_tryget from IRQ context
(does this really happen btw.?) which would interrupt cgroup_rmdir
between we add CSS_DEACT_BIAS and the group is marked CGRP_REMOVED.
Or am I still missing the point?
Yeah, that's the correct one. We don't want tryget happening between
DEACT_BIAS and REMOVED as it can hang forever there.
Here's the updated description. git branch updated accordingly.
Thanks.
From: Tejun Heo
Subject: cgroup: kill cgroup_subsys->__DEPRECATED_clear_css_refs
2ef37d3fe4 ("memcg: Simplify mem_cgroup_force_empty_list error
handling") removed the last user of __DEPRECATED_clear_css_refs. This
patch removes __DEPRECATED_clear_css_refs and mechanisms to support
it.
* Conditionals dependent on __DEPRECATED_clear_css_refs removed.
* cgroup_clear_css_refs() can no longer fail. All that needs to be
done are deactivating refcnts, setting CSS_REMOVED and putting the
base reference on each css. Remove cgroup_clear_css_refs() and the
failure path, and open-code the loops into cgroup_rmdir().
This patch keeps the two for_each_subsys() loops separate while open
coding them. They can be merged now but there are scheduled changes
which need them to be separate, so keep them separate to reduce the
amount of churn.
local_irq_save/restore() from cgroup_clear_css_refs() are replaced
with local_irq_disable/enable() for simplicity. This is safe as
cgroup_rmdir() is always called with IRQ enabled. Note that this IRQ
switching is necessary to ensure that css_tryget() isn't called from
IRQ context on the same CPU while lower context is between CSS
deactivation and setting CSS_REMOVED as css_tryget() would hang
forever in such cases waiting for CSS to be re-activated or
CSS_REMOVED set. This will go away soon.
v2: cgroup_call_pre_destroy() removal dropped per Michal. Commit
message updated to explain local_irq_disable/enable() conversion.
Signed-off-by: Tejun Heo
Reviewed-by: Michal Hocko
I should see this v2 thread 1st...
Reviewed-by: KAMEZAWA Hiroyuki
--
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/8] cgroup: kill CSS_REMOVED
(2012/11/01 4:44), Tejun Heo wrote: > CSS_REMOVED is one of the several contortions which were necessary to > support css reference draining on cgroup removal. All css->refcnts > which need draining should be deactivated and verified to equal zero > atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts > needed to be re-activated and css_tryget() shouldn't fail in the > process. > > This was achieved by letting css_tryget() busy-loop until either the > refcnt is reactivated (failed removal attempt) or CSS_REMOVED is set > (committing to removal). > > Now that css refcnt draining is no longer used, there's no need for > atomic rollback mechanism. css_tryget() simply can look at the > reference count and fail if it's deactivated - it's never getting > re-activated. > > This patch removes CSS_REMOVED and updates __css_tryget() to fail if > the refcnt is deactivated. As deactivation and removal are a single > step now, they no longer need to be protected against css_tryget() > happening from irq context. Remove local_irq_disable/enable() from > cgroup_rmdir(). > > Note that this removes css_is_removed() whose only user is VM_BUG_ON() > in memcontrol.c. We can replace it with a check on the refcnt but > given that the only use case is a debug assert, I think it's better to > simply unexport it. > > v2: Comment updated and explanation on local_irq_disable/enable() > added per Michal Hocko. > > Signed-off-by: Tejun Heo > Reviewed-by: Michal Hocko > Cc: Johannes Weiner > Cc: Balbir Singh > Cc: KAMEZAWA Hiroyuki Thank you. Reviewed-by: KAMEZAWA Hiroyuki -- 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/8] cgroup: use cgroup_lock_live_group(parent) in cgroup_create()
(2012/11/01 4:44), Tejun Heo wrote: > This patch makes cgroup_create() fail if @parent is marked removed. > This is to prepare for further updates to cgroup_rmdir() path. > > Note that this change isn't strictly necessary. cgroup can only be > created via mkdir and the removed marking and dentry removal happen > without releasing cgroup_mutex, so cgroup_create() can never race with > cgroup_rmdir(). Even after the scheduled updates to cgroup_rmdir(), > cgroup_mkdir() and cgroup_rmdir() are synchronized by i_mutex > rendering the added liveliness check unnecessary. > > Do it anyway such that locking is contained inside cgroup proper and > we don't get nasty surprises if we ever grow another caller of > cgroup_create(). > > Signed-off-by: Tejun Heo > Reviewed-by: Michal Hocko Reviewed-by: KAMEZAWA Hiroyuki -- 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/8] cgroup: deactivate CSS's and mark cgroup dead before invoking ->pre_destroy()
(2012/11/01 4:44), Tejun Heo wrote: > Because ->pre_destroy() could fail and can't be called under > cgroup_mutex, cgroup destruction did something very ugly. > >1. Grab cgroup_mutex and verify it can be destroyed; fail otherwise. > >2. Release cgroup_mutex and call ->pre_destroy(). > >3. Re-grab cgroup_mutex and verify it can still be destroyed; fail > otherwise. > >4. Continue destroying. > > In addition to being ugly, it has been always broken in various ways. > For example, memcg ->pre_destroy() expects the cgroup to be inactive > after it's done but tasks can be attached and detached between #2 and > #3 and the conditions that memcg verified in ->pre_destroy() might no > longer hold by the time control reaches #3. > > Now that ->pre_destroy() is no longer allowed to fail. We can switch > to the following. > >1. Grab cgroup_mutex and verify it can be destroyed; fail otherwise. > >2. Deactivate CSS's and mark the cgroup removed thus preventing any > further operations which can invalidate the verification from #1. > >3. Release cgroup_mutex and call ->pre_destroy(). > >4. Re-grab cgroup_mutex and continue destroying. > > After this change, controllers can safely assume that ->pre_destroy() > will only be called only once for a given cgroup and, once > ->pre_destroy() is called, the cgroup will stay dormant till it's > destroyed. > > This removes the only reason ->pre_destroy() can fail - new task being > attached or child cgroup being created inbetween. Error out path is > removed and ->pre_destroy() invocation is open coded in > cgroup_rmdir(). > > v2: cgroup_call_pre_destroy() removal moved to this patch per Michal. > Commit message updated per Glauber. > > Signed-off-by: Tejun Heo > Reviewed-by: Michal Hocko > Cc: Glauber Costa Reviewed-by: KAMEZAWA Hiroyuki -- 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] iio: hid-sensor: Use __devexit annotation for remove()
On 10/27/2012 03:48 PM, Axel Lin wrote:
> Use __devexit rather than __devinit annotation for remove().
> Also adds __devexit_p around remove callback.
>
> Signed-off-by: Axel Lin
Added to fixes-togreg branch of iio.git
oops on this one. Should have picked that up in review.
Thanks Axel!
> ---
> drivers/iio/accel/hid-sensor-accel-3d.c |4 ++--
> drivers/iio/gyro/hid-sensor-gyro-3d.c |4 ++--
> drivers/iio/light/hid-sensor-als.c|4 ++--
> drivers/iio/magnetometer/hid-sensor-magn-3d.c |4 ++--
> 4 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c
> b/drivers/iio/accel/hid-sensor-accel-3d.c
> index 314a405..1b49931 100644
> --- a/drivers/iio/accel/hid-sensor-accel-3d.c
> +++ b/drivers/iio/accel/hid-sensor-accel-3d.c
> @@ -388,7 +388,7 @@ error_ret:
> }
>
> /* Function to deinitialize the processing for usage id */
> -static int __devinit hid_accel_3d_remove(struct platform_device *pdev)
> +static int __devexit hid_accel_3d_remove(struct platform_device *pdev)
> {
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> @@ -409,7 +409,7 @@ static struct platform_driver
> hid_accel_3d_platform_driver = {
> .owner = THIS_MODULE,
> },
> .probe = hid_accel_3d_probe,
> - .remove = hid_accel_3d_remove,
> + .remove = __devexit_p(hid_accel_3d_remove),
> };
> module_platform_driver(hid_accel_3d_platform_driver);
>
> diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> index 4c56ada..705dc49 100644
> --- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> +++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> @@ -388,7 +388,7 @@ error_ret:
> }
>
> /* Function to deinitialize the processing for usage id */
> -static int __devinit hid_gyro_3d_remove(struct platform_device *pdev)
> +static int __devexit hid_gyro_3d_remove(struct platform_device *pdev)
> {
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> @@ -409,7 +409,7 @@ static struct platform_driver hid_gyro_3d_platform_driver
> = {
> .owner = THIS_MODULE,
> },
> .probe = hid_gyro_3d_probe,
> - .remove = hid_gyro_3d_remove,
> + .remove = __devexit_p(hid_gyro_3d_remove),
> };
> module_platform_driver(hid_gyro_3d_platform_driver);
>
> diff --git a/drivers/iio/light/hid-sensor-als.c
> b/drivers/iio/light/hid-sensor-als.c
> index 96e3691..4c35ac7 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -355,7 +355,7 @@ error_ret:
> }
>
> /* Function to deinitialize the processing for usage id */
> -static int __devinit hid_als_remove(struct platform_device *pdev)
> +static int __devexit hid_als_remove(struct platform_device *pdev)
> {
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> @@ -376,7 +376,7 @@ static struct platform_driver hid_als_platform_driver = {
> .owner = THIS_MODULE,
> },
> .probe = hid_als_probe,
> - .remove = hid_als_remove,
> + .remove = __devexit_p(hid_als_remove),
> };
> module_platform_driver(hid_als_platform_driver);
>
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index c4f0d27..a02dc98 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> @@ -389,7 +389,7 @@ error_ret:
> }
>
> /* Function to deinitialize the processing for usage id */
> -static int __devinit hid_magn_3d_remove(struct platform_device *pdev)
> +static int __devexit hid_magn_3d_remove(struct platform_device *pdev)
> {
> struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data;
> struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> @@ -410,7 +410,7 @@ static struct platform_driver hid_magn_3d_platform_driver
> = {
> .owner = THIS_MODULE,
> },
> .probe = hid_magn_3d_probe,
> - .remove = hid_magn_3d_remove,
> + .remove = __devexit_p(hid_magn_3d_remove),
> };
> module_platform_driver(hid_magn_3d_platform_driver);
>
>
--
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] iio: hid-sensor: Return proper error if kmemdup fails
On 10/27/2012 04:03 PM, Axel Lin wrote:
> Return -ENOMEM instead of 0 if kmemdup fails.
>
> Signed-off-by: Axel Lin
Added to fixes-togreg branch of iio.git
Thanks
> ---
> drivers/iio/accel/hid-sensor-accel-3d.c |6 +++---
> drivers/iio/gyro/hid-sensor-gyro-3d.c |6 +++---
> drivers/iio/light/hid-sensor-als.c|5 ++---
> drivers/iio/magnetometer/hid-sensor-magn-3d.c |6 +++---
> 4 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c
> b/drivers/iio/accel/hid-sensor-accel-3d.c
> index 1b49931..2046208 100644
> --- a/drivers/iio/accel/hid-sensor-accel-3d.c
> +++ b/drivers/iio/accel/hid-sensor-accel-3d.c
> @@ -319,10 +319,10 @@ static int __devinit hid_accel_3d_probe(struct
> platform_device *pdev)
> goto error_free_dev;
> }
>
> - channels = kmemdup(accel_3d_channels,
> - sizeof(accel_3d_channels),
> - GFP_KERNEL);
> + channels = kmemdup(accel_3d_channels, sizeof(accel_3d_channels),
> +GFP_KERNEL);
> if (!channels) {
> + ret = -ENOMEM;
> dev_err(&pdev->dev, "failed to duplicate channels\n");
> goto error_free_dev;
> }
> diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> index 705dc49..c93dd59 100644
> --- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
> +++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
> @@ -319,10 +319,10 @@ static int __devinit hid_gyro_3d_probe(struct
> platform_device *pdev)
> goto error_free_dev;
> }
>
> - channels = kmemdup(gyro_3d_channels,
> - sizeof(gyro_3d_channels),
> - GFP_KERNEL);
> + channels = kmemdup(gyro_3d_channels, sizeof(gyro_3d_channels),
> +GFP_KERNEL);
> if (!channels) {
> + ret = -ENOMEM;
> dev_err(&pdev->dev, "failed to duplicate channels\n");
> goto error_free_dev;
> }
> diff --git a/drivers/iio/light/hid-sensor-als.c
> b/drivers/iio/light/hid-sensor-als.c
> index 4c35ac7..ea59daa 100644
> --- a/drivers/iio/light/hid-sensor-als.c
> +++ b/drivers/iio/light/hid-sensor-als.c
> @@ -285,10 +285,9 @@ static int __devinit hid_als_probe(struct
> platform_device *pdev)
> goto error_free_dev;
> }
>
> - channels = kmemdup(als_channels,
> - sizeof(als_channels),
> - GFP_KERNEL);
> + channels = kmemdup(als_channels, sizeof(als_channels), GFP_KERNEL);
> if (!channels) {
> + ret = -ENOMEM;
> dev_err(&pdev->dev, "failed to duplicate channels\n");
> goto error_free_dev;
> }
> diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> index a02dc98..63d0a38 100644
> --- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> +++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
> @@ -320,10 +320,10 @@ static int __devinit hid_magn_3d_probe(struct
> platform_device *pdev)
> goto error_free_dev;
> }
>
> - channels = kmemdup(magn_3d_channels,
> - sizeof(magn_3d_channels),
> - GFP_KERNEL);
> + channels = kmemdup(magn_3d_channels, sizeof(magn_3d_channels),
> +GFP_KERNEL);
> if (!channels) {
> + ret = -ENOMEM;
> dev_err(&pdev->dev, "failed to duplicate channels\n");
> goto error_free_dev;
> }
>
--
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 3/3] lp8788-charger: fix wrong ADC conversion
On 10/19/2012 01:45 PM, Lars-Peter Clausen wrote:
> On 10/19/2012 02:12 AM, Kim, Milo wrote:
>> To get the battery voltage and temperature, IIO ADC functions are used.
>> LP8788 ADC driver provides RAW and SCALE channel information.
>> This patch fixes wrong ADC result.
>>
>> Patch v2.
>> Use simple iio_read_channel_processed() function rather than
>> iio_read_channel_raw() and _scale().
>>
>> Fix the result type of ADC function as a signed integer.
>> Because power_supply_propval.intval and the return value of
>> iio_read_channel_processed() are a signed integer,
>> 'unsigned int' are replaced with 'int'.
>>
>> Patch v1.
>> Fix wrong ADC results using iio_read_channel_raw() and _scale().
>>
>> Signed-off-by: Milo(Woogyom) Kim
>
> Looks good to me, fwiw:
>
> Reviewed-by Lars-Peter Clausen
On this stuff as far as I'm concerned Lars' approval is fine but
for what it's worth this all looks fine to me.
Acked-by: Jonathan Cameron
>
> But there is one issue, but this is not necessarily related to this patch,
> more inline.
>
>> ---
>> drivers/power/lp8788-charger.c | 26 +++---
>> 1 file changed, 7 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/power/lp8788-charger.c b/drivers/power/lp8788-charger.c
>> index 02fc9ab..f18ec8f 100644
>> --- a/drivers/power/lp8788-charger.c
>> +++ b/drivers/power/lp8788-charger.c
>> @@ -235,25 +235,14 @@ static int lp8788_get_battery_present(struct
>> lp8788_charger *pchg,
>> return 0;
>> }
>>
> [...]
>> static int lp8788_get_battery_voltage(struct lp8788_charger *pchg,
>> @@ -268,7 +257,7 @@ static int lp8788_get_battery_capacity(struct
>> lp8788_charger *pchg,
>> struct lp8788 *lp = pchg->lp;
>> struct lp8788_charger_platform_data *pdata = pchg->pdata;
>> unsigned int max_vbatt;
>> -unsigned int vbatt;
>> +int vbatt;
>> enum lp8788_charging_state state;
>> u8 data;
>> int ret;
>> @@ -304,19 +293,18 @@ static int lp8788_get_battery_temperature(struct
>> lp8788_charger *pchg,
>> union power_supply_propval *val)
>> {
>> struct iio_channel *channel = pchg->chan[LP8788_BATT_TEMP];
>> -int scaleint;
>> -int scalepart;
>> +int result;
>> int ret;
>>
>> if (!channel)
>> return -EINVAL;
>>
>> -ret = iio_read_channel_scale(channel, &scaleint, &scalepart);
>> -if (ret != IIO_VAL_INT_PLUS_MICRO)
>> +ret = iio_read_channel_processed(channel, &result);
>> +if (ret < 0)
>> return -EINVAL;
>>
>> /* unit: 0.1 'C */
>> -val->intval = (scaleint + scalepart * 100) / 100;
>> +val->intval = result * 10;
>
> IIO reports temperatures in milli degree Celsius. So it should be multiplied
> by 100 to get tenth degree like the power supply framework expects it. But
> this might be a issue in your IIO driver reporting the wrong scale.
>
> - Lars
>
>>
>> return 0;
>> }
>
--
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] xfs: silence GCC warning
Building xfs_ioctl.o triggers this GCC warning:
In file included from fs/xfs/xfs_linux.h:49:0,
from fs/xfs/xfs.h:27,
from fs/xfs/xfs_ioctl.c:18:
fs/xfs/xfs_ioctl.c: In function ‘xfs_find_handle’:
include/linux/file.h:37:7: warning: ‘f.file’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
fs/xfs/xfs_ioctl.c:73:13: note: ‘f.file’ was declared here
In this function 'f' and ('f.file') are only used for the
XFS_IOC_FD_TO_HANDLE command. It is clear that 'f.file' is always used
initialized, but there appears to be no easy way to give GCC enough
information to determine that. So let's silence this warning, using the
pattern Ingo Molnar recently suggested.
Signed-off-by: Paul Bolle
---
0) Compile tested only.
1) I fear that the only way to give GCC the information it needs to do
the flow analysis correctly is to split xfs_find_handle() into three
separate functions, one for each command it handles, and add one or two
helper functions for the code common to all three functions. That seemed
a bit drastic. But perhaps we should try that.
fs/xfs/xfs_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index 8305f2a..5c98ce3 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -70,7 +70,7 @@ xfs_find_handle(
int hsize;
xfs_handle_thandle;
struct inode*inode;
- struct fd f;
+ struct fd f = { }; /* Avoid GCC warning */
struct path path;
int error;
struct xfs_inode*ip;
--
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/
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Op 2 nov. 2012, om 10:26 heeft "Cousson, Benoit" het
volgende geschreven:
> Hi Jason,
>
> On 11/1/2012 7:50 PM, Jason Kridner wrote:
>> My apologies for starting a new thread, but I don't have this thread
>> in my Inbox.
>>
>> http://www.spinics.net/lists/linux-omap/msg81034.html
>>
>> Tony Lindgren wrote:
>>
>>> * Pantelis Antoniou [121031 15:02]:
So when device's node is 'disabled' of_platform_device_create_pdata()
will not create the device.
Now, of course it is possible to re-trigger the platform's probe method
to be called, and in fact I do so in the capebus patches.
>>>
>>> You should fix this in generic way then rather than working
>>> around it in capebus. The same problem exists changing
>>> between different functionality for the shared pins,
>>> let's say between USB pins and UART pins if you want a
>>> serial debug console on some phone.
>>
>> The current capebus solution goes a long way to fixing a huge issue
>> for BeagleBone users and I don't understand what seems to be a
>> push-back on principle. On BeagleBone capes, these conflicts cannot be
>> resolved early.
>
> I don't think there is any push-back on the principle. It is a very valid
> problem that does not have any solution today.
>
> The comments are more on the implementation.
>
>> Do you have suggestions on some more generic method? It seems to me
>> the proposed capebus approach strikes a good balance.
>
> Well, yeah, that's a generic DT issue, not a beagle-cape issue.
> We should not necessarily handle it by introducing some fake bus and some new
> binding like spi-dt / i2c-dt that does not mean anything in term of HW.
>
> DT is about pure HW representation. Introducing some fake hierarchy to make
> SW life easier is not necessarily the good approach.
I see, pure HW. Let's look at this:
gpio_keys {
compatible = "gpio-keys";
pinctrl-names = "default";
pinctrl-0 = <&bone_lcd3_cape_keys_00A0_pins>;
#address-cells = <1>;
#size-cells = <0>;
button@1 {
debounce_interval = <50>;
linux,code = <105>;
label = "left";
gpios = <&gpio2 16 0x0>;
gpio-key,wakeup;
autorepeat;
};
Is the "linux,code" pure hardware or have there already been exceptions to that
rule?
regards,
Koen--
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 5/8] cgroup: remove CGRP_WAIT_ON_RMDIR, cgroup_exclude_rmdir() and cgroup_release_and_wakeup_rmdir()
(2012/11/01 4:44), Tejun Heo wrote:
> CGRP_WAIT_ON_RMDIR is another kludge which was added to make cgroup
> destruction rollback somewhat working. cgroup_rmdir() used to drain
> CSS references and CGRP_WAIT_ON_RMDIR and the associated waitqueue and
> helpers were used to allow the task performing rmdir to wait for the
> next relevant event.
>
> Unfortunately, the wait is visible to controllers too and the
> mechanism got exposed to memcg by 887032670d ("cgroup avoid permanent
> sleep at rmdir").
>
> Now that the draining and retries are gone, CGRP_WAIT_ON_RMDIR is
> unnecessary. Remove it and all the mechanisms supporting it. Note
> that memcontrol.c changes are essentially revert of 887032670d
> ("cgroup avoid permanent sleep at rmdir").
>
> Signed-off-by: Tejun Heo
> Reviewed-by: Michal Hocko
> Cc: Balbir Singh
> Cc: KAMEZAWA Hiroyuki
plz forget my comments on v1...But...
If swap-in makes a charge before css is deactivated,
pre_destroy()->force_empty()
will cause infinite loop until it finds a newly charged page in LRU. I think
force_empty() will find it by lru_drain() and can make res_coutnter to be 0.
I think we need some test with swap-in handling..Anyway,
Reviewed-by: KAMEZAWA Hiroyuki
--
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: [PATCHv7 4/4] virtio_console: Add support for remoteproc serial
On (Fri) 02 Nov 2012 [09:52:08], Rusty Russell wrote:
> Amit Shah writes:
> > On (Tue) 23 Oct 2012 [12:17:49], Rusty Russell wrote:
> >> sjur.brandel...@stericsson.com writes:
> >> > From: Sjur Brændeland
> >
> >> > @@ -1415,7 +1524,16 @@ static void remove_port_data(struct port *port)
> >> >
> >> > /* Remove buffers we queued up for the Host to send us data in.
> >> > */
> >> > while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
> >> > -free_buf(buf);
> >> > +free_buf(buf, true);
> >> > +
> >> > +/*
> >> > + * Remove buffers from out queue for rproc-serial. We cannot
> >> > afford
> >> > + * to leak any DMA mem, so reclaim this memory even if this
> >> > might be
> >> > + * racy for the remote processor.
> >> > + */
> >> > +if (is_rproc_serial(port->portdev->vdev))
> >> > +while ((buf =
> >> > virtqueue_detach_unused_buf(port->out_vq)))
> >> > +free_buf(buf, true);
> >> > }
> >>
> >> This seems wrong; either this is needed even if !is_rproc_serial(), or
> >> it's not necessary as the out_vq is empty.
> >>
> >> Every path I can see has the device reset (in which case the queues
> >> should not be active), or we got a VIRTIO_CONSOLE_PORT_REMOVE event (in
> >> which case, the same).
> >>
> >> I think we can have non-blocking writes which could leave buffers in
> >> out_vq: Amit?
> >
> > Those get 'reclaimed' just above this hunk:
> >
> >
> > static void remove_port_data(struct port *port)
> > {
> > struct port_buffer *buf;
> >
> > /* Remove unused data this port might have received. */
> > discard_port_data(port);
> >
> > reclaim_consumed_buffers(port);
> >
> > /* Remove buffers we queued up for the Host to send us data in. */
> > while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
> > free_buf(buf, true);
>
> No, that's pending input buffers, not output buffers.
You're right. Nice catch.
Sjur, can you remove the WARN_ON in your latest series, even generic
ports may have buffers in the outq.
It'll also need to be done in the port_fops_release() function. Let
me know if you prefer I send a patch instead.
Thanks,
Amit
--
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] memcg: fix hotplugged memory zone oops
On Thu 01-11-12 18:28:02, Hugh Dickins wrote:
> When MEMCG is configured on (even when it's disabled by boot option),
> when adding or removing a page to/from its lru list, the zone pointer
> used for stats updates is nowadays taken from the struct lruvec.
> (On many configurations, calculating zone from page is slower.)
>
> But we have no code to update all the lruvecs (per zone, per memcg)
> when a memory node is hotadded. Here's an extract from the oops which
> results when running numactl to bind a program to a newly onlined node:
>
> BUG: unable to handle kernel NULL pointer dereference at 0f60
> IP: [] __mod_zone_page_state+0x9/0x60
> PGD 0
> Oops: [#1] SMP
> CPU 2
> Pid: 1219, comm: numactl Not tainted 3.6.0-rc5+ #180 Bochs Bochs
> Process numactl (pid: 1219, threadinfo 880039abc000, task
> 8800383c4ce0)
> Stack:
> 880039abdaf8 8117390f 880039abdaf8 8167c601
> 81174162 88003a480f00 0001 8800395e
> 88003dbd0e80 0282 880039abdb48 81174181
> Call Trace:
> [] __pagevec_lru_add_fn+0xdf/0x140
> [] pagevec_lru_move_fn+0xb1/0x100
> [] __pagevec_lru_add+0x1c/0x30
> [] lru_add_drain_cpu+0xa3/0x130
> [] lru_add_drain+0x2f/0x40
> ...
>
> The natural solution might be to use a memcg callback whenever memory
> is hotadded; but that solution has not been scoped out, and it happens
> that we do have an easy location at which to update lruvec->zone. The
> lruvec pointer is discovered either by mem_cgroup_zone_lruvec() or by
> mem_cgroup_page_lruvec(), and both of those do know the right zone.
>
> So check and set lruvec->zone in those; and remove the inadequate
> attempt to set lruvec->zone from lruvec_init(), which is called
> before NODE_DATA(node) has been allocated in such cases.
>
> Ah, there was one exceptionr. For no particularly good reason,
> mem_cgroup_force_empty_list() has its own code for deciding lruvec.
> Change it to use the standard mem_cgroup_zone_lruvec() and
> mem_cgroup_get_lru_size() too. In fact it was already safe against
> such an oops (the lru lists in danger could only be empty),
> but we're better proofed against future changes this way.
>
> Reported-by: Tang Chen
> Signed-off-by: Hugh Dickins
> Acked-by: Johannes Weiner
> Acked-by: KAMEZAWA Hiroyuki
> Cc: Konstantin Khlebnikov
> Cc: Wen Congyang
> Cc: sta...@vger.kernel.org
OK, it adds "an overhead" also when there is no hotadd going on but this
is just one additional mem access&cmp&je so it shouldn't be noticable
(lruvec->zone is used most of the time later so it not a pointless
load).
It is also easier to backport for stable. But is there any reason to fix
it later properly in the hotadd hook?
Anyway
Acked-by: Michal Hocko
Thanks!
> ---
> I've marked this for stable (3.6) since we introduced the problem
> in 3.5 (now closed to stable); but I have no idea if this is the
> only fix needed to get memory hotadd working with memcg in 3.6,
> and received no answer when I enquired twice before.
>
> include/linux/mmzone.h |2 -
> mm/memcontrol.c| 46 +--
> mm/mmzone.c|6 -
> mm/page_alloc.c|2 -
> 4 files changed, 38 insertions(+), 18 deletions(-)
>
> --- 3.7-rc3/include/linux/mmzone.h2012-10-14 16:16:57.665308933 -0700
> +++ linux/include/linux/mmzone.h 2012-11-01 14:31:04.284185741 -0700
> @@ -752,7 +752,7 @@ extern int init_currently_empty_zone(str
>unsigned long size,
>enum memmap_context context);
>
> -extern void lruvec_init(struct lruvec *lruvec, struct zone *zone);
> +extern void lruvec_init(struct lruvec *lruvec);
>
> static inline struct zone *lruvec_zone(struct lruvec *lruvec)
> {
> --- 3.7-rc3/mm/memcontrol.c 2012-10-14 16:16:58.341309118 -0700
> +++ linux/mm/memcontrol.c 2012-11-01 14:31:04.284185741 -0700
> @@ -1055,12 +1055,24 @@ struct lruvec *mem_cgroup_zone_lruvec(st
> struct mem_cgroup *memcg)
> {
> struct mem_cgroup_per_zone *mz;
> + struct lruvec *lruvec;
>
> - if (mem_cgroup_disabled())
> - return &zone->lruvec;
> + if (mem_cgroup_disabled()) {
> + lruvec = &zone->lruvec;
> + goto out;
> + }
>
> mz = mem_cgroup_zoneinfo(memcg, zone_to_nid(zone), zone_idx(zone));
> - return &mz->lruvec;
> + lruvec = &mz->lruvec;
> +out:
> + /*
> + * Since a node can be onlined after the mem_cgroup was created,
> + * we have to be prepared to initialize lruvec->zone here;
> + * and if offlined then reonlined, we need to reinitialize it.
> + */
> + if (unlikely(lruvec->zone != zone))
> + lruvec->zone = zone;
> + return lruvec;
> }
>
> /*
> @@ -1087,9 +1099,12 @@ struct lruvec *mem_cgroup_page_lruvec(st
> struct mem_cgroup_per_zone *mz;
> struct mem_cgroup *m
Re: [PATCH 6/8] memcg: make mem_cgroup_reparent_charges non failing
(2012/11/01 4:44), Tejun Heo wrote: > From: Michal Hocko > > Now that pre_destroy callbacks are called from the context where neither > any task can attach the group nor any children group can be added there > is no other way to fail from mem_cgroup_pre_destroy. > mem_cgroup_pre_destroy doesn't have to take a reference to memcg's css > because all css' are marked dead already. > > tj: Remove now unused local variable @cgrp from > mem_cgroup_reparent_charges(). > > Signed-off-by: Michal Hocko > Reviewed-by: Glauber Costa > Signed-off-by: Tejun Heo Acked-by: KAMEZAWA Hiroyuki -- 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 7/8] hugetlb: do not fail in hugetlb_cgroup_pre_destroy
(2012/11/01 4:44), Tejun Heo wrote: > From: Michal Hocko > > Now that pre_destroy callbacks are called from the context where neither > any task can attach the group nor any children group can be added there > is no other way to fail from hugetlb_pre_destroy. > > Signed-off-by: Michal Hocko > Reviewed-by: Tejun Heo > Reviewed-by: Glauber Costa > Signed-off-by: Tejun Heo Acked-by: KAMEZAWA Hiroyuki -- 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 1/2] kbuild: centralize .dts->.dtb rule
On Fri, Nov 02, 2012 at 10:58:01AM +0100, Ralf Baechle wrote: > Can you fold these MIPS bits into your patch? I missed Lantiq. Ralf Signed-off-by: Ralf Baechle arch/mips/cavium-octeon/Makefile | 3 --- arch/mips/lantiq/dts/Makefile| 3 --- arch/mips/netlogic/dts/Makefile | 3 --- 3 files changed, 9 deletions(-) diff --git a/arch/mips/cavium-octeon/Makefile b/arch/mips/cavium-octeon/Makefile index bc96e29..6e927cf 100644 --- a/arch/mips/cavium-octeon/Makefile +++ b/arch/mips/cavium-octeon/Makefile @@ -24,9 +24,6 @@ DTB_FILES = $(patsubst %.dts, %.dtb, $(DTS_FILES)) obj-y += $(patsubst %.dts, %.dtb.o, $(DTS_FILES)) -$(obj)/%.dtb: $(src)/%.dts FORCE - $(call if_changed_dep,dtc) - # Let's keep the .dtb files around in case we want to look at them. .SECONDARY: $(addprefix $(obj)/, $(DTB_FILES)) diff --git a/arch/mips/lantiq/dts/Makefile b/arch/mips/lantiq/dts/Makefile index 674fca4..6fa72dd 100644 --- a/arch/mips/lantiq/dts/Makefile +++ b/arch/mips/lantiq/dts/Makefile @@ -1,4 +1 @@ obj-$(CONFIG_DT_EASY50712) := easy50712.dtb.o - -$(obj)/%.dtb: $(obj)/%.dts - $(call if_changed,dtc) diff --git a/arch/mips/netlogic/dts/Makefile b/arch/mips/netlogic/dts/Makefile index 67ae3fe2..d117d46 100644 --- a/arch/mips/netlogic/dts/Makefile +++ b/arch/mips/netlogic/dts/Makefile @@ -1,4 +1 @@ obj-$(CONFIG_DT_XLP_EVP) := xlp_evp.dtb.o - -$(obj)/%.dtb: $(obj)/%.dts - $(call if_changed,dtc) -- 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 8/8] cgroup: make ->pre_destroy() return void
(2012/11/01 4:44), Tejun Heo wrote: > All ->pre_destory() implementations return 0 now, which is the only > allowed return value. Make it return void. > > Signed-off-by: Tejun Heo > Cc: Michal Hocko > Cc: Balbir Singh > Cc: KAMEZAWA Hiroyuki > Cc: Vivek Goyal Thank you ! Acked-by: KAMEZAWA Hiroyuki -- 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 2/6] sched: add a new SD SHARE_POWERLINE flag for sched_domain
On Monday 29 October 2012 03:20 PM, Vincent Guittot wrote:
It looks like i need to describe more what
On 29 October 2012 10:40, Vincent Guittot wrote:
On 24 October 2012 17:17, Santosh Shilimkar wrote:
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
This new flag SD SHARE_POWERLINE reflects the sharing of the power rail
between the members of a domain. As this is the current assumption of the
scheduler, the flag is added to all sched_domain
Signed-off-by: Vincent Guittot
---
arch/ia64/include/asm/topology.h |1 +
arch/tile/include/asm/topology.h |1 +
include/linux/sched.h|1 +
include/linux/topology.h |3 +++
kernel/sched/core.c |5 +
5 files changed, 11 insertions(+)
diff --git a/arch/ia64/include/asm/topology.h
b/arch/ia64/include/asm/topology.h
index a2496e4..065c720 100644
--- a/arch/ia64/include/asm/topology.h
+++ b/arch/ia64/include/asm/topology.h
@@ -65,6 +65,7 @@ void build_cpu_to_node_map(void);
| SD_BALANCE_EXEC \
| SD_BALANCE_FORK \
| SD_WAKE_AFFINE, \
+ | arch_sd_share_power_line()\
.last_balance = jiffies, \
.balance_interval = 1,\
.nr_balance_failed = 0,\
diff --git a/arch/tile/include/asm/topology.h
b/arch/tile/include/asm/topology.h
index 7a7ce39..d39ed0b 100644
--- a/arch/tile/include/asm/topology.h
+++ b/arch/tile/include/asm/topology.h
@@ -72,6 +72,7 @@ static inline const struct cpumask *cpumask_of_node(int
node)
| 0*SD_PREFER_LOCAL \
| 0*SD_SHARE_CPUPOWER \
| 0*SD_SHARE_PKG_RESOURCES \
+ | arch_sd_share_power_line()\
| 0*SD_SERIALIZE\
, \
.last_balance = jiffies, \
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4786b20..74f2daf 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -862,6 +862,7 @@ enum cpu_idle_type {
#define SD_WAKE_AFFINE0x0020 /* Wake task to waking CPU
*/
#define SD_PREFER_LOCAL 0x0040 /* Prefer to keep tasks
local to this domain */
#define SD_SHARE_CPUPOWER 0x0080 /* Domain members share cpu power
*/
+#define SD_SHARE_POWERLINE 0x0100 /* Domain members share power
domain */
If you ignore the current use of SD_SHARE_CPUPOWER, isn't the meaning of
CPUPOWER and POWERLINE is same here. Just trying to understand the clear
meaning of this new flag. Have you not considered SD_SHARE_CPUPOWER
because it is being used for cpu_power and needs at least minimum two
domains ? SD_PACKING would have been probably more appropriate based
on the way it is being used in further series.
CPUPOWER reflects the share of hw ressources between cores like for
hyper threading. POWERLINE describes the fact that cores are sharing
the same power line amore precisely the powergate.
Sorry, the mail has been sent too early while I was writing it
CPUPOWER reflects the share of hw ressources between cores like for
hyper threading. POWERLINE describes the fact that cores are sharing
the same power line and more precisely the same power gating. It looks
like I need to describe more precisely what i would mean with
SHARE_POWERLINE.
Yes. More description will help. I see bit of overlap POWERLINE
flag with SD_SHARE_CPUPOWER and SD_SHARE_PKG_RESOURCES and hence
the questions.
I don't want to use PACKING because it's more a behavior than a
feature. If cores can power gate independently (!SD_SHARE_POWERLINE),
packing small tasks is one interesting behavior but it may be not the
only one. I want to make a difference between the HW configuration and
the behavior we want to have above it
Fair enough. Thanks for clarification.
Regards,
Santosh
--
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 02/25] perf tests: Move test objects into 'tests' directory
On Fri, Nov 02, 2012 at 10:48:57AM +0900, Namhyung Kim wrote: > Hi Jiri, > > Despite its way to acme's tree, I'd like to leave a few comments. :) > > > On Tue, 30 Oct 2012 23:01:43 +0100, Jiri Olsa wrote: > > Separating test objects into 'tests' directory. > > > > Signed-off-by: Jiri Olsa > > Cc: Arnaldo Carvalho de Melo > > Cc: Peter Zijlstra > > Cc: Ingo Molnar > > Cc: Paul Mackerras > > Cc: Corey Ashford > > Cc: Frederic Weisbecker > > --- > > tools/perf/Makefile |9 +- > > tools/perf/builtin-test.c | 1559 > > --- > > tools/perf/tests/builtin-test.c | 1559 > > +++ > > tools/perf/tests/dso-data.c | 153 > > tools/perf/tests/parse-events.c | 1116 + > > tools/perf/util/dso-test-data.c | 153 > > tools/perf/util/parse-events-test.c | 1116 - > > Looks like it should be considered as renames. Isn't 'git format-patch > -M' working? I can see it is.. nice ;) first time I hear about it.. > > > > 7 files changed, 2833 insertions(+), 2832 deletions(-) > > delete mode 100644 tools/perf/builtin-test.c > > create mode 100644 tools/perf/tests/builtin-test.c > > create mode 100644 tools/perf/tests/dso-data.c > > create mode 100644 tools/perf/tests/parse-events.c > > delete mode 100644 tools/perf/util/dso-test-data.c > > delete mode 100644 tools/perf/util/parse-events-test.c > > > > diff --git a/tools/perf/Makefile b/tools/perf/Makefile > > index 3e807d7..2d3427f 100644 > > --- a/tools/perf/Makefile > > +++ b/tools/perf/Makefile > > @@ -169,7 +169,7 @@ endif > > > > ### --- END CONFIGURATION SECTION --- > > > > -BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I$(OUTPUT)util > > -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 > > -D_GNU_SOURCE > > +BASIC_CFLAGS = -Iutil/include -Iarch/$(ARCH)/include -I$(OUTPUT)util > > -Iutil -I. -I$(TRACE_EVENT_DIR) -D_LARGEFILE64_SOURCE > > -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE > > Hmm.. Do you really want this? AFAIK there're lots of places that > include header files under the util directory and they used relative > path. I don't know how it affects them but at least they can be changed > to use simpler path with this change. [jolsa@krava perf]$ make O=$PWD/../build/ ... CC /home/jolsa/kernel.org/linux/tools/build/tests/parse-events.o tests/parse-events.c:2:26: fatal error: parse-events.h: No such file or directory yes, we could consolidate util includes globaly > > > > BASIC_LDFLAGS = > > > > ifeq ($(call try-cc,$(SOURCE_BIONIC),$(CFLAGS),bionic),y) > > @@ -371,7 +371,6 @@ LIB_OBJS += $(OUTPUT)util/help.o > > LIB_OBJS += $(OUTPUT)util/levenshtein.o > > LIB_OBJS += $(OUTPUT)util/parse-options.o > > LIB_OBJS += $(OUTPUT)util/parse-events.o > > -LIB_OBJS += $(OUTPUT)util/parse-events-test.o > > LIB_OBJS += $(OUTPUT)util/path.o > > LIB_OBJS += $(OUTPUT)util/rbtree.o > > LIB_OBJS += $(OUTPUT)util/bitmap.o > > @@ -389,7 +388,6 @@ LIB_OBJS += $(OUTPUT)util/sigchain.o > > LIB_OBJS += $(OUTPUT)util/dso.o > > LIB_OBJS += $(OUTPUT)util/symbol.o > > LIB_OBJS += $(OUTPUT)util/symbol-elf.o > > -LIB_OBJS += $(OUTPUT)util/dso-test-data.o > > LIB_OBJS += $(OUTPUT)util/color.o > > LIB_OBJS += $(OUTPUT)util/pager.o > > LIB_OBJS += $(OUTPUT)util/header.o > > @@ -430,6 +428,9 @@ LIB_OBJS += $(OUTPUT)ui/stdio/hist.o > > > > LIB_OBJS += $(OUTPUT)arch/common.o > > > > +LIB_OBJS += $(OUTPUT)tests/parse-events.o > > +LIB_OBJS += $(OUTPUT)tests/dso-data.o > > + > > Maybe TEST_OBJS? I guess they don't need to be included in libperf? I guess we could have NO_TESTS Makefile variable to disable tests and '[x] Tests' directory under make menuconfig ;) > > > > BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o > > BUILTIN_OBJS += $(OUTPUT)builtin-bench.o > > # Benchmark modules > > @@ -459,8 +460,8 @@ BUILTIN_OBJS += $(OUTPUT)builtin-probe.o > > BUILTIN_OBJS += $(OUTPUT)builtin-kmem.o > > BUILTIN_OBJS += $(OUTPUT)builtin-lock.o > > BUILTIN_OBJS += $(OUTPUT)builtin-kvm.o > > -BUILTIN_OBJS += $(OUTPUT)builtin-test.o > > BUILTIN_OBJS += $(OUTPUT)builtin-inject.o > > +BUILTIN_OBJS += $(OUTPUT)tests/builtin-test.o > > Placing builtin command in a different directory looks little bit odd. well, it's full of tests ;) maybe we could have those tests placed in separate files and use builtin-test as runner only thanks, jirka -- 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/timers] x86: apic: Use tsc deadline for oneshot when available
Commit-ID: 279f1461432ccdec0b98c0bcbe0a8e2c0f6fdda5
Gitweb: http://git.kernel.org/tip/279f1461432ccdec0b98c0bcbe0a8e2c0f6fdda5
Author: Suresh Siddha
AuthorDate: Mon, 22 Oct 2012 14:37:58 -0700
Committer: Thomas Gleixner
CommitDate: Fri, 2 Nov 2012 11:23:37 +0100
x86: apic: Use tsc deadline for oneshot when available
If the TSC deadline mode is supported, LAPIC timer one-shot mode can be
implemented using IA32_TSC_DEADLINE MSR. An interrupt will be generated
when the TSC value equals or exceeds the value in the IA32_TSC_DEADLINE
MSR.
This enables us to skip the APIC calibration during boot. Also, in
xapic mode, this enables us to skip the uncached apic access to re-arm
the APIC timer.
As this timer ticks at the high frequency TSC rate, we use the
TSC_DIVISOR (32) to work with the 32-bit restrictions in the
clockevent API's to avoid 64-bit divides etc (frequency is u32 and
"unsigned long" in the set_next_event(), max_delta limits the next
event to 32-bit for 32-bit kernel).
Signed-off-by: Suresh Siddha
Cc: ve...@google.com
Cc: len.br...@intel.com
Link:
http://lkml.kernel.org/r/1350941878.6017.31.ca...@sbsiddha-desk.sc.intel.com
Signed-off-by: Thomas Gleixner
---
Documentation/kernel-parameters.txt |4 ++
arch/x86/include/asm/msr-index.h|2 +
arch/x86/kernel/apic/apic.c | 73 +-
3 files changed, 59 insertions(+), 20 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 9776f06..4aa9ca0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1304,6 +1304,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
lapic [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
+ lapic= [x86,APIC] "notscdeadline" Do not use TSC deadline
+ value for LAPIC timer one-shot implementation. Default
+ back to the programmable timer unit in the LAPIC.
+
lapic_timer_c2_ok [X86,APIC] trust the local apic timer
in C2 power state.
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 7f0edce..e400cdb 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -337,6 +337,8 @@
#define MSR_IA32_MISC_ENABLE_TURBO_DISABLE (1ULL << 38)
#define MSR_IA32_MISC_ENABLE_IP_PREF_DISABLE (1ULL << 39)
+#define MSR_IA32_TSC_DEADLINE 0x06E0
+
/* P4/Xeon+ specific */
#define MSR_IA32_MCG_EAX 0x0180
#define MSR_IA32_MCG_EBX 0x0181
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index b17416e..b994cc8 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -90,21 +90,6 @@ EXPORT_EARLY_PER_CPU_SYMBOL(x86_bios_cpu_apicid);
*/
DEFINE_EARLY_PER_CPU_READ_MOSTLY(int, x86_cpu_to_logical_apicid, BAD_APICID);
-/*
- * Knob to control our willingness to enable the local APIC.
- *
- * +1=force-enable
- */
-static int force_enable_local_apic __initdata;
-/*
- * APIC command line parameters
- */
-static int __init parse_lapic(char *arg)
-{
- force_enable_local_apic = 1;
- return 0;
-}
-early_param("lapic", parse_lapic);
/* Local APIC was disabled by the BIOS and enabled by the kernel */
static int enabled_via_apicbase;
@@ -133,6 +118,25 @@ static inline void imcr_apic_to_pic(void)
}
#endif
+/*
+ * Knob to control our willingness to enable the local APIC.
+ *
+ * +1=force-enable
+ */
+static int force_enable_local_apic __initdata;
+/*
+ * APIC command line parameters
+ */
+static int __init parse_lapic(char *arg)
+{
+ if (config_enabled(CONFIG_X86_32) && !arg)
+ force_enable_local_apic = 1;
+ else if (!strncmp(arg, "notscdeadline", 13))
+ setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
+ return 0;
+}
+early_param("lapic", parse_lapic);
+
#ifdef CONFIG_X86_64
static int apic_calibrate_pmtmr __initdata;
static __init int setup_apicpmtimer(char *s)
@@ -315,6 +319,7 @@ int lapic_get_maxlvt(void)
/* Clock divisor */
#define APIC_DIVISOR 16
+#define TSC_DIVISOR 32
/*
* This function sets up the local APIC timer, with a timeout of
@@ -333,6 +338,9 @@ static void __setup_APIC_LVTT(unsigned int clocks, int
oneshot, int irqen)
lvtt_value = LOCAL_TIMER_VECTOR;
if (!oneshot)
lvtt_value |= APIC_LVT_TIMER_PERIODIC;
+ else if (boot_cpu_has(X86_FEATURE_TSC_DEADLINE_TIMER))
+ lvtt_value |= APIC_LVT_TIMER_TSCDEADLINE;
+
if (!lapic_is_integrated())
lvtt_value |= SET_APIC_TIMER_BASE(APIC_TIMER_BASE_DIV);
@@ -341,6 +349,11 @@ static void __setup_APIC_LVTT(unsigned int clocks, int
oneshot, int irqen)
apic_write(APIC_LVTT, lvtt_value);
+ if (lvtt_value & APIC_LVT_TIMER_TSCDEADLINE) {
+ print
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Op 2 nov. 2012, om 10:42 heeft Russ Dill het volgende geschreven: > On Fri, Nov 2, 2012 at 1:57 AM, Felipe Balbi wrote: >> Hi, >> >> On Thu, Nov 01, 2012 at 04:49:23PM -0700, Russ Dill wrote: >>> On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi wrote: HI, On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: > Hi Alan, > > On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: > >>> What they want, and what every user wants, is I plug this board in, and >>> the driver make sure everything is loaded and ready. No, the end users >>> don't want to see any of the implementation details of how the bitfile >>> is transported; the driver can handle it. >> >> That doesn't necessarily make it a bus merely some kind of hotplug >> enumeration of devices. That should all work properly both for devices >> and busses with spi and i²c as the final bits needed for it got fixed >> some time ago. >> >> In an ideal world you don't want to be writing custom drivers for stuff. >> If your cape routes an i²c serial device to the existing system i²c >> busses then you want to just create an instance of any existing driver on >> the existing i²c bus not create a whole new layer of goop. >> >> It does need to do the plumbing and resource management for the plumbing >> but thats not the same as being a bus. >> >> Alan > > > Fair enough. But there's no such thing a 'hotplug enumeration > construct' in Linux yet, and a bus is the closest thing to it. It does > take advantage of the nice way device code matches drivers and devices > though. > > I'm afraid that having the I2C/SPI drivers doing the detection won't > work. The capes can have arbitrary I2C/SPI devices (and even more > weird components). There is no way to assure for example that the I2C > device responding to address 'foo' in cape A is the same I2C device > responding to the same address in cape B. your ->detect() method should take care of that. >>> >>> There isn't some magical serial number in I²C devices that a >>> ->detect() method can read and the implementation of I²C is somewhat >>> flexible. One devices read may be another devices write. A detect >> >> look at what other drivers do. You can read a revision register, you can >> write a command and see if the device responds as expected, it doesn't >> matter. > > Since a "revision" register isn't required by the I²C spec, it isn't > implemented on a huge number of chips. Also, having a few dozen probe > routines come though and write to random address of every single I²C > device can a) take a really long time, and b) have quite a few > unintended side effects. > >>> method that only performs reads could easily toggle a gpio that resets >>> the board, rewrite and eeprom, or set the printer on fire. If you >> >> how ? It's just a read. > > Because the I²C spec is incredibly flexible. For a lot of devices, > reading from a register is done by writing the register address, and > then reading the contents. For devices that don't implement registers > in that way (such as many eeproms), this is just a write. > >>> browse through various detect functions, yes, some of them key off an >>> ID, but a lot of them just check various registers to see if certain >>> bits are zero, or certain bits are one. A lot of I²C devices I've >>> dealt with have no good way of probing them, especially GPIO chips >>> (you'll notice none of the I²C GPIO expanders have detect functions) >> >> it doesn't mean it can't be done. > > Really? Please, do tell how you would write a detect function for a > PCA9534. It has 4 registers, an input port registers, an output port > register, a polarity inversion register, and a configuration register. > And don't forget, since we are probing, every detect routine for every > I²C driver will have to run with every I²C address on every bus, > possibly with both address formats. Worse, things like early revisions of the picoDLP projector will erase their firmware if you do a linear scan through all addresses. regards, Koen-- 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: [PATCHv2 03/25] perf tests: Add framework for automated perf_event_attr tests
On Fri, Nov 02, 2012 at 11:18:56AM +0900, Namhyung Kim wrote:
> On Wed, 31 Oct 2012 15:52:47 +0100, Jiri Olsa wrote:
> > Adding automated test to check event's perf_event_attr values.
> > +#define WRITE_ASS(str, fmt, data) \
> > +do {
> > \
> > + char buf[BUFSIZE]; \
> > + size_t size;\
> > + \
> > + size = snprintf(buf, BUFSIZE, #str "=%"fmt "\n", data); \
> > + if (1 != fwrite(buf, size, 1, file)) { \
> > + perror("test attr - failed to write event file"); \
> > + fclose(file); \
> > + return -1; \
> > + } \
> > + \
> > +} while (0)
>
> What is ASS?
short for assignment
>
> > +
> > +static int store_event(struct perf_event_attr *attr, pid_t pid, int cpu,
> > + int fd, int group_fd, unsigned long flags)
> > +{
> > + FILE *file;
> > + char path[PATH_MAX];
> > +
SNIP
> > + WRITE_ASS(sample_regs_user, "llu", attr->sample_regs_user);
> > + WRITE_ASS(sample_stack_user, PRIu32, attr->sample_stack_user);
> > + WRITE_ASS(optional, "d", 0);
>
> How about rename current WRITE_ASS to __WRITE_ASS and create a wrapper
> WRITE_ASS like this:
>
> #define WRITE_ASS(field, fmt) __WRITE_ASS(field, fmt, attr->field)
>
> and use __WRITE_ASS for 'optional'.
looks ok
>
> > +
> > + fclose(file);
> > + return 0;
> > +}
> [snip]
> > +def compare_data(self, a, b):
> > +a_list = a.split('|')
> > +b_list = b.split('|')
> > +
> > +for a_item in a_list:
> > +for b_item in b_list:
> > +if (a_item == b_item):
> > +return True
> > +elif (a_item == '*') or (b_item == '*'):
> > +return True
> > +
> > +return False
>
> I think it needs some comments about how it works.
>
> > +
> [snip]
> > +def load_events(self, path, events):
> > +parser_event = ConfigParser.SafeConfigParser()
> > +parser_event.read(path)
> > +
> > +for section in filter(self.is_event, parser_event.sections()):
> > +
> > +parser_items = parser_event.items(section);
> > +base_items = {}
> > +
> > +if (':' in section):
> > +base = section[section.index(':') + 1:]
> > +parser_base = ConfigParser.SafeConfigParser()
> > +parser_base.read(self.test_dir + '/' + base)
> > +base_items = parser_base.items('event')
> > +
> > +e = Event(section, parser_items, base_items)
> > +events[section] = e
>
> And this too. :)
ok, will try ;)
thanks,
jirka
--
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/1] ARM: oprofile: add A5/A7/A15 entries in op_perf_name
From: Xiao Jiang
Add related name for A5/A7/A15 which are consistent with the OProfile
user ABI.
Signed-off-by: Xiao Jiang
---
arch/arm/oprofile/common.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
index 99c63d4b..ec10db1 100644
--- a/arch/arm/oprofile/common.c
+++ b/arch/arm/oprofile/common.c
@@ -37,8 +37,11 @@ static struct op_perf_name {
{ "xscale1","arm/xscale2" },
{ "v6", "arm/armv6" },
{ "v6mpcore", "arm/mpcore"},
+ { "ARMv7 Cortex-A5","arm/armv7-ca5" },
+ { "ARMv7 Cortex-A7","arm/armv7-ca7" },
{ "ARMv7 Cortex-A8","arm/armv7" },
{ "ARMv7 Cortex-A9","arm/armv7-ca9" },
+ { "ARMv7 Cortex-A15", "arm/armv7-ca15" },
};
char *op_name_from_perf_id(void)
--
1.7.3
--
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: BUG: enabling psacct breaks fsfreeze
> I saw this behavior (task-hang) when I tested the fsfreeze code. I was > writing a little patch to replace fsfreeze's wait queue with a killable > queue, in this way the user can do at least "kill -9", but since the > behavior was the same before your patch I didn't send it. I don't know if we > can break any previous behavior. The funny thing here is that it's like if > fsfreeze freezes itself :) I think freezing all tasks ain't that bad, my problem is it's not possible to start fsfreeze -u to thaw filesystem.. > > Marco > -- - Ing. Nikola CIPRICH LinuxBox.cz, s.r.o. 28.rijna 168, 709 00 Ostrava tel.: +420 591 166 214 fax:+420 596 621 273 mobil: +420 777 093 799 www.linuxbox.cz mobil servis: +420 737 238 656 email servis: ser...@linuxbox.cz - pgpRvyEzTI16C.pgp Description: PGP signature
Re: kswapd0: excessive CPU usage
Dne 15.10.2012 13:09, Mel Gorman napsal(a):
On Mon, Oct 15, 2012 at 11:54:13AM +0200, Jiri Slaby wrote:
On 10/12/2012 03:57 PM, Mel Gorman wrote:
mm: vmscan: scale number of pages reclaimed by reclaim/compaction only in
direct reclaim
Jiri Slaby reported the following:
(It's an effective revert of "mm: vmscan: scale number of pages
reclaimed by reclaim/compaction based on failures".)
Given kswapd had hours of runtime in ps/top output yesterday in the
morning and after the revert it's now 2 minutes in sum for the last 24h,
I would say, it's gone.
The intention of the patch in question was to compensate for the loss of
lumpy reclaim. Part of the reason lumpy reclaim worked is because it
aggressively reclaimed pages and this patch was meant to be a
sane compromise.
When compaction fails, it gets deferred and both compaction and
reclaim/compaction is deferred avoid excessive reclaim. However, since
commit c6543459 (mm: remove __GFP_NO_KSWAPD), kswapd is woken up each time
and continues reclaiming which was not taken into account when the patch
was developed.
As it is not taking deferred compaction into account in this path it scans
aggressively before falling out and making the compaction_deferred check in
compaction_ready. This patch avoids kswapd scaling pages for reclaim and
leaves the aggressive reclaim to the process attempting the THP
allocation.
Signed-off-by: Mel Gorman
---
mm/vmscan.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2624edc..2b7edfa 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1763,14 +1763,20 @@ static bool in_reclaim_compaction(struct scan_control
*sc)
#ifdef CONFIG_COMPACTION
/*
* If compaction is deferred for sc->order then scale the number of pages
- * reclaimed based on the number of consecutive allocation failures
+ * reclaimed based on the number of consecutive allocation failures. This
+ * scaling only happens for direct reclaim as it is about to attempt
+ * compaction. If compaction fails, future allocations will be deferred
+ * and reclaim avoided. On the other hand, kswapd does not take compaction
+ * deferral into account so if it scaled, it could scan excessively even
+ * though allocations are temporarily not being attempted.
*/
static unsigned long scale_for_compaction(unsigned long pages_for_compaction,
struct lruvec *lruvec, struct scan_control *sc)
{
struct zone *zone = lruvec_zone(lruvec);
- if (zone->compact_order_failed <= sc->order)
+ if (zone->compact_order_failed <= sc->order &&
+ !current_is_kswapd())
pages_for_compaction <<= zone->compact_defer_shift;
return pages_for_compaction;
}
Yes, applying this instead of the revert fixes the issue as well.
I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive CPU
usage - mainly after suspend/resume
Here is just simple kswapd backtrace from running kernel:
kswapd0 R running task030 2 0x
8801331ddae8 0082 880135b8a340 0008
880135b8a340 8801331ddfd8 8801331ddfd8 8801331ddfd8
880071db8000 880135b8a340 0286 8801331dc000
Call Trace:
[] preempt_schedule+0x42/0x60
[] _raw_spin_unlock+0x55/0x60
[] put_super+0x31/0x40
[] drop_super+0x22/0x30
[] prune_super+0x149/0x1b0
[] shrink_slab+0xba/0x510
[] ? mem_cgroup_iter+0x17a/0x2e0
[] ? mem_cgroup_iter+0xca/0x2e0
[] balance_pgdat+0x629/0x7f0
[] kswapd+0x174/0x620
[] ? __init_waitqueue_head+0x60/0x60
[] ? balance_pgdat+0x7f0/0x7f0
[] kthread+0xdb/0xe0
[] ? kthread_create_on_node+0x140/0x140
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_node+0x140/0x140
Zdenek
--
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: [PATCHv7 4/4] virtio_console: Add support for remoteproc serial
> On (Fri) 02 Nov 2012 [09:52:08], Rusty Russell wrote:
> > Amit Shah writes:
> > > On (Tue) 23 Oct 2012 [12:17:49], Rusty Russell wrote:
> > >> sjur.brandel...@stericsson.com writes:
> > >> > From: Sjur Brændeland
> > >
> > >> > @@ -1415,7 +1524,16 @@ static void remove_port_data(struct port
> *port)
> > >> >
> > >> >/* Remove buffers we queued up for the Host to send us data in.
> > >> > */
> > >> >while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
> > >> > - free_buf(buf);
> > >> > + free_buf(buf, true);
> > >> > +
> > >> > + /*
> > >> > + * Remove buffers from out queue for rproc-serial. We
> cannot afford
> > >> > + * to leak any DMA mem, so reclaim this memory even if this
> might be
> > >> > + * racy for the remote processor.
> > >> > + */
> > >> > + if (is_rproc_serial(port->portdev->vdev))
> > >> > + while ((buf = virtqueue_detach_unused_buf(port-
> >out_vq)))
> > >> > + free_buf(buf, true);
> > >> > }
> > >>
> > >> This seems wrong; either this is needed even if !is_rproc_serial(), or
> > >> it's not necessary as the out_vq is empty.
> > >>
> > >> Every path I can see has the device reset (in which case the queues
> > >> should not be active), or we got a VIRTIO_CONSOLE_PORT_REMOVE
> event (in
> > >> which case, the same).
> > >>
> > >> I think we can have non-blocking writes which could leave buffers in
> > >> out_vq: Amit?
> > >
> > > Those get 'reclaimed' just above this hunk:
> > >
> > >
> > > static void remove_port_data(struct port *port)
> > > {
> > > struct port_buffer *buf;
> > >
> > > /* Remove unused data this port might have received. */
> > > discard_port_data(port);
> > >
> > > reclaim_consumed_buffers(port);
> > >
> > > /* Remove buffers we queued up for the Host to send us data in. */
> > > while ((buf = virtqueue_detach_unused_buf(port->in_vq)))
> > > free_buf(buf, true);
> >
> > No, that's pending input buffers, not output buffers.
>
> You're right. Nice catch.
>
> Sjur, can you remove the WARN_ON in your latest series, even generic
> ports may have buffers in the outq.
Sure, I can respin the patch and remove the WARN_ON().
> It'll also need to be done in the port_fops_release() function. Let
> me know if you prefer I send a patch instead.
I can have a go at this, as I have to respin the patch anyway.
Thanks,
Sjur
--
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/
[RFC PATCH 3.7.0-rc2] dt/platform: insert resources correctly into resource tree
From: Srinivas Kandagatla
This patch add new code to correctly add resources into platform device.
Issue with the existing code was the resources are added as flat entry
without creating any tree, this is very much different to what non-dt
platform code does.
With this patch the resources appear correctly as tree in /proc/iomem,
without this patch the resources in /proc/iomem appear as single entry.
i2c example in /proc/iomem:
With-patch:
fed41000-fed4110f : /soc/i2c-stm@fed41000
fed41000-fed4110f : i2c
Without patch:
fed41000-fed4110f : i2c
Signed-off-by: Srinivas Kandagatla
---
Hi All,
Recently I noticed that appearance of /proc/iomem ouput changed
when I started using device trees and the reason for this was
the of-plaform code was not adding resources in same way as
non-dt platform code does.
Do you have any reason for not doing it the same way as non-dt platform code?
This patch is a fixup to that issue.
Comment?
thanks,
srini
drivers/of/platform.c | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b80891b..f43922c 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -203,6 +203,7 @@ struct platform_device *of_platform_device_create_pdata(
struct device *parent)
{
struct platform_device *dev;
+ int i;
if (!of_device_is_available(np))
return NULL;
@@ -218,6 +219,28 @@ struct platform_device *of_platform_device_create_pdata(
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
+ for (i = 0; i < dev->num_resources; i++) {
+ struct resource *p, *r = &dev->resource[i];
+
+ if (r->name == NULL)
+ r->name = dev_name(&dev->dev);
+
+ p = r->parent;
+ if (!p) {
+ if (resource_type(r) == IORESOURCE_MEM)
+ p = &iomem_resource;
+ else if (resource_type(r) == IORESOURCE_IO)
+ p = &ioport_resource;
+ }
+
+ if (p && insert_resource(p, r)) {
+ pr_err("%s: failed to claim resource %d\n",
+ dev_name(&dev->dev), i);
+ platform_device_put(dev);
+ return NULL;
+ }
+ }
+
/* We do not fill the DMA ops for platform devices by default.
* This is currently the responsibility of the platform code
* to do such, possibly using a device notifier
--
1.7.0.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 v1 1/1] mfd: fix for i2c issue DA9052/53 PMIC
There is an issue where the DA9052/53-AA/BA/BB PMIC either locks up or fails to
respond following a system Reset. This could result in a second write
in which the bus writes the current content of the write buffer to address
of the last I2C access.
The failure case is where this unwanted write transfers incorrect data to
a critical register.
This patch fixes this issue by following any read or write with a dummy read
to a safe register address. A safe register address is one where the contents
will not affect the operation of the system.
Signed-off-by: David Dajun Chen
Signed-off-by: Ashish Jangam
---
drivers/mfd/da9052-i2c.c | 56 +
include/linux/mfd/da9052/da9052.h | 47 --
include/linux/mfd/da9052/reg.h|3 ++
3 files changed, 102 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/da9052-i2c.c b/drivers/mfd/da9052-i2c.c
index 352c58b..90eff9a 100644
--- a/drivers/mfd/da9052-i2c.c
+++ b/drivers/mfd/da9052-i2c.c
@@ -27,6 +27,62 @@
#include
#endif
+/* safe register to park I2C operation */
+static inline bool is_i2c_safe_reg(unsigned char reg)
+{
+ switch (reg) {
+ case DA9052_STATUS_A_REG:
+ case DA9052_STATUS_B_REG:
+ case DA9052_STATUS_C_REG:
+ case DA9052_STATUS_D_REG:
+ case DA9052_ADC_RES_L_REG:
+ case DA9052_ADC_RES_H_REG:
+ case DA9052_VDD_RES_REG:
+ case DA9052_ICHG_AV_REG:
+ case DA9052_TBAT_RES_REG:
+ case DA9052_ADCIN4_RES_REG:
+ case DA9052_ADCIN5_RES_REG:
+ case DA9052_ADCIN6_RES_REG:
+ case DA9052_TJUNC_RES_REG:
+ case DA9052_TSI_X_MSB_REG:
+ case DA9052_TSI_Y_MSB_REG:
+ case DA9052_TSI_LSB_REG:
+ case DA9052_TSI_Z_MSB_REG:
+ return true;
+ default:
+ return false;
+ }
+}
+
+/*
+ * There is an issue with DA9052 and DA9053_AA/BA/BB PMIC where the PMIC
+ * gets lockup up or fails to respond following a system reset.
+ * This fix is to follow any read or write with a dummy read to a safe
+ * register.
+ */
+int da9052_i2c_fix(struct da9052 *da9052, unsigned char reg)
+{
+ int val;
+
+ switch (da9052->chip_id) {
+ case DA9052:
+ case DA9053_AA:
+ case DA9053_BA:
+ case DA9053_BB:
+ /* A dummy read to a safe register address. */
+ if (!is_i2c_safe_reg(reg))
+ return regmap_read(da9052->regmap, DA9052_PARK_REGISTER,
+ &val);
+ break;
+ default:
+ /* Do nothing */
+ break;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(da9052_i2c_fix);
+
static int da9052_i2c_enable_multiwrite(struct da9052 *da9052)
{
int reg_val, ret;
diff --git a/include/linux/mfd/da9052/da9052.h
b/include/linux/mfd/da9052/da9052.h
index 0507c4c..0bc0383 100644
--- a/include/linux/mfd/da9052/da9052.h
+++ b/include/linux/mfd/da9052/da9052.h
@@ -101,6 +101,16 @@ struct da9052 {
int chip_irq;
};
+/* I2C Fix */
+#if defined(CONFIG_MFD_DA9052_SPI)
+static inline int da9052_i2c_fix(struct da9052 *da9052, unsigned char reg)
+{
+ return 0;
+}
+#else
+int da9052_i2c_fix(struct da9052 *da9052, unsigned char reg);
+#endif
+
/* ADC API */
int da9052_adc_manual_read(struct da9052 *da9052, unsigned char channel);
int da9052_adc_read_temp(struct da9052 *da9052);
@@ -113,32 +123,61 @@ static inline int da9052_reg_read(struct da9052 *da9052,
unsigned char reg)
ret = regmap_read(da9052->regmap, reg, &val);
if (ret < 0)
return ret;
+
+ ret = da9052_i2c_fix(da9052, reg);
+ if (ret < 0)
+ return ret;
+
return val;
}
static inline int da9052_reg_write(struct da9052 *da9052, unsigned char reg,
unsigned char val)
{
- return regmap_write(da9052->regmap, reg, val);
+ int ret;
+
+ ret = regmap_write(da9052->regmap, reg, val);
+ if (ret < 0)
+ return ret;
+
+ return da9052_i2c_fix(da9052, reg);
}
static inline int da9052_group_read(struct da9052 *da9052, unsigned char reg,
unsigned reg_cnt, unsigned char *val)
{
- return regmap_bulk_read(da9052->regmap, reg, val, reg_cnt);
+ int ret;
+
+ ret = regmap_bulk_read(da9052->regmap, reg, val, reg_cnt);
+ if (ret < 0)
+ return ret;
+
+ return da9052_i2c_fix(da9052, reg);
}
static inline int da9052_group_write(struct da9052 *da9052, unsigned char reg,
unsigned reg_cnt, unsigned char *val)
{
- return regmap_raw_write(da9052->regmap, reg, val, reg_cnt);
+ int ret;
+
+ ret = regmap_raw_write(da9052->regmap, reg, val, reg_cnt);
+ if (ret < 0)
+ return ret;
+
+ return da9052_i2c_fix(da9052, reg);
}
static inline int da9052_reg_update(struct da9052 *da9
AMD A10: MCE Instruction Cache Error
Hello, I've just got the following on an AMD A10 5800K: -- [ 8395.999581] [Hardware Error]: CPU:0 MC1_STATUS[-|CE|MiscV|-|AddrV|-|-]: 0x8c210151 [ 8395.999586] [Hardware Error]:MC1_ADDR: 0xa00e1203 [ 8395.999588] [Hardware Error]: Instruction Cache Error: Parity error during data load from IC. [ 8395.999590] [Hardware Error]: cache level: L1, tx: INSN, mem-tx: IRD -- Kernel is 3.6.5, MB is an Asus F2A85-M with BIOS 5103 (the latest). Can someone enlight me about what might be wrong with my (new) system (memtest didn't show an errors)? What IC is meant? As far as I know, this processor doesn't support ECC, so I wonder where that parity error does come from. Regards, Alexander -- 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: kswapd0: excessive CPU usage
On 11/02/2012 11:44 AM, Zdenek Kabelac wrote: >>> Yes, applying this instead of the revert fixes the issue as well. > > I've applied this patch on 3.7.0-rc3 kernel - and I still see excessive > CPU usage - mainly after suspend/resume > > Here is just simple kswapd backtrace from running kernel: Yup, this is what we were seeing with the former patch only too. Try to apply the other one too: https://patchwork.kernel.org/patch/1673231/ For me I would say, it is fixed by the two patches now. I won't be able to report later, since I'm leaving to a conference tomorrow. > kswapd0 R running task030 2 0x ... > [] shrink_slab+0xba/0x510 thanks, -- js suse labs -- 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 3/6] sched: pack small tasks
On Monday 29 October 2012 06:42 PM, Vincent Guittot wrote:
On 24 October 2012 17:20, Santosh Shilimkar wrote:
Vincent,
Few comments/questions.
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
During sched_domain creation, we define a pack buddy CPU if available.
On a system that share the powerline at all level, the buddy is set to -1
On a dual clusters / dual cores system which can powergate each core and
cluster independantly, the buddy configuration will be :
| CPU0 | CPU1 | CPU2 | CPU3 |
---
buddy | CPU0 | CPU0 | CPU0 | CPU2 |
^
Is that a typo ? Should it be CPU2 instead of
CPU0 ?
No it's not a typo.
The system packs at each scheduling level. It starts to pack in
cluster because each core can power gate independently so CPU1 tries
to pack its tasks in CPU0 and CPU3 in CPU2. Then, it packs at CPU
level so CPU2 tries to pack in the cluster of CPU0 and CPU0 packs in
itself
I get it. Though in above example a task may migrate from say
CPU3->CPU2->CPU0 as part of packing. I was just thinking whether
moving such task from say CPU3 to CPU0 might be best instead.
Small tasks tend to slip out of the periodic load balance.
The best place to choose to migrate them is at their wake up.
I have tried this series since I was looking at some of these packing
bits. On Mobile workloads like OSIdle with Screen ON, MP3, gallary,
I did see some additional filtering of threads with this series
but its not making much difference in power. More on this below.
Can I ask you which configuration you have used ? how many cores and
cluster ? Can they be power gated independently ?
I have been trying with couple of setups. Dual Core ARM machine and
Quad core X86 box with single package thought most of the mobile
workload analysis I was doing on ARM machine. On both setups
CPUs can be gated independently.
Signed-off-by: Vincent Guittot
---
kernel/sched/core.c |1 +
kernel/sched/fair.c | 109
++
kernel/sched/sched.h |1 +
3 files changed, 111 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index dab7908..70cadbe 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6131,6 +6131,7 @@ cpu_attach_domain(struct sched_domain *sd, struct
root_domain *rd, int cpu)
rcu_assign_pointer(rq->sd, sd);
destroy_sched_domains(tmp, cpu);
+ update_packing_domain(cpu);
update_top_cache_domain(cpu);
}
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4f4a4f6..8c9d3ed 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -157,6 +157,63 @@ void sched_init_granularity(void)
update_sysctl();
}
+
+/*
+ * Save the id of the optimal CPU that should be used to pack small tasks
+ * The value -1 is used when no buddy has been found
+ */
+DEFINE_PER_CPU(int, sd_pack_buddy);
+
+/* Look for the best buddy CPU that can be used to pack small tasks
+ * We make the assumption that it doesn't wort to pack on CPU that share
the
s/wort/worth
yes
+ * same powerline. We looks for the 1st sched_domain without the
+ * SD_SHARE_POWERLINE flag. Then We look for the sched_group witht the
lowest
+ * power per core based on the assumption that their power efficiency is
+ * better */
Commenting style..
/*
*
*/
yes
Can you please expand the why the assumption is right ?
"it doesn't wort to pack on CPU that share the same powerline"
By "share the same power-line", I mean that the CPUs can't power off
independently. So if some CPUs can't power off independently, it's
worth to try to use most of them to race to idle.
In that case I suggest we use different word here. Power line can be
treated as voltage line, power domain.
May be SD_SHARE_CPU_POWERDOMAIN ?
Think about a scenario where you have quad core, ducal cluster system
|Cluster1| |cluster 2|
| CPU0 | CPU1 | CPU2 | CPU3 | | CPU0 | CPU1 | CPU2 | CPU3 |
Both clusters run from same voltage rail and have same PLL
clocking them. But the cluster have their own power domain
and all CPU's can power gate them-self to low power states.
Clusters also have their own level2 caches.
In this case, you will still save power if you try to pack
load on one cluster. No ?
yes, I need to update the description of SD_SHARE_POWERLINE because
I'm afraid I was not clear enough. SD_SHARE_POWERLINE includes the
power gating capacity of each core. For your example above, the
SD_SHARE_POWERLINE shoud be cleared at both MC and CPU level.
Thanks for clarification.
+void update_packing_domain(int cpu)
+{
+ struct sched_domain *sd;
+ int id = -1;
+
+ sd = highest_flag_domain(cpu, SD_SHARE_POWERLINE);
+ if (!sd)
+ sd = rcu_dereference_check_sched_domain(cpu_rq(cpu)->sd);
+ else
+ sd = sd->parent;
+
+ while (sd) {
+ struct sched_group *sg = sd->gr
Re: [PATCH] memcg: fix hotplugged memory zone oops
On Fri 02-11-12 11:21:59, Michal Hocko wrote:
> On Thu 01-11-12 18:28:02, Hugh Dickins wrote:
[...]
And I forgot to mention that the following hunk will clash with
"memcg: Simplify mem_cgroup_force_empty_list error handling" which is in
linux-next already (via Tejun's tree).
Would it be easier to split the patch into the real fix and the hunk
bellow? That one doesn't have to go into stable anyway and we would save
some merging conflicts. The updated fix on top of -mm tree is bellow for
your convinience.
> > /**
> > @@ -3688,17 +3712,17 @@ unsigned long mem_cgroup_soft_limit_recl
> > static bool mem_cgroup_force_empty_list(struct mem_cgroup *memcg,
> > int node, int zid, enum lru_list lru)
> > {
> > - struct mem_cgroup_per_zone *mz;
> > + struct lruvec *lruvec;
> > unsigned long flags, loop;
> > struct list_head *list;
> > struct page *busy;
> > struct zone *zone;
> >
> > zone = &NODE_DATA(node)->node_zones[zid];
> > - mz = mem_cgroup_zoneinfo(memcg, node, zid);
> > - list = &mz->lruvec.lists[lru];
> > + lruvec = mem_cgroup_zone_lruvec(zone, memcg);
> > + list = &lruvec->lists[lru];
> >
> > - loop = mz->lru_size[lru];
> > + loop = mem_cgroup_get_lru_size(lruvec, lru);
> > /* give some margin against EBUSY etc...*/
> > loop += 256;
> > busy = NULL;
---
>From 0e55c305a050502a4b2f5167efed58bb6585520b Mon Sep 17 00:00:00 2001
From: Hugh Dickins
Date: Fri, 2 Nov 2012 11:47:48 +0100
Subject: [PATCH] memcg: use mem_cgroup_zone_lruvec in
mem_cgroup_force_empty_list
For no particularly good reason, mem_cgroup_force_empty_list() has
its own code for deciding lruvec. Change it to use the standard
mem_cgroup_zone_lruvec() and mem_cgroup_get_lru_size() too.
In fact it was already safe against oops after memory hotadd (see
"memcg: fix hotplugged memory zone oops" for more details) when lruvec
is not initialized yet (the lru lists in danger could only be empty),
but we're better proofed against future changes this way.
Reported-by: Tang Chen
Signed-off-by: Hugh Dickins
Acked-by: Johannes Weiner
Acked-by: KAMEZAWA Hiroyuki
Acked-by: Michal Hocko
Cc: Konstantin Khlebnikov
Cc: Wen Congyang
---
mm/memcontrol.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6c72d65..32f0ecf 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3710,15 +3710,15 @@ unsigned long mem_cgroup_soft_limit_reclaim(struct zone
*zone, int order,
static void mem_cgroup_force_empty_list(struct mem_cgroup *memcg,
int node, int zid, enum lru_list lru)
{
- struct mem_cgroup_per_zone *mz;
+ struct lruvec *lruvec;
unsigned long flags;
struct list_head *list;
struct page *busy;
struct zone *zone;
zone = &NODE_DATA(node)->node_zones[zid];
- mz = mem_cgroup_zoneinfo(memcg, node, zid);
- list = &mz->lruvec.lists[lru];
+ lruvec = mem_cgroup_zone_lruvec(zone, memcg);
+ list = &lruvec->lists[lru];
busy = NULL;
do {
--
1.7.10.4
--
Michal Hocko
SUSE Labs
--
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 2/3] pppoatm: fix race condition with destroying of vcc
On Fri, Nov 02, 2012 at 10:40:18AM +0100, Krzysztof Mazur wrote: > On Thu, Nov 01, 2012 at 10:26:28AM -0400, chas williams - CONTRACTOR wrote: > > On Wed, 31 Oct 2012 23:04:35 +0100 > > Krzysztof Mazur wrote: > > > - missing check for SS_CONNECTED in pppoatm_ioctl, > > > > in practice you will never run into this because a pvc is immediately > > put into SS_CONNECTED mode (right before the userspace open() > > returns). however, should it check? yes. i dont see anything > > preventing you from running ppp on svc's. > > I can confirm that the problem really exists, without connect() in pppoatm > plugin in pppd, I have seen an Oops and panic. I will send appropriate > patch. I'm sending the patch that fixes this issue. Works correctly with original pppd, and does not crash with pppd without connect() - the pppd just logs: pppd[3460]: ioctl(ATM_SETBACKEND): Invalid argument and exits. Krzysiek -- >8 -- Subject: [PATCH] pppoatm: allow assign only on a connected socket The pppoatm does not check if the used vcc is in connected state, causing an Oops in pppoatm_send() when vcc->send() is called on not fully connected socket. Now pppoatm can be assigned only on connected sockets; otherwise -EINVAL error is returned. Signed-off-by: Krzysztof Mazur --- BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) *pde = Oops: [#1] PREEMPT Pid: 4154, comm: pppd Not tainted 3.6.0-krzysiek-2-g3ff1093 #95/AK32 EIP: 0060:[<>] EFLAGS: 00010202 CPU: 0 EIP is at 0x0 EAX: d95f7800 EBX: d9d4ba80 ECX: d95f7800 EDX: d9d4ba80 ESI: EDI: 0001 EBP: 01c0 ESP: d9823f34 DS: 007b ES: 007b FS: GS: 0033 SS: 0068 CR0: 8005003b CR2: CR3: 1e7b6000 CR4: 07d0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process pppd (pid: 4154, ti=d9822000 task=d99918a0 task.ti=d9822000) Stack: c060cd9b c043a2ca d99ed860 d99ed864 d9d4ba80 08094f22 c043a228 d9d4ba80 d99ed860 000c c043a347 000c d94311a0 08094f22 c043a290 c019f72e d9823f9c 0003 09df1090 d94311a0 08094f22 0008 d9822000 Call Trace: [] ? pppoatm_send+0x6b/0x300 [] ? ppp_write+0x3a/0xe0 [] ? ppp_channel_push+0x38/0xa0 [] ? ppp_write+0xb7/0xe0 [] ? ppp_channel_push+0xa0/0xa0 [] ? vfs_write+0x8e/0x140 [] ? sys_write+0x3c/0x70 [] ? sysenter_do_call+0x12/0x26 Code: Bad EIP value. EIP: [<>] 0x0 SS:ESP 0068:d9823f34 CR2: ---[ end trace e29cf1805f576278 ]--- Kernel panic - not syncing: Fatal exception in interrupt net/atm/pppoatm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/atm/pppoatm.c b/net/atm/pppoatm.c index 226dca9..f27a07a 100644 --- a/net/atm/pppoatm.c +++ b/net/atm/pppoatm.c @@ -406,6 +406,8 @@ static int pppoatm_ioctl(struct socket *sock, unsigned int cmd, return -ENOIOCTLCMD; if (!capable(CAP_NET_ADMIN)) return -EPERM; + if (sock->state != SS_CONNECTED) + return -EINVAL; return pppoatm_assign_vcc(atmvcc, argp); } case PPPIOCGCHAN: -- 1.8.0.172.g62af90c -- 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 5/6] sched: pack the idle load balance
On Monday 29 October 2012 06:57 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
Look for an idle CPU close the pack buddy CPU whenever possible.
s/close/close to
yes
The goal is to prevent the wake up of a CPU which doesn't share the power
line of the pack CPU
Signed-off-by: Vincent Guittot
---
kernel/sched/fair.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 6df53b5..f76acdc 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5158,7 +5158,25 @@ static struct {
static inline int find_new_ilb(int call_cpu)
{
+ struct sched_domain *sd;
int ilb = cpumask_first(nohz.idle_cpus_mask);
+ int buddy = per_cpu(sd_pack_buddy, call_cpu);
+
+ /*
+* If we have a pack buddy CPU, we try to run load balance on a
CPU
+* that is close to the buddy.
+*/
+ if (buddy != -1)
+ for_each_domain(buddy, sd) {
+ if (sd->flags & SD_SHARE_CPUPOWER)
+ continue;
Do you mean SD_SHARE_POWERLINE here ?
No, I just don't want to take hyperthread level for ILB
+
+ ilb = cpumask_first_and(sched_domain_span(sd),
+ nohz.idle_cpus_mask);
+
+ if (ilb < nr_cpu_ids)
+ break;
+ }
if (ilb < nr_cpu_ids && idle_cpu(ilb))
return ilb;
Can you please expand "idle CPU _close_ the pack buddy CPU" ?
The goal is to packed the tasks on the pack buddy CPU so when the
scheduler needs to start ILB, I try to wake up a CPU that is close to
the buddy and preferably in the same cluster
I see your point now. Thanks for clarification.
Regards
santosh
--
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 6/6] ARM: sched: clear SD_SHARE_POWERLINE
On Monday 29 October 2012 06:58 PM, Vincent Guittot wrote:
On 24 October 2012 17:21, Santosh Shilimkar wrote:
On Sunday 07 October 2012 01:13 PM, Vincent Guittot wrote:
The ARM platforms take advantage of packing small tasks on few cores.
This is true even when the cores of a cluster can't be powergated
independently.
Signed-off-by: Vincent Guittot
---
arch/arm/kernel/topology.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index 26c12c6..00511d0 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -226,6 +226,11 @@ static inline void update_cpu_power(unsigned int
cpuid, unsigned int mpidr) {}
*/
struct cputopo_arm cpu_topology[NR_CPUS];
+int arch_sd_share_power_line(void)
+{
+ return 0*SD_SHARE_POWERLINE;
+}
Making this selection of policy based on sched domain will better. Just
gives the flexibility to choose a separate scheme for big and little
systems which will be very convenient.
I agree that it would be more flexible to be able to set it for each level
Will you be addressing that in next version then ?
Regards
santosh
--
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/
