March 2014 - kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

building kernel modules for linux differnet version
by Saket Sinha March 11, 2014

March 11, 2014

Hi, I have a scenario where I need to build a driver for different kernel versions. I have kernel-headers of different version in /lib/modules/ 2.6.32-xxxx 2.6.39-xxxx and currently I am booted into 2.6.32-xxxx(which I find out by uname -r) Now in my driver makefile, I generate .ko of driver make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules but I notice that the driver .ko gets generated for 2.6.39-xxxx though I am booted into 2.6.32-xxxx. Can anyone help me figure out why this is happening? Regards, Saket Sinha

3 5

Release DMA Memory
by Matt Davis March 11, 2014

March 11, 2014

I have a kernel module that communicates to a PCI device via DMA. The module allocates the shared memory using dma_alloc_coherent(). When the module is unloaded, a call to dma_free_coherent() is executed. My question is, since the DMA memory is not explicitly zeroed before deallocation, is there a chance that the PCI device could still read (non-zeroed data) and act upon the DMA memory after the module unloads and calls dma_free_coherent()? Thanks! -Matt

2 1

Re: Kernelnewbies Digest, Vol 40, Issue 16
by Brian Brzezicki March 10, 2014

March 10, 2014

Ok they are gone part of the order did not come in. Though it's working and the inside is setup very pretty. You can adjust the stones and sand there is extra or both on the bed. --- Please excuse If this message is overly terse. It is because it is being sent on my iPad. > On Mar 10, 2014, at 12:00 PM, kernelnewbies-request(a)kernelnewbies.org wrote: > > Send Kernelnewbies mailing list submissions to > kernelnewbies(a)kernelnewbies.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > or, via email, send a message with subject or body 'help' to > kernelnewbies-request(a)kernelnewbies.org > > You can reach the person managing the list at > kernelnewbies-owner(a)kernelnewbies.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Kernelnewbies digest..." > > > Today's Topics: > > 1. How to check if my kernel driver is leaking memory (m silverstri) > 2. Re: How to check if my kernel driver is leaking memory > (Valdis.Kletnieks(a)vt.edu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 9 Mar 2014 22:14:24 -0700 > From: m silverstri <michael.j.silverstri(a)gmail.com> > Subject: How to check if my kernel driver is leaking memory > To: kernelnewbies <kernelnewbies(a)kernelnewbies.org> > Message-ID: > <CABMudhTc8c9hBt8QaS1TWyc0vnCY1YWTk3i2xyyVo6moMy-c3g(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I am developing a kernel driver. What should I test to make sure my > kernel driver is not leaking memory? > 1. under normal operation (when applications open and close my driver properly) > 2. in error situation (when application open my driver and then it > crashes without close my driver property) > > How can I find out the memory usage used by my driver? so that I can > monitor it over time. > > Thank you. > > > > ------------------------------ > > Message: 2 > Date: Mon, 10 Mar 2014 09:58:39 -0400 > From: Valdis.Kletnieks(a)vt.edu > Subject: Re: How to check if my kernel driver is leaking memory > To: m silverstri <michael.j.silverstri(a)gmail.com> > Cc: kernelnewbies <kernelnewbies(a)kernelnewbies.org> > Message-ID: <167370.1394459919(a)turing-police.cc.vt.edu> > Content-Type: text/plain; charset="us-ascii" > > On Sun, 09 Mar 2014 22:14:24 -0700, m silverstri said: > >> I am developing a kernel driver. What should I test to make sure my >> kernel driver is not leaking memory? > > 1) The brute force method - just add lots of printk's that have > "allocating 25-byte frobozz struct" and "freeing 25-byte frobozz struct" > and make sure they match up. > > 2) kmemleak. > >> 1. under normal operation (when applications open and close my driver properly) >> 2. in error situation (when application open my driver and then it >> crashes without close my driver property) > > Case (2) shouldn't happen, as even if a program crashes the kernel *should* > be invoking the cleanup of open files at process termination. > > A more common cause of memory leaks is for an open() or read/write/ioctl() > path to allocate N chunks of memory, hit an error, and return after having > cleaned up only N-1 of the chunks. This is part of why most kernel code > uses a 'goto error' structure with only one return; at the end of the function. > >

1 0

mmap giving Permission Denied error
by Ravi Teja March 8, 2014

March 8, 2014

Hello all, I tried mmap'ing to address zero after setting */proc/sys/vm/mmap_min_addr*to * 0*, but mmap is giving Permission Denied error. My C code is as below - #include <stdio.h> #include <stdlib.h> #include <sys/mman.h> int main(void) { int *ptr = NULL; ptr = mmap(0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED,-1,0); if(ptr == MAP_FAILED) { perror("Error in mapping\n"); exit(1); } printf("After mmap\n"); *ptr = 16; printf("Contents of address 0x%x is :: %d\n",ptr,*ptr); return 0; } Am I doing anything wrong here? Thank you in advance. Regards, Ravi Teja

5 6

guidelines for kernel module development in linux
by pravin jadav March 8, 2014

March 8, 2014

hello Sir. i want to develop a kernel module that will scan page cache and find the pfn of those pages that have a same content in cache and in secondary storage like physical disk, so please give me some idea how should i start to develop kernel module -- pravin jadav M.Tech (IT pursuing )

2 1

Inline functions
by Summi March 8, 2014

March 8, 2014

Hi, I am writing a device driver. I have a questions to ask: a) inline functions in .c file --> Will it be correct to have inline function declared in .c file? I am speaking with respect to device driver meant for the linux kernel. I have a function, which is quite short in terms of function body and it is exported from one module to another. Do you think, I can declare it as an inline in the .c file or I need to move this function declaration along with the EXPORT_SYMBOL line to a .h file just because it is inlined? For ex -> something like this? inline void hello_world( ) {............ return; } EXPORT_SYMBOL(hello_world);

