April 2015 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Imprecise external aborts (0x1406)
by Tejas Joglekar April 17, 2015

April 17, 2015

Hello , I work on 3.0.35 kernel release by freescale for imx6 platform. I see some imprecise external aborts happening once in while . I read description of the imprecise external aborts on ARM but got to know that it is difficult to get the root cause. Can someone guide me to enable some kernel config to get more info on external abort when next time I see the issue? Cheers, Tejas

1 0

Re: Kernel thread scheduling
by Ruben Safir April 17, 2015

April 17, 2015

That is written by my friend GREG!! I know Greg. I've had many beers with Greg. Ruben On Sun, Apr 12, 2015 at 04:36:53AM +0000, Mohammed Ghriga wrote: > In addition to the suggestions that were offered, I recommend you try reading Chapter 16: https://www.google.com/search?tbo=p&tbm=bks&q=isbn:0596554672 (pages: 267-272). > > > -----Original Message----- > From: nick [mailto:xerofoify@gmail.com] > Sent: Sunday, April 12, 2015 12:16 AM > To: Ruben Safir; kernelnewbies(a)kernelnewbies.org; Mohammed Ghriga > Subject: Re: Kernel thread scheduling > > > > On 2015-04-11 11:02 PM, Ruben Safir wrote: > > On 04/11/2015 10:21 PM, Ruben Safir wrote: > >> On 04/10/2015 09:09 AM, nick wrote: > >>> > >>> > >>> On 2015-04-09 11:37 PM, Ruben Safir wrote: > >>>> On 04/09/2015 10:52 PM, nick wrote: > >>>>> Before asking questions again like this please look into either > >>>>> using lxr or ctags to navigate the kernel tree for answers as can > >>>>> be faster then waiting for me or someone else to respond. > >>>> > >>>> > >>>> well, I reading the text is ctags aren't much value there. > >>>> > >>> Ctags is useful for searching the code, which is why I am recommending it. > >>> Nick > >> > >> I have it built into gvim, but you can't use it from a textbook. I'm > >> finding it is not as useful as it could be for the kernel code. > >> There are stacks of tags to get around. Another 2 days to learn to > >> get around tags in vi is not in the agenda right now. It is the tool > >> I have so I'll have to live with it right now. > >> > >> I also have a question that is not obvious from the code I'm looking at. > >> I'm not sure how these structs are attached together. Or more > >> specifically, I'm not sure how pulling the correct sched_entity gets > >> one the coresponding task_entity > >> > >> You have > >> struct task_struct with a > >> struct sched_entity > >> > >> struct sched_enitities are nodes in the RB tree > >> which are a "container" for "struct rb_node run_node". > >> > >> So a look at sched_entity ... is in ../linux/sched.h > >> > >> 1161 struct sched_entity { > >> 1162 struct load_weight load; /* for load-balancing */ > >> 1163 struct rb_node run_node; > >> 1164 struct list_head group_node; > >> 1165 unsigned int on_rq; > >> 1166 > >> 1167 u64 exec_start; > >> 1168 u64 sum_exec_runtime; > >> 1169 u64 vruntime; > >> 1170 u64 prev_sum_exec_runtime; > >> 1171 > >> 1172 u64 nr_migrations; > >> 1173 > >> 1174 #ifdef CONFIG_SCHEDSTATS > >> 1175 struct sched_statistics statistics; > >> 1176 #endif > >> 1177 > >> 1178 #ifdef CONFIG_FAIR_GROUP_SCHED > >> 1179 int depth; > >> 1180 struct sched_entity *parent; > >> 1181 /* rq on which this entity is (to be) queued: */ > >> 1182 struct cfs_rq *cfs_rq; > >> 1183 /* rq "owned" by this entity/group: */ > >> 1184 struct cfs_rq *my_q; > >> 1185 #endif > >> 1186 > >> 1187 #ifdef CONFIG_SMP > >> 1188 /* Per-entity load-tracking */ > >> 1189 struct sched_avg avg; > >> 1190 #endif > >> 1191 }; > >> > >> I see no means of referencing a specific task from this struct that > >> forms the node. So when you pull the node with the smallest vruntime > >> from the left most postion of the RB tree, by calling > >> pick_next_task(), > >> > >> > >> static struct sched_entity *__pick_next_entity(struct sched_entity > >> *se) { > >> struct rb_node *next = rb_next(&se->run_node); > This finds the next node in the red black tree for sched_enities. > Basically rb_next finds the next node in the tree. The argument is the rb_node structure embedded in the structure using a red black tree. > >> > >> if (!next) > >> return NULL; > >> > If there is no runnable task return NULL and pick_next_task will run the idle_task for this cpu. > >> return rb_entry(next, struct sched_entity, run_node); } > >> > >> > >> how do we know what task we are attached to? > >> > Also try to read Chapter 6 of Linux Kernel Development as if have read that > chapter understanding how red black trees and other data structures work in > kernel code would make more sense. > Nick > >> Ruben > >> > >> > > > > I'm still loss on how we know which taks_struct is being used but as a > > side note, I found this also very puzzling > > > > return rb_entry(next, struct sched_entity, run_node); > > With help I ran it down to this: > > > > http://lxr.free-electrons.com/source/include/linux/rbtree.h#L50 > > > > #define rb_entry(ptr, type, member) container_of(ptr, type, member) > > > > which leads me to yet another macro > > > > 798 #define container_of(ptr, type, member) ({ \ > > 799 const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > > 800 (type *)( (char *)__mptr - offsetof(type,member) );}) > > > > > > This is a use of macros I'd never seen before up close. If anyone could > > help me understand it, I'd appreciate it. > > > > Ruben > >> > >> > >>>> _______________________________________________ > >>>> Kernelnewbies mailing list > >>>> Kernelnewbies(a)kernelnewbies.org > >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >>>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Kernelnewbies mailing list > >> Kernelnewbies(a)kernelnewbies.org > >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >> > >> > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies(a)kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013

1 0

Re: Kernel thread scheduling
by Ruben Safir April 17, 2015

April 17, 2015

looking at it know because I have no clue what that macro is. It is not listed as possible in kings On Sun, Apr 12, 2015 at 04:36:53AM +0000, Mohammed Ghriga wrote: > In addition to the suggestions that were offered, I recommend you try reading Chapter 16: https://www.google.com/search?tbo=p&tbm=bks&q=isbn:0596554672 (pages: 267-272). > > > -----Original Message----- > From: nick [mailto:xerofoify@gmail.com] > Sent: Sunday, April 12, 2015 12:16 AM > To: Ruben Safir; kernelnewbies(a)kernelnewbies.org; Mohammed Ghriga > Subject: Re: Kernel thread scheduling > > > > On 2015-04-11 11:02 PM, Ruben Safir wrote: > > On 04/11/2015 10:21 PM, Ruben Safir wrote: > >> On 04/10/2015 09:09 AM, nick wrote: > >>> > >>> > >>> On 2015-04-09 11:37 PM, Ruben Safir wrote: > >>>> On 04/09/2015 10:52 PM, nick wrote: > >>>>> Before asking questions again like this please look into either > >>>>> using lxr or ctags to navigate the kernel tree for answers as can > >>>>> be faster then waiting for me or someone else to respond. > >>>> > >>>> > >>>> well, I reading the text is ctags aren't much value there. > >>>> > >>> Ctags is useful for searching the code, which is why I am recommending it. > >>> Nick > >> > >> I have it built into gvim, but you can't use it from a textbook. I'm > >> finding it is not as useful as it could be for the kernel code. > >> There are stacks of tags to get around. Another 2 days to learn to > >> get around tags in vi is not in the agenda right now. It is the tool > >> I have so I'll have to live with it right now. > >> > >> I also have a question that is not obvious from the code I'm looking at. > >> I'm not sure how these structs are attached together. Or more > >> specifically, I'm not sure how pulling the correct sched_entity gets > >> one the coresponding task_entity > >> > >> You have > >> struct task_struct with a > >> struct sched_entity > >> > >> struct sched_enitities are nodes in the RB tree > >> which are a "container" for "struct rb_node run_node". > >> > >> So a look at sched_entity ... is in ../linux/sched.h > >> > >> 1161 struct sched_entity { > >> 1162 struct load_weight load; /* for load-balancing */ > >> 1163 struct rb_node run_node; > >> 1164 struct list_head group_node; > >> 1165 unsigned int on_rq; > >> 1166 > >> 1167 u64 exec_start; > >> 1168 u64 sum_exec_runtime; > >> 1169 u64 vruntime; > >> 1170 u64 prev_sum_exec_runtime; > >> 1171 > >> 1172 u64 nr_migrations; > >> 1173 > >> 1174 #ifdef CONFIG_SCHEDSTATS > >> 1175 struct sched_statistics statistics; > >> 1176 #endif > >> 1177 > >> 1178 #ifdef CONFIG_FAIR_GROUP_SCHED > >> 1179 int depth; > >> 1180 struct sched_entity *parent; > >> 1181 /* rq on which this entity is (to be) queued: */ > >> 1182 struct cfs_rq *cfs_rq; > >> 1183 /* rq "owned" by this entity/group: */ > >> 1184 struct cfs_rq *my_q; > >> 1185 #endif > >> 1186 > >> 1187 #ifdef CONFIG_SMP > >> 1188 /* Per-entity load-tracking */ > >> 1189 struct sched_avg avg; > >> 1190 #endif > >> 1191 }; > >> > >> I see no means of referencing a specific task from this struct that > >> forms the node. So when you pull the node with the smallest vruntime > >> from the left most postion of the RB tree, by calling > >> pick_next_task(), > >> > >> > >> static struct sched_entity *__pick_next_entity(struct sched_entity > >> *se) { > >> struct rb_node *next = rb_next(&se->run_node); > This finds the next node in the red black tree for sched_enities. > Basically rb_next finds the next node in the tree. The argument is the rb_node structure embedded in the structure using a red black tree. > >> > >> if (!next) > >> return NULL; > >> > If there is no runnable task return NULL and pick_next_task will run the idle_task for this cpu. > >> return rb_entry(next, struct sched_entity, run_node); } > >> > >> > >> how do we know what task we are attached to? > >> > Also try to read Chapter 6 of Linux Kernel Development as if have read that > chapter understanding how red black trees and other data structures work in > kernel code would make more sense. > Nick > >> Ruben > >> > >> > > > > I'm still loss on how we know which taks_struct is being used but as a > > side note, I found this also very puzzling > > > > return rb_entry(next, struct sched_entity, run_node); > > With help I ran it down to this: > > > > http://lxr.free-electrons.com/source/include/linux/rbtree.h#L50 > > > > #define rb_entry(ptr, type, member) container_of(ptr, type, member) > > > > which leads me to yet another macro > > > > 798 #define container_of(ptr, type, member) ({ \ > > 799 const typeof( ((type *)0)->member ) *__mptr = (ptr); \ > > 800 (type *)( (char *)__mptr - offsetof(type,member) );}) > > > > > > This is a use of macros I'd never seen before up close. If anyone could > > help me understand it, I'd appreciate it. > > > > Ruben > >> > >> > >>>> _______________________________________________ > >>>> Kernelnewbies mailing list > >>>> Kernelnewbies(a)kernelnewbies.org > >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >>>> > >>> > >>> > >> > >> > >> _______________________________________________ > >> Kernelnewbies mailing list > >> Kernelnewbies(a)kernelnewbies.org > >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > >> > >> > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies(a)kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013

1 0

Re: Kernel thread scheduling
by Ruben Safir April 17, 2015

April 17, 2015

On 04/09/2015 10:00 PM, nick wrote: > > > On 2015-04-09 09:51 PM, Ruben Safir wrote: >> >> It is passover so I've read over much of this text, but I have to say >> that in general, I'm way ahead of this book. Although I have limited >> knowledge of Kernel technology in the specific, the C code, data >> structs, and programming concepts are spoon feed in this text and its >> wasting too much time with words that are more easily explained with >> coding examples and UML charts. I don't need a chapter explaining how >> to use ps and the basis of Unix architecture. This text is targeted to >> a different audience, and FWIW, I'm not certain it does a good job of >> that either. The guys who write these texts fall in love with their own >> voices. I know, I've suffered this disease myself when I've written >> tech articles and books. >> >> I can''t recommend this book to anyone. Anyone who doesn't understand >> the basics of I/O processer blocks is not going to understand >> >> static void update_curr(struct cfs_rq *cfs_rq) >> >> >> and OTOH void update_curr(struct cfs_rq *cfs_rq) is not explained well >> enough for coders unfamiliar with the kernel data structs of which BTW >> struct cfs_rq is not one defined in the text. >> >> :( >> >> I'm looking for something more like this, but flushed out more as a textbook >> >> http://www.ibm.com/developerworks/library/l-completely-fair-scheduler/index…, >> and some mentoring, I hope. >> >> >> Ruben >> > Ruben, > The book is for an intro to the kernel not a complete walk through of each subsystem. > If that is the case,why not read the subsystem code and docs in the kernel. I am a > novice myself in terms of patch and coding experience but will be glad to explain the > code as I have read lots of it. Thank you nick. Yes, I downloaded the entire source from Kernel.org and it is sitting on both my laptop and in virtual machines where I have already compiled some stuff and not broken my VMs yets :) I'm looking over /home/ruben/linux-3.19.3/Documentation/scheduler [ruben@stat13 scheduler]$ ls 00-INDEX sched-deadline.txt sched-rt-group.txt media=legal -o sides=two-sided-long-edg sched-design-CFS.txt sched-stats.txt sched-arch.txt sched-domains.txt sched-bwc.txt sched-nice-design.txt I also see in the code there is significant documentation. Right now I am trying to figure out what is the relationship between struct sched_entity and struct cfs_rq and struct rq_of why do we have both?? there is a cast in update_curr u64 now = rq_of(cfs_rq)->clock; or is rq_of a function that returns a pointer is a struct that I missed? > Nick >> On 03/22/2015 08:35 PM, nick wrote: >>> >>> >>> On 2015-03-22 08:05 PM, Ruben Safir wrote: >>>> On 03/22/2015 07:30 PM, nick wrote: >>>>> I would recommend reading Chapters 3 and 4 of Linux Kernel Development by Robert Love >>>>> as when I was learning the scheduler and process management >>>> >>>> >>>> how much has the scheduler changed since then. It was completely >>>> overhauled when the CFS was created >>>> >>>> >>>> >>> The 3rd edition of this book was written after CFS was in the kernel so the chapters >>> are pretty up to date. >>> Nick >>>> _______________________________________________ >>>> Kernelnewbies mailing list >>>> Kernelnewbies(a)kernelnewbies.org >>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>>> >>> >>> _______________________________________________ >>> Kernelnewbies mailing list >>> Kernelnewbies(a)kernelnewbies.org >>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >>> >>> . >>> >> >> >> _______________________________________________ >> Kernelnewbies mailing list >> Kernelnewbies(a)kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > >

9 23

Re: Heap Management Problem
by Ruben Safir April 15, 2015

April 15, 2015

On Wed, Apr 15, 2015 at 05:10:05PM +0800, 慕冬亮 wrote: > IMO, heap , stack , code ,data and so on constitute the process address > space! > | > | > heap > > stack > | > | > data > code > So I only point to this heap ! > That is not nearly complete. The Heap a memory structure attahced to the processor control record that has pointers to areas in the memory which are defined ad hoc in user space and are not defined in the PCR. I can be wrong though. Heaps can be allorthims which are nearly complete binrary trees with values stored at nodes. FWIW, that is tonights class for me... > 2015-04-15 16:48 GMT+08:00 Ruben Safir <ruben(a)mrbrklyn.com>: > > > On 04/15/2015 12:28 AM, 慕冬亮 wrote: > > > Can you give a detail of what you want to prove? > > > I am not familiar with heap management , so I ask for the details! > > > mudongliang > > > > > > 2015-04-15 0:00 GMT+08:00 <Valdis.Kletnieks(a)vt.edu>: > > > > > >> On Tue, 14 Apr 2015 23:01:58 +0800, 慕冬亮 said: > > >> > > >>> Hello Everyone: > > >>> What's the rule about heap management? Especially what's the > > >> function > > >>> of do_brk? > > >> > > >> Who says there's a "rule" about it? Some userspace heap managers don't > > >> even *use* brk() or sbrk(), but instead use mmap() of an anonymous area. > > >> > > > > > > > > > > To the OP, what in your mind is a Heap? > > > > Ruben > > > > > > > > _______________________________________________ > > > Kernelnewbies mailing list > > > Kernelnewbies(a)kernelnewbies.org > > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > > > > > _______________________________________________ > > Kernelnewbies mailing list > > Kernelnewbies(a)kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013

1 0

Heap Management Problem
by 慕冬亮 April 15, 2015

April 15, 2015

Hello Everyone: What's the rule about heap management? Especially what's the function of do_brk? mudongliang

3 4

upstream EXPORT_SYMBOL() for out of tree module?
by dwalker＠fifo99.com April 15, 2015

April 15, 2015

Hi all, I have an out of tree module which uses the xlate_dev_mem_ptr() function on x86. I wanted to know if the kernel community would accept a patch to add an EXPORT_SYMBOL() for this kernel with out the corresponding module being upstreamed with it? Thanks for any help, Daniel

2 2

Question about fixmap
by Alexander Kuleshov April 14, 2015

April 14, 2015

Hello All, I'm reading x86_64 source code and trying to understand where are fixmaps space in the virtual memory space. If I understand correctly (but i'm really not sure about it), fixmap space is after vsyscall space. As Documentation/x86/x86_64/mm.txt says vsyscall virtual space is: ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls Also I see that FIXADDR_START and FIXADDR_TOP and are: FIXADDR_START - 0xffffffffff779000L FIXADDR_TOP - 0xffffffffff7ff000L on my machine. With these addressess FIXADDR_START/FIXADDR_TOP overlap vsyscalls area. Is it correct case that fixmaps are in vsyscal virtual memory space or I'm wrong somewhere? Thank you.

1 0

xtime variable in kernel 4.0
by Mohammad A Khasawneh April 14, 2015

April 14, 2015

Hi everyone, I'm trying to develop a syscall in kernel v4.0 which copies the xtime variable to user space. I can find the variable in 3.X but it seems to have been changed in 4.0. Can anyone point me to its location? Thanks, Mohammad Khasawneh

4 3

maybe dumb question about RCU
by Jeff Haran April 13, 2015

April 13, 2015

Hi all, I've been trying to understand the usage of RCU and am struggling a bit with one issue. Let's say one intends to use "classic RCU" as described in whatisRCU.txt where readers use sequences of rcu_read_lock(), rcu_dereference(), rcu_read_unlock) and updaters use rcu_assign_pointer()/synchronize_rcu(). If one uses rcu_dereference() to access an RCU protect pointer twice within the same rcu read locked critical section, is it guaranteed that the pointers returned by rcu_dereference() will point to the same block of memory? For instance, in the following code (trying make this as simple as possible even if it does nothing useful): char *global; char x[1]; char y[1]; void reader(void) { char *a; char *b; rcu_read_lock(); a = rcu_dereference(global); b = rcu_dereference(global); rcu_read_unlock(); } void updater(void) { rcu_assign_pointer(global, x); rcu_assign_pointer(global, y); } Following the second call to rcu_deference() in reader(), is it guaranteed that a and b will be equal (either both equal to x or both equal y)? Or is it possible what a will equal x and b will equal y? whatisRCU.txt seems to imply that though this is bad practice because its wasteful, both calls to rcu_dereference() will return the same pointer: "228 rcu_dereference() ... 244 Common coding practice uses rcu_dereference() to copy an 245 RCU-protected pointer to a local variable, then dereferences 246 this local variable, for example as follows: 247 248 p = rcu_dereference(head.next); 249 return p->data; 250 251 However, in this case, one could just as easily combine these 252 into one statement: 253 254 return rcu_dereference(head.next)->data; 255 256 If you are going to be fetching multiple fields from the 257 RCU-protected structure, using the local variable is of 258 course preferred. Repeated rcu_dereference() calls look 259 ugly and incur unnecessary overhead on Alpha CPUs." >From lines 256 to 259 I conclude that reader()'s code is considered ugly and wasteful, but a will always equal b. But looking at how rcu_dereference() and rcu_assign_pointer() are implemented, I'm having a hard time seeing how reader() would always see a and b equal. Thanks in advance, Jeff Haran

4 15