Re: OOT: sharing about my research about why stat and ls show difference used block count upon a file
Hello. Nice post. I had never noticed that. And I am able to reproduce the ls-stat behavior on a debian box with ext4 fs and no SELinux, or any other ACL's whatsoever. In any case, from here, On Jul 2, 2011, at 8:00 AM, Mulyadi Santosa wrote: > > Few kind people already share their opinions on Linkedin. Here is the > summary so far: > http://the-hydra.blogspot.com/2011/07/feedback-regarding-my-stat-or-ls-post.html You state: > But my friend pointed that stat was accouting extra blocks that might (I say > "might" because my friend is not so sure) contain metadata such as SELinux > and ACL. I am no ext3 expert, but I cannot wrap my head around the FS accounting for *metadata* blocks when stat is invoked. And I don't believe the ACLs would be kept within data blocks either, so this makes little sense to me. In any case, after looking at ext3, I now believe the 'getattr' method in 'struct inode_operations' is left for the VFS to handle with its 'generic_fillattr()' method, and it pretty much copies everything relevant from the inode to the 'struct kstat'. Thing is, does the inode 'i_blocks' field keep track of both metadata and data blocks, or only data blocks? (I think only the latter makes any sense, but hey, that's just me). --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Linux module for causing a system hard lock-up
On Jun 14, 2011, at 9:23 PM, limp wrote: > Thanks very much for that, it worked great! Would it be possible to give me > a brief explanation on how this achieves the hard lockup (i.e. what does it > actually do that leads to a lockup)? If you look at 'stop_machine' method in kernel/stop_machine.c, as provided in [1], and check it further down the call chain, you'll see it basically calls 'stop_cpus', which will then run your 'func' method on each online cpu. From the description of 'stop_cpus', > * Execute @fn(@arg) on online cpus in @cpumask. On each target cpu, > * @fn is run in a process context with the highest priority > * preempting any task on the cpu and monopolizing it. This function > * returns after all executions are complete. If I understood it correctly, each cpu will be running your method 'func', which is an infinite loop that never sleeps, with the highest priority possible and, quoting, "monopolizing it". Hanging the machine with it seems only logical. I hope this helps. Cheers. [1] - http://lxr.linux.no/#linux+v2.6.37.3/kernel/stop_machine.c#L476 [2] - http://lxr.linux.no/#linux+v2.6.37.3/kernel/stop_machine.c#L170 --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re:
On Jun 14, 2011, at 1:36 PM, Mulyadi Santosa wrote: > On Tue, Jun 14, 2011 at 19:20, Venkateswarlu P > wrote: >> >> anyone can send >> implementation of fork() library call in the library >> >> i want to know how it is get connected to the system call. > > create a C program that callls fork(), compile and the ltrace it... Or take a look at glibc's implementation. I'm sure you'd be able to find it by downloading glibc and grep'ing it or by searching the web for an online repository with the code. --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel memory allocation
Hello, Once again, I would pretty much enjoy if you CC'ed the list on replies. On Jun 3, 2011, at 8:49 PM, Amirali Shambayati wrote: > I set breakpoint before kmalloc. panic happens after kmalloc. > >> 2011/6/4 Amirali Shambayati >> ofcourse it's null before allocate it. I make an instantiation of it. then >> I want to allocate memory for it.What else I should do? I meant, are you checking if 'newBun' is NULL _AFTER_ the kmalloc? The kmalloc call will return NULL instead of a pointer to newly allocated memory whenever an error occurs. If by any chance you are not checking if 'newBun' is NULL after the kmalloc, then you should do it. Also, if the panic happens _after_ the kmalloc, and not _during_ the kmalloc, I would say there's a slim chance of kmalloc being the cause of the panic. --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel memory allocation
Hi. In future replies, please CC the list. Does it panic in during the kmalloc, or afterwards? Are you checking if 'newBun' is NULL? I may be missing something obvious in that code, but unless you are out of memory or with some past corruption, I don't think that should panic the kernel. In any case, the panic trace should help. Cheers. --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu On Jun 3, 2011, at 7:50 PM, Amirali Shambayati wrote: > thanks for your guidance. I just want to allocate memory for a struct. I use > this: > > struct bundle* newBun; > newBun = kmalloc(sizeof(*newBun), GFP_KERNEL); > > but it goes to panic state. > > 2011/6/3 João Eduardo Luís > Hi. > > From [1] I'm lead to believe the only difference between the regular > kmalloc() arguments and those of kmalloc_node() is the one specifying which > node you want to allocate the memory on. > > Aside from the third argument, which seems to be related with NUMA (with > which I never worked on kernel-context), I would suggest you to read [2]. > > If on the other hand you only want to allocate memory locally, maybe you > should use kmalloc() or one of its variants [3]. > > > Cheers. > > > [1] - http://www.kernel.org/doc/htmldocs/kernel-api/API-kmalloc-node.html > [2] - http://www.kernel.org/doc/htmldocs/kernel-api/API-kcalloc.html > [3] - http://www.kernel.org/doc/htmldocs/kernel-api/mm.html#id408507 > --- > João Eduardo Luís > gpg key: 477C26E5 from pool.keyserver.eu > > > > > > On Jun 3, 2011, at 7:07 PM, Amirali Shambayati wrote: > > > > > Hello all, > > > > I just want to allocate memory for a struct instantiation. Would anyone > > guide me what arguments I should pass to "kmalloc_node"? > > Regards, > > -- > > Amirali Shambayati > > Bachelor Student > > Computer Engineering Department > > Sharif University of Technology > > Tehran, Iran > > > > ___ > > Kernelnewbies mailing list > > Kernelnewbies@kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > > -- > Amirali Shambayati > Bachelor Student > Computer Engineering Department > Sharif University of Technology > Tehran, Iran > PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel memory allocation
Hi. From [1] I'm lead to believe the only difference between the regular kmalloc() arguments and those of kmalloc_node() is the one specifying which node you want to allocate the memory on. Aside from the third argument, which seems to be related with NUMA (with which I never worked on kernel-context), I would suggest you to read [2]. If on the other hand you only want to allocate memory locally, maybe you should use kmalloc() or one of its variants [3]. Cheers. [1] - http://www.kernel.org/doc/htmldocs/kernel-api/API-kmalloc-node.html [2] - http://www.kernel.org/doc/htmldocs/kernel-api/API-kcalloc.html [3] - http://www.kernel.org/doc/htmldocs/kernel-api/mm.html#id408507 --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu On Jun 3, 2011, at 7:07 PM, Amirali Shambayati wrote: > > Hello all, > > I just want to allocate memory for a struct instantiation. Would anyone guide > me what arguments I should pass to "kmalloc_node"? > Regards, > -- > Amirali Shambayati > Bachelor Student > Computer Engineering Department > Sharif University of Technology > Tehran, Iran > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: surviving in lkml
On Jun 2, 2011, at 7:57 AM, Greg KH wrote: > On Thu, Jun 02, 2011 at 02:51:45AM +0100, João Eduardo Luís wrote: >> Quite nice presentation. Although I was hoping to see something >> stating the correct protocol to repost a question to the list, either >> because the previous one was ignored or just went by unnoticed. > > Just resend it. > > Fair enough. Will do that, expecting not to be marked as spam by everybody whenever I'm way too persistent with something. :-) --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: surviving in lkml
Quite nice presentation. Although I was hoping to see something stating the correct protocol to repost a question to the list, either because the previous one was ignored or just went by unnoticed. Then again, I feel blessed because I either find the answer by myself, although most times when it is no longer required, or I'm able to simply work around the problem. Cheers. --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu On Jun 2, 2011, at 2:25 AM, Anuz Pratap Singh Tomar wrote: > Hi list, > This is an interesting story/presentation by an lkml regular, not technical > but useful. > > https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0B8baQh2SFt66N2Q3M2FkMzYtZmRjYi00NTEzLWEwZWYtOTEzMDk5MzhkOTQ1&hl=en_US&pli=1 > > Regards > Anuz > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: academia contribution to the kernel
state of affairs in my university, dictates that we are in the Java era. Everybody knows Java, and few are those who care to learn any more C than the right amount to complete the couple of chairs in the course that actually requires such an 'archaic programming language' (as some of my colleagues enjoy pointing out, for whatever reason they fancy). Cheers. Joao --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Question regarding purging of specific dcache entries
Hi, I've been developing in the kernel's FS subsystem for quite a while now, and though I've been able to accomplish everything I've set myself up to, it seems I can't figure out how to do a little something. Currently, I need to guarantee that, at a specific moment in time, all entries in the dcache associated with a directory and its children are purged from the cache, forcing a new file system lookup for each and every single one of them. Although I've looked up in dcache.c for a suitable method, I believe d_genocide() may not do the trick, and d_invalidate() won't invalidate a dentry if other dentries can be reached through it. And I have no idea how to walk the dcache, trying to find the required entries in order to invalidate them one by one up to the topmost entry. Any help would sure be appreciated. Cheers. Joao --- João Eduardo Luís gpg key: 477C26E5 from pool.keyserver.eu PGP.sig Description: This is a digitally signed message part ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
