Re: Contributing to the device driver staging section of the linux tree

2014-04-15 Thread Greg KH
On Tue, Apr 15, 2014 at 10:57:28PM +0530, Kashyap Gada wrote:
> Hello, 
> 
> I want to re start the code clean up stuff in the staging branch of drivers in
> the linux tree. I have done this before some time back on the 2.6 branch. I
> want to get back to atleast start off again (I am learning developing device
> drivers) to be active in the community.
> 
> My question is that the latest linux kernel is 3.x there have been so many
> versions of it since 2.6. So how to decide which branch we should be working 
> on
> and which is relevant enought in todays time.

You always have to work on the latest development kernel tree, as we do
not do new work on older releases.

See the Documentation/kernel_development/ documentation for how this all
works.

Hope this helps,

greg k-h

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Contributing to the device driver staging section of the linux tree

2014-04-15 Thread Kashyap Gada
Hello,

I want to re start the code clean up stuff in the staging branch of drivers
in the linux tree. I have done this before some time back on the 2.6
branch. I want to get back to atleast start off again (I am learning
developing device drivers) to be active in the community.

My question is that the latest linux kernel is 3.x there have been so many
versions of it since 2.6. So how to decide which branch we should be
working on and which is relevant enought in todays time.

Thanks
Kashyap Gada
gada.kash...@gmail.com
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Questions regarding del_timer_sync() and re-registering timers

2014-04-15 Thread Jimmie Mayfield
Hi.  The conventional wisdom when mixing del_timer_sync() with timers
that re-register themselves is that the caller must ensure that re-registration
does not happen.

>From kernel/timer.c:
 * Synchronization rules: Callers must prevent restarting of the timer,
 * otherwise this function is meaningless.

Now, the pseudo-code for del_timer_sync and try_to_del_timer_sync looks 
something like this (ignoring the lock manipulation):

while (1) {
if (timer is not running) {
if timer is pending then detach it
break
}
else {
sleep
}
}

So that the loop continues to spin until the timer function is no longer 
running at which point the kernel checks the pending list and removes it if 
necessary.

Q:  So given this construct, why is it imperative that the timer 
function not re-register itself?  

I could understand that restriction if the timer function might be running on 
another CPU when the "if timer is pending then detach" step is executed but 
it's not obvious to me how that's possible since base->lock is owned at 
that point (not shown in the pseudocode)?

Can someone briefly point out what I've missed?

Jimmie



___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: cgroups: cannot write on file memory.oom_control

2014-04-15 Thread Rami Rosen
Hi, Hedi,

This sequence works for me:

echo 0 >  /sys/fs/cgroup/memory/memory.use_hierarchy

mkdir  /sys/fs/cgroup/memory/0

Then, the following two commands changes the value of oom_kill_disable:

echo 1 >   /sys/fs/cgroup/memory/0/memory.oom_control

echo 0 >   /sys/fs/cgroup/memory/0/memory.oom_control


For more info, please look for the text about enabling/disabling
use_hierarchy in section 6,
http://lxr.free-electrons.com/source/Documentation/cgroups/memory.txt.

Regards,
Rami Rosen
http://ramirose.wix.com/ramirosen



On Mon, Apr 14, 2014 at 12:22 PM, Hedi Boufaied
 wrote:
> Hi everyone,
>
> I am working with cgroups on OpenSuse (over VirtualBox) and I cannot disable
> the OOM killer by writing to the file memory.oom_control:
>
>> echo 1 > memory.oom_control
>> -bash: echo: write error: Invalid argument
>
> I can change the memory limit and several other settings by writing to the
> appropriate files (like memory.limit_in_bytes) but I could never write to
> file memory.oom_control although I am root.
>
> I saw someone posted a similar issue a few days ago but there was no
> reply...
>
> I have copied below the sequence of command I am using. Any idea what could
> be the issue ?
>
> Thanks in advance for your help!
>
> Hedi
>
>
> 
>
> /sys/fs> su - root
>
> /sys/fs> cd cgroup
>
> /sys/fs/cgroup> cgcreate -g memory:/mygroup
>
> /sys/fs/cgroup> cd memory/mygroup
>
> /sys/fs/cgroup/memory/mygroup> echo 32M > memory.limit_in_bytes
>
> /sys/fs/cgroup/memory/mygroup> cat memory.limit_in_bytes
> 33554432
>
> /sys/fs/cgroup/memory/mygroup> echo 1 > memory.oom_control
> -bash: echo: write error: Invalid argument
>
> /sys/fs/cgroup/memory/mygroup> cat memory.oom_control
> oom_kill_disable 0
> under_oom 0
>
> ---
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>

___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies