Re: Regarding high mem

2012-10-17 Thread Kshemendra KP
On Wed, Oct 17, 2012 at 2:04 PM, Chetan Nanda chetanna...@gmail.com wrote:



 On Tue, Oct 16, 2012 at 5:47 PM, Kshemendra KP 
 kshemen...@suphalaam.comwrote:


On x86 kernel is normally split into 3GB (user) : 1 GB (Kernel)
 spaces. Kernel can only directly
manipulate 1 GB (around 889 MB) from the PAGE_OFFSET (0xC000). The
 user space
memofy below PAGE_OFFSET kernel can't directly access, it considers
 this memory as
high memory. Kernel needs to kmap()/kmap_atomic() map user page and
 access that region.


 As per my understanding, if kernel code is running under a process context
 then it can access lower 3GB address space, provided address in 0-3GB is in
 process address space.  And its not a high memory.
 High memory is a virtual address space with 1GB kernel space to map RAM
 pages beyond 896MB.


One thing not clear to me is, during boot,  kernel is copied to 1st MB of
the RAM in x86 architecture as this  architecture
has ISA mem map hole (640k -to 1MB). From 1st BM till 896MB is occupied by
the kernel. Then user space will be
made available beyond 896 MB.  With this reasoning, it is not clear to me,
whether user space which is present
beyond 896 MB is in high memory.




If the memory is above 4 GB with page extension, it is clear that
 kernel can't access it as
kernel uses void * and/or  unsigned long to hold the address. But
 it is not clear for me
why kernel's can't directly access memory below PAGE_OFFSET ( 0-3GB)
 directly.


 Kernel can access 0-3GB memory, take an example of application sending
 data to kernel via system call e.g. write.
 in Write system call pointer to the buffer will be in 0-3Gb address space
 of calling application. And kernel will access this address to write data
 to drivers/etc ..



 Regards

 Kshemendra

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

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


Regarding high mem

2012-10-16 Thread Kshemendra KP
   On x86 kernel is normally split into 3GB (user) : 1 GB (Kernel) spaces.
Kernel can only directly
   manipulate 1 GB (around 889 MB) from the PAGE_OFFSET (0xC000). The
user space
   memofy below PAGE_OFFSET kernel can't directly access, it considers this
memory as
   high memory. Kernel needs to kmap()/kmap_atomic() map user page and
access that region.

   If the memory is above 4 GB with page extension, it is clear that kernel
can't access it as
   kernel uses void * and/or  unsigned long to hold the address. But it
is not clear for me
   why kernel's can't directly access memory below PAGE_OFFSET ( 0-3GB)
directly.


Regards

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


smp_rmb() in consume_skb

2012-10-11 Thread Kshemendra KP
Hi,

When I was looking into consume_skb() routine (net/core/skbuff.c),
there is smp_rmb() read barrier is present.
It is not clear why this is needed here.  Basically this routine frees
sk_buff if only one user reference is theere

 void consume_skb(struct sk_buff * skb)
 {
 if (unlikely(!skb))
  return;
 if (likley (atomic_read (skb-users) == 1))
  smp_rmb()
  need for this
barrier

..
  __kfree_skb();
 }


Regards

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


Re: how to process data recvd from a device that wont give interrupts

2012-10-05 Thread Kshemendra KP
softirqs and tasklets run in interrupt context and must not sleep.
One cannot use copy_from_user() and copy_to_user() in both of them.


Regards

Kshemendra



On Fri, Oct 5, 2012 at 10:24 AM, devendra.aaru devendra.a...@gmail.comwrote:

 On Thu, Oct 4, 2012 at 1:50 PM, Mulyadi Santosa
 mulyadi.sant...@gmail.com wrote:
  Hi...
 
  On Thu, Oct 4, 2012 at 7:03 PM, devendra.aaru devendra.a...@gmail.com
 wrote:
  Hi all,
 
  I found that you can use a kernel timer and poll for the hardware
  interrupt registers whether the interrupt flag is set or not,
 
  but this will take atleast some good amount of CPU.
 
  yeah, thing is, as you know, timer fires interrupt and CPU will
  certainly have to service it. So, it's impossible to work around it
  IMHO
 
  are there any ways other than using the kernel timer?
 
  perhaps something less intrusive like creating kernel thread and its
  function is solely checking register state?
 

 yes, more or less similar to what the kernel timer does, :)

 I think actually when i get the data , i am just copying it to my
 local structures,

 This job is done in the kernel timer itself, with this itself its
 taking a 10% of cpu
 which is actually too much.

 let me try with softirqs, i am going to use tasklets, what do you think ?
 :)
  --
  regards,
 
  Mulyadi Santosa
  Freelance Linux trainer and consultant
 
  blog: the-hydra.blogspot.com
  training: mulyaditraining.blogspot.com

 ___
 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


Re: Questions about process state manipulation

2012-09-20 Thread Kshemendra KP
On Thu, Sep 20, 2012 at 10:45 AM, Kshemendra KP kshemen...@suphalaam.comwrote:


 Hi Amit,

