RE: Semaphore and Spinlock
-Original Message- From: kernelnewbies-boun...@kernelnewbies.org [mailto:kernelnewbies- boun...@kernelnewbies.org] On Behalf Of Ruben Sent: Monday, April 27, 2015 12:10 PM To: kernelnewbies@kernelnewbies.org Subject: Re: Semaphore and Spinlock On 04/27/2015 12:31 PM, Jeff Haran wrote: -Original Message- From: kernelnewbies- bounces+jharan=bytemobile@kernelnewbies.org [mailto:kernelnewbies- bounces+jharan=bytemobile@kernelnewbies.org] On Behalf Of Abhishek Bist Sent: Monday, April 27, 2015 6:19 AM To: kernelnewbies@kernelnewbies.org Subject: Semaphore and Spinlock [ Semaphores are a bit like spinlocks, except the holder of a semaphore is a process, not a CPU. ] This is a very first line that is bein written on the description of semaphore on kernel newbies.So what are the different parameter that could justify this statement or the way it could be justified and understood. It makes sense to me conceptually. Say you are running some kernel code on a multicore system and that code serializes access to some data structure via a spinlock. If core A takes the spinlock, then core B comes along and tries to take it, core B will No - that is completely confused. A semaphore doesn't even imply a lock. When a wait calls and the semaphore is less than zero, then the process that called wait then is put on the wait queue and essentially blocks itself. When a process signals a semaphore, it increments the semaphore and then, if the value of the semaphore is = 0 its goes and signals the wait queue for next waiting task from the wait queue and puts in on the run queue for scheduling. This text was in an introduction. I was simply commenting that the original text seemed to provide a reasonable analogy (a bit like spinlocks) at the conceptual level. One can always find differences via some anal retentive run off into the weeds of its implementation. Jeff Haran spin until core A releases the spin lock, at which point core B will hold it. Conceptually, core B is prevented from doing anything else while core A holds the spinl Now say you are running some kernel code that is executed in the context of multiple processes and that code serializes access to some data structure via a semaphore. If process A takes the semaphore, then process B comes along and tries to take it, process B will block (the core B is running on will do a context switch to some other process) until process A releases the semaphore, at which point process B will hold it and once the scheduler on B's core allows process B will start running again. Conceptually, process B is prevented from doing anything else while process A holds the semaphore. A mutex here would also apply. Semaphore is to process like spinlock is to core, at least in this case where the semaphore is being used for mutual exclusion. Jeff Haran ___ 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 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore and Spinlock
On 04/27/2015 09:18 AM, Abhishek Bist wrote: [ Semaphores are a bit like spinlocks, except the holder of a semaphore is a process, not a CPU. ] This is a very first line that is bein written on the description of semaphore on kernel newbies.So what are the different parameter that could justify this statement or the way it could be justified and understood. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies That is a good question. In fact, I've been studying semaphores, spinlocks and Mutexes now for 3 weeks and it still confuses me. Our school is working from a text called Operating Systems Concepts 9th Edition. It seems to avoid defining things It should say Definition: Semephore Mutex: Spinlocks: and then there is monitors I have poured over a lot of sample code. I can show you coding examples for concurrence protection from race condition, and models for mutexes, and even describe what a wait queue might look like, but in the end, I'm still puzzled by this most basic of definition. A lot of this is the fault of the book. They get lost in their own words, research and thoughts and fail to deliver understand concepts to the student. Forget operating systems. Lets say I am writing a book about Bicycles and the principles of Bicycle design. And we are going to study wheels. It makes for very ineffective communication to spend 10 pages describing that C=2piR and other facts about circle geometry, and the mathematical calculation of force when applied to a spoke(or a rope) under tension, et et et and forget to define that a Wheel on a bicycle is a round hoop, usually covered on the outer rim by a rubber tire, that makes contact to the road and allows for the bicycle to roll. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: Semaphore and Spinlock
-Original Message- From: kernelnewbies-bounces+jharan=bytemobile@kernelnewbies.org [mailto:kernelnewbies- bounces+jharan=bytemobile@kernelnewbies.org] On Behalf Of Abhishek Bist Sent: Monday, April 27, 2015 6:19 AM To: kernelnewbies@kernelnewbies.org Subject: Semaphore and Spinlock [ Semaphores are a bit like spinlocks, except the holder of a semaphore is a process, not a CPU. ] This is a very first line that is bein written on the description of semaphore on kernel newbies.So what are the different parameter that could justify this statement or the way it could be justified and understood. It makes sense to me conceptually. Say you are running some kernel code on a multicore system and that code serializes access to some data structure via a spinlock. If core A takes the spinlock, then core B comes along and tries to take it, core B will spin until core A releases the spin lock, at which point core B will hold it. Conceptually, core B is prevented from doing anything else while core A holds the spinlock. Now say you are running some kernel code that is executed in the context of multiple processes and that code serializes access to some data structure via a semaphore. If process A takes the semaphore, then process B comes along and tries to take it, process B will block (the core B is running on will do a context switch to some other process) until process A releases the semaphore, at which point process B will hold it and once the scheduler on B's core allows process B will start running again. Conceptually, process B is prevented from doing anything else while process A holds the semaphore. A mutex here would also apply. Semaphore is to process like spinlock is to core, at least in this case where the semaphore is being used for mutual exclusion. Jeff Haran ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore and Spinlock
On 04/27/2015 12:31 PM, Jeff Haran wrote: -Original Message- From: kernelnewbies-bounces+jharan=bytemobile@kernelnewbies.org [mailto:kernelnewbies- bounces+jharan=bytemobile@kernelnewbies.org] On Behalf Of Abhishek Bist Sent: Monday, April 27, 2015 6:19 AM To: kernelnewbies@kernelnewbies.org Subject: Semaphore and Spinlock [ Semaphores are a bit like spinlocks, except the holder of a semaphore is a process, not a CPU. ] This is a very first line that is bein written on the description of semaphore on kernel newbies.So what are the different parameter that could justify this statement or the way it could be justified and understood. It makes sense to me conceptually. Say you are running some kernel code on a multicore system and that code serializes access to some data structure via a spinlock. If core A takes the spinlock, then core B comes along and tries to take it, core B will No - that is completely confused. A semaphore doesn't even imply a lock. When a wait calls and the semaphore is less than zero, then the process that called wait then is put on the wait queue and essentially blocks itself. When a process signals a semaphore, it increments the semaphore and then, if the value of the semaphore is = 0 its goes and signals the wait queue for next waiting task from the wait queue and puts in on the run queue for scheduling. spin until core A releases the spin lock, at which point core B will hold it. Conceptually, core B is prevented from doing anything else while core A holds the spinl Now say you are running some kernel code that is executed in the context of multiple processes and that code serializes access to some data structure via a semaphore. If process A takes the semaphore, then process B comes along and tries to take it, process B will block (the core B is running on will do a context switch to some other process) until process A releases the semaphore, at which point process B will hold it and once the scheduler on B's core allows process B will start running again. Conceptually, process B is prevented from doing anything else while process A holds the semaphore. A mutex here would also apply. Semaphore is to process like spinlock is to core, at least in this case where the semaphore is being used for mutual exclusion. Jeff Haran ___ 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: Semaphore
Hi, Once process terminated for what ever reason, kernel should release all the resources held by that process including lock. do_exit()--exit_sem(). thanks, Rajath On Tue, Feb 28, 2012 at 1:53 PM, Rajath N R rajat...@gmail.com wrote: Hi, I think santosh is talking about user land IPC (semget). thread/process which has acquired a sema lock/sem down using semop(2) syscall. Thanks, Rajath On Fri, Feb 24, 2012 at 3:54 PM, Kristof Provost kris...@sigsegv.bewrote: On 2012-02-24 12:15:03 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: I think of user land program opening a socket and crashing on segmentation fault. In code 'socket' syscall does: sock_map_fd -- sock_alloc_file -- alloc_file -- ... get lost ... Where exactly in this case lock is held - I mean the lock that gets released when user land process dies? In this case there doesn't appear to be any lock. The sock_map_fd function is most probably called from the socket syscall. This call isn't locked. Multiple processes can be in the socket syscall at the same time. There certainly won't be a (kernel) lock which is held between two system calls. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Thanks Regards, Rajath N R -- Thanks Regards, Rajath N R ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. Can you please point to some code in Linux Kernel that does the job? In kernel/exit.c, look at do_exit(). It cleans up a process after it's terminated (for whatever reason). It does a lot of cleanup, but through exit_files() - put_files_struct() - close_files() it ends up iterating over all open file descriptors and closing them. What's done for each close depends on what the process had open. Normal files will just be closed, or a TCP socket might be closed, or if a device node was opened the corresponding drivers close() function will be called. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On Fri, Feb 24, 2012 at 11:04 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. Can you please point to some code in Linux Kernel that does the job? In kernel/exit.c, look at do_exit(). It cleans up a process after it's terminated (for whatever reason). It does a lot of cleanup, but through exit_files() - put_files_struct() - close_files() it ends up iterating over all open file descriptors and closing them. What's done for each close depends on what the process had open. Normal files will just be closed, or a TCP socket might be closed, or if a device node was opened the corresponding drivers close() function will be called. I meant that I don't see any semaphore related stuff in do_exit(). It seems that semaphore just remains there in the system after a user land task is killed... --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
Can you please point to some code in Linux Kernel that does the job? In kernel/exit.c, look at do_exit(). It cleans up a process after it's terminated (for whatever reason). It does a lot of cleanup, but through exit_files() - put_files_struct() - close_files() it ends up iterating over all open file descriptors and closing them. What's done for each close depends on what the process had open. Normal files will just be closed, or a TCP socket might be closed, or if a device node was opened the corresponding drivers close() function will be called. I meant that I don't see any semaphore related stuff in do_exit(). It seems that semaphore just remains there in the system after a user land task is killed... In this (fictional, I've not looked at the serial driver code) example I'm assuming a semaphore owned by a driver. The user space application is using the driver through a device node. The semaphore is managed by the driver, and released when the close is called. The driver does not know how (or even if) the application stopped, only that it closed the file descriptor. What specific type of semaphore are you interested in? Who acquires it, what does it protect? I think of user land program opening a socket and crashing on segmentation fault. In code 'socket' syscall does: sock_map_fd -- sock_alloc_file -- alloc_file -- ... get lost ... Where exactly in this case lock is held - I mean the lock that gets released when user land process dies? Thanks, --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On 2012-02-24 12:15:03 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: I think of user land program opening a socket and crashing on segmentation fault. In code 'socket' syscall does: sock_map_fd -- sock_alloc_file -- alloc_file -- ... get lost ... Where exactly in this case lock is held - I mean the lock that gets released when user land process dies? In this case there doesn't appear to be any lock. The sock_map_fd function is most probably called from the socket syscall. This call isn't locked. Multiple processes can be in the socket syscall at the same time. There certainly won't be a (kernel) lock which is held between two system calls. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. Can you please point to some code in Linux Kernel that does the job? Thanks, --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands dhyla...@gmail.com wrote: Hi Santosh, On Tue, Feb 21, 2012 at 5:47 AM, SaNtosh kuLkarni santosh.yesop...@gmail.com wrote: A certain kernel process has acquired a semaphore lock and meanwhile during this period the process gets killed abruptly (and it has not released the sem lock..//.sem down).and the other processes cannot acquire the lock, what can be done in this case. Normally, the semaphore would be associated with a driver of some type. If the process opened the driver, then regardless of how the process dies, the file that was opened by the process will eventually be closed by the kernel and the driver's release function will get called. This gives you the opportunity to release the semaphore. The driver would be responsible for tracking the state of the semaphore. Fundamentally the driver is responsible for cleaning up all of the resources that it may be using, and a semaphore is just another resource, like memory. I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. Ok, but what happens if things go wrong? For example, it driver exists abnormally (segmentation fault or something)? Anyway, it seems very strange that the responsibility is of a driver alone! There is the *kernel* in the system to take care of abnormal situation, not the exit function of a driver... --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel zertse...@gmail.com wrote: On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands dhyla...@gmail.com wrote: I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. Ok, but what happens if things go wrong? For example, it driver exists abnormally (segmentation fault or something)? Anyway, it seems very strange that the responsibility is of a driver alone! There is the *kernel* in the system to take care of abnormal situation, not the exit function of a driver... The driver is part of the kernel. If it dies the whole kernel can (perhaps even should) die. There are systems, like Minix, where drivers don't run in kernel mode and where a crashing driver won't take the system down. There are advantages and disadvantages to that approach. See http://en.wikipedia.org/wiki/Microkernel Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel zertse...@gmail.com wrote: On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands dhyla...@gmail.com wrote: I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. Ok, but what happens if things go wrong? For example, it driver exists abnormally (segmentation fault or something)? Anyway, it seems very strange that the responsibility is of a driver alone! There is the *kernel* in the system to take care of abnormal situation, not the exit function of a driver... The driver is part of the kernel. If it dies the whole kernel can (perhaps even should) die. There are systems, like Minix, where drivers don't run in kernel mode and where a crashing driver won't take the system down. There are advantages and disadvantages to that approach. See http://en.wikipedia.org/wiki/Microkernel I am curious though if userspace gets segmentation fault, which is SIGSEGV, kernel should be the one sending that to user space. And while sending SIGSEGV, it must be doing some exit cleanup, wherein it frees all resources. However unlike memory, i haven't seen exit code which frees lock as well? Kristof ___ 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: Semaphore
On 2012-02-22 11:53:12 (+), Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel zertse...@gmail.com wrote: On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands dhyla...@gmail.com wrote: I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. Ok, but what happens if things go wrong? For example, it driver exists abnormally (segmentation fault or something)? Anyway, it seems very strange that the responsibility is of a driver alone! There is the *kernel* in the system to take care of abnormal situation, not the exit function of a driver... The driver is part of the kernel. If it dies the whole kernel can (perhaps even should) die. There are systems, like Minix, where drivers don't run in kernel mode and where a crashing driver won't take the system down. There are advantages and disadvantages to that approach. See http://en.wikipedia.org/wiki/Microkernel I am curious though if userspace gets segmentation fault, which is SIGSEGV, kernel should be the one sending that to user space. And while sending SIGSEGV, it must be doing some exit cleanup, wherein it frees all resources. However unlike memory, i haven't seen exit code which frees lock as well? You're talking about a user space application crashing, Konstantin was talking about crashes in kernel space. These are two very different things. In either case we're talking about a lock inside the kernel. For the first case: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. In the second case: A kernel thread has a lock held, for whatever reason. It can be terminated for a variety of reasons (*all* of them bugs or hardware problems). For example it fails a BUG_ON check, or causes a fault by accessing unmapped memory. In that case the oops handler will terminate the thread, but in that case the lock will still be held, and never unlocked. This results in an incorrect state of the kernel! Some things might still work, others will be broken. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
The original question was how can one can handle safe release of semaphore when a process dies after acquiring semaphore?. This is causing the semaphore to be in acquired state, resulting other processes to wait on it. Regardless of file handling in the kernel, how kernel cleans up the resources held up by the process this question is more specific to locking mechanism. Semaphore design and solution has inherent problem of determining who held the lock. If the owner ship of the lock is unknown it would be easy to release the lock if process dies after acquiring the lock. To overcome this problem, mutex was designed as solution. Mutex provides the ownership of the lock. So, whenever the lock is held by thread, ownership is assigned to that thread. This way one can know which when to release lock if in event of thread dies. In POSIX there are mutex handlers called push and pop handler. Check POSIX API. Regards, Sri. On Wed, Feb 22, 2012 at 7:11 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-22 11:53:12 (+), Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel zertse...@gmail.com wrote: On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands dhyla...@gmail.com wrote: I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. Ok, but what happens if things go wrong? For example, it driver exists abnormally (segmentation fault or something)? Anyway, it seems very strange that the responsibility is of a driver alone! There is the *kernel* in the system to take care of abnormal situation, not the exit function of a driver... The driver is part of the kernel. If it dies the whole kernel can (perhaps even should) die. There are systems, like Minix, where drivers don't run in kernel mode and where a crashing driver won't take the system down. There are advantages and disadvantages to that approach. See http://en.wikipedia.org/wiki/Microkernel I am curious though if userspace gets segmentation fault, which is SIGSEGV, kernel should be the one sending that to user space. And while sending SIGSEGV, it must be doing some exit cleanup, wherein it frees all resources. However unlike memory, i haven't seen exit code which frees lock as well? You're talking about a user space application crashing, Konstantin was talking about crashes in kernel space. These are two very different things. In either case we're talking about a lock inside the kernel. For the first case: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. In the second case: A kernel thread has a lock held, for whatever reason. It can be terminated for a variety of reasons (*all* of them bugs or hardware problems). For example it fails a BUG_ON check, or causes a fault by accessing unmapped memory. In that case the oops handler will terminate the thread, but in that case the lock will still be held, and never unlocked. This results in an incorrect state of the kernel! Some things might still work, others will be broken. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Sri. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
Hi Guys, Thanks for the replies and your interest and your time :) :) cause i did not know if it was a valid doubt , ya my doubt was on how to handle situations like this...i would also like to add few more doubts/append/ to my previous question and make the question more clear.. You have thread/process which has acquired a sema lock/sem down and you kill tat thread or kswapd [[ i would also like to know if its possible gracefully and will that render your system safe ]] say a #bug in your code before it does a sema up/post.I just had this doubt and am considering a possible scenario for code flow/unit test. And also if not a issue how would a user space code would handle this deadlock situation signal handler for sem lock release may be??! Thanks On Wed, Feb 22, 2012 at 8:01 PM, Sri Ram Vemulpali sri.ram.gm...@gmail.comwrote: The original question was how can one can handle safe release of semaphore when a process dies after acquiring semaphore?. This is causing the semaphore to be in acquired state, resulting other processes to wait on it. Regardless of file handling in the kernel, how kernel cleans up the resources held up by the process this question is more specific to locking mechanism. Semaphore design and solution has inherent problem of determining who held the lock. If the owner ship of the lock is unknown it would be easy to release the lock if process dies after acquiring the lock. To overcome this problem, mutex was designed as solution. Mutex provides the ownership of the lock. So, whenever the lock is held by thread, ownership is assigned to that thread. This way one can know which when to release lock if in event of thread dies. In POSIX there are mutex handlers called push and pop handler. Check POSIX API. Regards, Sri. On Wed, Feb 22, 2012 at 7:11 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-22 11:53:12 (+), Anuz Pratap Singh Tomar chambilketha...@gmail.com wrote: On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel zertse...@gmail.com wrote: On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands dhyla...@gmail.com wrote: I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. Ok, but what happens if things go wrong? For example, it driver exists abnormally (segmentation fault or something)? Anyway, it seems very strange that the responsibility is of a driver alone! There is the *kernel* in the system to take care of abnormal situation, not the exit function of a driver... The driver is part of the kernel. If it dies the whole kernel can (perhaps even should) die. There are systems, like Minix, where drivers don't run in kernel mode and where a crashing driver won't take the system down. There are advantages and disadvantages to that approach. See http://en.wikipedia.org/wiki/Microkernel I am curious though if userspace gets segmentation fault, which is SIGSEGV, kernel should be the one sending that to user space. And while sending SIGSEGV, it must be doing some exit cleanup, wherein it frees all resources. However unlike memory, i haven't seen exit code which frees lock as well? You're talking about a user space application crashing, Konstantin was talking about crashes in kernel space. These are two very different things. In either case we're talking about a lock inside the kernel. For the first case: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. In the second case: A kernel thread has a lock held, for whatever reason. It can be terminated for a variety of reasons (*all* of them bugs or hardware problems). For example it fails a BUG_ON check, or causes a fault by accessing unmapped memory. In that case the oops handler will terminate the thread, but in that case the lock will still be held, and never unlocked. This results in an incorrect state of the kernel! Some things might still work, others will be broken. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Sri. -- *Regards, Santosh Kulkarni*
Re: Semaphore
On Tue, Feb 21, 2012 at 3:47 PM, SaNtosh kuLkarni santosh.yesop...@gmail.com wrote: A certain kernel process has acquired a semaphore lock and meanwhile during this period the process gets killed abruptly (and it has not released the sem lock..//.sem down). and the other processes cannot acquire the lock, what can be done in this case. The only check I see is debug_check_no_locks_held() in kernel/exit.c file, do_exit(). But it seems to be relevant only for 'CONFIG_LOCKDEP'... Does anyone know the correct answer? Thanks, --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
Hi Santosh, On Tue, Feb 21, 2012 at 5:47 AM, SaNtosh kuLkarni santosh.yesop...@gmail.com wrote: A certain kernel process has acquired a semaphore lock and meanwhile during this period the process gets killed abruptly (and it has not released the sem lock..//.sem down).and the other processes cannot acquire the lock, what can be done in this case. Normally, the semaphore would be associated with a driver of some type. If the process opened the driver, then regardless of how the process dies, the file that was opened by the process will eventually be closed by the kernel and the driver's release function will get called. This gives you the opportunity to release the semaphore. The driver would be responsible for tracking the state of the semaphore. Fundamentally the driver is responsible for cleaning up all of the resources that it may be using, and a semaphore is just another resource, like memory. I'm assuming that the semaphore is one which is held across multiple calls into the kernel, otherwise you don't have an issue in the first place, unless there is a bug on the kernel side of things which actually caused the process to terminate. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