2 1

Device Tree support for x86_64 kernel? Unresolved symbol apic_force_enable
by Bob Paauwe March 7, 2014

March 7, 2014

Background: I'm working on a project that needs device tree like capability. Using the device tree OF driver works well and I don't want to create something that closely duplicates that functionality. When building a 32bit kernel, all works fine. However when building a 64bit kernel, the linking stage fails with an unresolved symbol: apic_force_enable This symbol is getting called from arch/x86/kernel/devicetree.c and is defined in arch/x86/kernel/apic/apic.c but only when !CONFIG_X86_64 I see two possible fixes but as I'm unfamiliar with this area of the kernel I don't know which would be a better choice. 1) in arch/x86/kernel/apic/apic.c, define the apic_force_enable() function in the X86_64 bit path and have it return 0. Something like: int __init apic_force_enable(unsigned long addr) { return 0; } 2) wrap the call to apic_force_enable with a #ifndef CONFIG_X86_64 in devicetree.c. Something like : #ifndef CONFIG_X86_64 if (apic_force_enable(r.start)) return; #else return; #endif I've been using #1 successfully in my development and it seems like it would be the best choice long term. I'm looking for some validation that this makes sense and if so, I'll submit a patch to lkm with the fix.

1 0

Worth Trying to Take this Upstream?
by Arlie Stephens March 7, 2014

March 7, 2014

Hi Folks, I'm currently making my living working with a system derived from RHEL 6.1, complete with proprietary kernel modules. That's based on the 2.6.32 kernel, which is, of course, old news in the linux world. I recently encountered and bandaided a rather nasty semi-deadlock, that was being aggravated by some of the proprietary code - but which appears to me (so far only from reading source code) to be present in current versions of the linux kernel. It is, however, hard to tickle even with our proprietary module, and doubtless worse without. The problem, in a nutshell, is that whenever the tasklist_lock is held for read there's a tiny chance that jiffies won't advance - increasing the longer the lock is held - and there's code running in softirqs (potentially interrupting a holder of the tasklist_lock) that relies on jiffies as a method of limiting how much work it does before allowing the interrupted task to proceed. The mechanism is quite straightforward, at least with the combination of timer options we're using - which as far as I know now are probably default RHEL for x86_64. It appears that the job of updating jiffies is assigned to one particular core. Jiffies won't advance while that core has local interrupts blocked. Unfortunately the spinlock routine used to get the tasklist_lock in write mode leaves interrupts blocked while spinning. So all we need to get in trouble are 2 cpus. A gets the tasklist_lock in read mode, and is then interrupted, and starts running code that uses jiffies to limit its run time, and happens to have so much work available that only the time limit is likely to stop it. B is in charge of updating jiffies; it runs a thread that calls write_lock_irq(&tasklist_lock). The next thing that happens is that whatever watchdog mechanisms are enabled (and don't use jiffies ;-)) proceed to go off - in our case 60 seconds later. What I'm asking here (other than feedback on the explanation, if folks have any) is whether there's any point taking the issue to LKML. The modality there seems to be to communicate via suggested patches to real bugs someone's actually encountering on current kernels. And there's an understandable aversion to patches submitted by unknowns which touch fundamental core kernel mechanisms. Also, judging by the reaction of my coworkers to my suggestions for a real fix, the linux kernel is seen as very fragile - likely to have code relying on unintended behaviors, so that a change that's theoretically correct may expose all kinds of nastiness. With a little work, I can determine empirically whether the issue is potentially present on current kernels. But there's no way I have the machine farm to make this happen replicably on a standard kernel. Our QA team managed to replicate this 3 times in 8 months, with the help of some proprietary code using the same idiom of limiting its run time via jiffies and running in softirq context. And any work I do on this would be on my own time - management is happy with the proprietary code being changed to use a different technique to limit its run time. The fix I'm inclined to propose is to the reader-writer spinlock code - re-enable interrupts while spinning. Of all the fixes we considered, this is the only one that doesn't potentially cost performance or latency - the only extra work done is while already busy-waiting. It's not a general fix for all RW spinlocks - the tasklist_lock has the useful property that no one ever tries to get it for write with interrupts already blocked. (They use write_lock_irq(), and never write_lock_irqsave()) But it is general and targetted at the mechanism, not the symptom. Thanks for any advice, --- Arlie (Arlie Stephens arlie(a)worldash.org)

1 0

Linux MM : virtual memory address space
by priyaranjan March 7, 2014

March 7, 2014

I was going through http://linux-mm.org/HighMemory "Currently the 32 bit x86 architecture is the most popular type of computer. In this architecture, traditionally the Linux kernel has split the 4GB of virtual memory address space into 3GB for user programs and 1GB for the kernel" What about 64-bit system? Where does the code lie in linux kernel for the check? Is there any latest and updated memory management documentation for Linux kernel? Regards, Priyaranjan

4 8

My Kernel bug is celebrating 2 years. Can you help me fix it?
by Peter Senna Tschudin March 7, 2014

March 7, 2014

I have reported a bug more than two years ago and it is still affecting me. The bug report gives some information: https://bugzilla.redhat.com/show_bug.cgi?id=787299 I have tried basic debug instructions from: https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt And everything works as expected when: # echo freeze > /sys/power/state # echo disk > /sys/power/state I have asked for help for fixing it: https://lkml.org/lkml/2013/11/1/186 But I don't have a serial port. How can I debug this issue without a "real" serial port? Or what else can I try? How can I explore the hint about the problem only happening with VT-d enabled in BIOS? How can I explore the hint about the problem not happening if the option nox2apic is passed to the Kernel? Thank you, Peter P.S Yes, it works on Windows. -- Peter

5 6