An executin  task can be is interrupted by interrupts Timer
 interrupt updates
 all the time related things in the sytem. One of the path where scheduler
 is invoked
 is Timer Softirq. Scheduler verifies whether the current executing tasks
 time slice
 is over, or any other task that has higher priority than this task is
 eligible to run.
 If any of them is true scheduler selects the other task to run.



 Regards

 Kshemendra





 On Thu, Sep 20, 2012 at 4:40 AM, Amit Gupta gupta.v.a...@gmail.comwrote:

 Hi Srivatsa,

 (Thats an interesting pointer. I didnt know about cgroups freeze. Thanks.)

 However, I'm trying to figure out how the kernel would go about doing it.
 i.e How the kernel, having a pointer to a task struct, goes about removing
 something from the runqueue. or bringing something from a
 TASK_INTERRUPTIBLE/STOPPED state back onto the runqueue.

 I'm trying to figure this out from looking at the code, but am sort of
 getting lost.

 I guess I can rephrase the question as, I dont really need to do it for
 any other purpose other than understanding how the kernel mechanisms will
 accomplish it. i.e Doing it from userspace using kill or cgroups freeze
 wont uncover this for me.

 Hope my question is clearer,

 Thanks for replies guys,
 Amit



 On Wed, Sep 19, 2012 at 3:09 AM, Srivatsa Bhat 
 bhat.sriva...@gmail.comwrote:

 Hi Amit

  On Wed, Sep 19, 2012 at 4:49 AM, Amit Gupta gupta.v.a...@gmail.comwrote:


 Hi Kshemendra,

 I think I couldn't get my first question across clearly. My intent
 isn't to change do_fork()'s implementation. That wont work for precisely
 the reason you mentioned.(Infact everything after the init process would
 end up blocked).

 My question was more to explore if an existing running process can be
 explicitly taken off the runqueue once we have a pointer to its 
 task_struct.


 If you simply want to stop a running process and resume it at your will,
 you don't need to write any kernel code at all. Simply use the cgroup
 freezer functionality from userspace. You can find more details in
 Documentation/cgroups/freezer-subsystem.txt in the kernel sources.

 Regards,
 Srivatsa S. Bhat




 --
 Amit Gupta



kernel/sched/core.c - __schedule()   has the implemetnation
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies


Re: Questions about process state manipulation

2012-09-19 Thread Kshemendra KP
Hi Amit,

   An executin  task can be is interrupted by interrupts Timer
interrupt updates
all the time related things in the sytem. One of the path where scheduler
is invoked
is Timer Softirq. Scheduler verifies whether the current executing tasks
time slice
is over, or any other task that has higher priority than this task is
eligible to run.
If any of them is true scheduler selects the other task to run.



Regards

Kshemendra





On Thu, Sep 20, 2012 at 4:40 AM, Amit Gupta gupta.v.a...@gmail.com wrote:

 Hi Srivatsa,

 (Thats an interesting pointer. I didnt know about cgroups freeze. Thanks.)

 However, I'm trying to figure out how the kernel would go about doing it.
 i.e How the kernel, having a pointer to a task struct, goes about removing
 something from the runqueue. or bringing something from a
 TASK_INTERRUPTIBLE/STOPPED state back onto the runqueue.

 I'm trying to figure this out from looking at the code, but am sort of
 getting lost.

 I guess I can rephrase the question as, I dont really need to do it for
 any other purpose other than understanding how the kernel mechanisms will
 accomplish it. i.e Doing it from userspace using kill or cgroups freeze
 wont uncover this for me.

 Hope my question is clearer,

 Thanks for replies guys,
 Amit



 On Wed, Sep 19, 2012 at 3:09 AM, Srivatsa Bhat bhat.sriva...@gmail.comwrote:

 Hi Amit

  On Wed, Sep 19, 2012 at 4:49 AM, Amit Gupta gupta.v.a...@gmail.comwrote:


 Hi Kshemendra,

 I think I couldn't get my first question across clearly. My intent isn't
 to change do_fork()'s implementation. That wont work for precisely the
 reason you mentioned.(Infact everything after the init process would end up
 blocked).

 My question was more to explore if an existing running process can be
 explicitly taken off the runqueue once we have a pointer to its task_struct.


 If you simply want to stop a running process and resume it at your will,
 you don't need to write any kernel code at all. Simply use the cgroup
 freezer functionality from userspace. You can find more details in
 Documentation/cgroups/freezer-subsystem.txt in the kernel sources.

 Regards,
 Srivatsa S. Bhat




 --
 Amit Gupta


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


Re: Questions about process state manipulation

2012-09-17 Thread Kshemendra KP
On Tue, Sep 18, 2012 at 9:32 AM, Amit Gupta gupta.v.a...@gmail.com wrote:

 Hi All,

 I had a question about manipulating process state information in the
 kernel and am curious about the right way to go about it.
 (I'm just messing around with some stuff to try and understand the kernel
 better). I had 2 questions:

 1. I'm trying to create a process in the TASK_INTERRUPTIBLE state in the
 kernel. Since do_fork() creates a process/task that is ready to be
 scheduled, I was thinking what might be a good way to pull it off the
 runqueue/stop its execution after do_fork() returns?



Assuming you do the change in the do_fork() so that new process moves to
sleep queue
Whatever new process created made to TASK_INTERRUPTIBLE in the do fork, who
will wakeup the new process.
If you just type ls commnad also it does not work as ls command calls
fork() + exec().  So your shell fork() and
moves to sleep queue. Similarly lot of fork+exec activities happen in the
system will all move to sleep queue.  Many
deamons running on the system may do fork() or fork + exec() will stop
working.


 2.I'm curious if someone can explain the correct way to use the
  set_task_state() macro. Its implementation just seems to boil down to an
 assignment to the appropriate member of the task_struct. The question I had
 in mind was, what if the process is already running? Is it safe to do it?
 Don't we need to acquire some sort of lock before we manipulate a
 task_struct ?


set_task_state() macro is used for portability reason. Earlier code shows
direct manipulaation fo task_struct-state.
When you execute wait_interruptile() family calls, it is the running
process in kernel  executes set_task_state() .





 3. I would also be interested to read the correct way to use task_lock()
 that locks on alloc_lock field of the task_struct. What exactly is this
 lock for and does acquiring it/or any other lock in the task_struct cause
 the process to be remoted from the runqueue?


 Would appreciate any pointers to appropriate code/reading or any
 explanation.
 Thanks,
 --
 Amit Gupta


 ___
 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


Re: kernel stack memory

2012-09-13 Thread Kshemendra KP
Not sure for all the tasks slab is created initailly with contiguous
memory. Slab cache
is shrinked when the system is low on memory.

If the memory is contiguous wriring few bytes after the kernel stack may
corrupt a task_struct
of other task and  it may for eg. corrupt the linked list element resuling
in a crash. If it is not
contiguous, then it may corrupt some other data. If the data is crucial
like link or based on
the value some decision is taken then it will crash.  If some statistics
field is overwritten
it may not impact the system stability.





On Thu, Sep 13, 2012 at 12:42 PM, shubham sharma shubham20...@gmail.comwrote:

 Hi,

 On Thu, Sep 13, 2012 at 12:29 PM, Kshemendra KP
 kshemen...@suphalaam.com wrote:
 
  In user space when you write beyond your address space (if your write
  crosses
  the page boundary alloacted to you), then process is terminated. In the
  kernel
  you are still writinng inside the kernel address space. Your write is not
  beyond
  kernel address space.
 
  Secondly you are corrupting some other data structure. The kernel stack
 is
  part
  of task_struct of the running process, a kmalloc or slab allocator might
  have
  provided this memory (task_-struct).  When you write beyond this if the
  write modiefies some crucial data structure that may result in hang or a
  crash.

 I did a quick calculation on this. The number of slab objects
 allocated for task_struct in my system are 280 and each size of each
 object is 3264

 ---8---
 root@shubh-VirtualBox:~# cat /proc/slabinfo  | grep task_struct
 task_struct  262280   3264   108 : tunables00
   0 : slabdata 28 28  0
 ---8---

 So if my understanding is correct, in case if i define an array of
 more than 280*3264 bytes then it will corrupt the task_struct of at
 least one significantly important process or at least the task_struct
 of the process for my terminal will get corrupted?

 
 
 
 
  On Thu, Sep 13, 2012 at 12:15 PM, shubham sharma shubham20...@gmail.com
 
  wrote:
 
  Hi,
 
  As far as i know, the size of stack allocated in the kernel space is
  8Kb for each process. But in case i use more than 8Kb of memory from
  the stack then what will happen? I think that in that case the system
  would crash because i am accessing an illegal memory area. I wrote
  kernel module in which i defined an integer array whose size was 8000.
  But still it did not crash my system. Why?
 
  The module i wrote was as follows:
 
  #include linux/kernel.h
  #include linux/module.h
 
  int __init init_my_module(void)
  {
  int arr[8000];
  printk(%s:%d\tmodule initilized\n, __func__, __LINE__);
  arr[1] = 1;
  arr[4000] = 1;
  arr[7999] = 1;
  printk(%s:%d\tarr[1]:%d, arr[4000]:%d, arr[7999]:%d\n,
 __func__,
  __LINE__, arr[1], arr[4000], arr[7999]);
  return 0;
  }
 
  void __exit cleanup_my_module(void)
  {
  printk(exiting\n);
  return;
  }
 
  module_init(init_my_module);
  module_exit(cleanup_my_module);
 
  MODULE_LICENSE(GPL);
 
  ___
  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


module loading issue module_layout

2012-09-05 Thread Kshemendra KP
Hi
 As the kernel source not available for running kernel  code of an
Andodiod tablet,
I could not able to match module_layout address of my loadable module with
the
 android tablet running kernel even the kernel versions are same.

Is there a way to generate build environment in such a situation as
the manufacture source is bit deviated from source he has posted on  the
net.

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