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. -- *Regards, Santosh Kulkarni*
On Tue, Feb 21, 2012 at 3:47 PM, SaNtosh kuLkarni <santosh.yesoptus@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
Hi Santosh, On Tue, Feb 21, 2012 at 5:47 AM, SaNtosh kuLkarni <santosh.yesoptus@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
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@gmail.com> wrote:
Hi Santosh,
On Tue, Feb 21, 2012 at 5:47 AM, SaNtosh kuLkarni <santosh.yesoptus@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
On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <zertsekel@gmail.com> wrote:
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@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
On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <zertsekel@gmail.com> wrote:
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@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
On 2012-02-22 11:53:12 (+0000), Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <zertsekel@gmail.com> wrote:
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@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
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 <kristof@sigsegv.be> wrote:
On 2012-02-22 11:53:12 (+0000), Anuz Pratap Singh Tomar <chambilkethakur@gmail.com> wrote:
On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <zertsekel@gmail.com> wrote:
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@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.
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.gmu06@gmail.com>wrote:
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 <kristof@sigsegv.be> wrote:
On 2012-02-22 11:53:12 (+0000), Anuz Pratap Singh Tomar < chambilkethakur@gmail.com> wrote:
On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel < zertsekel@gmail.com> wrote:
On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@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*
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
On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel <zertsekel@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
On Fri, Feb 24, 2012 at 11:04 AM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel <zertsekel@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
On 2012-02-24 11:25:00 (+0200), Kosta Zertsekel <zertsekel@gmail.com> wrote:
On Fri, Feb 24, 2012 at 11:04 AM, Kristof Provost <kristof@sigsegv.be> wrote:
On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel <zertsekel@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...
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? Regards, Kristof
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
On 2012-02-24 12:15:03 (+0200), Kosta Zertsekel <zertsekel@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
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 <kristof@sigsegv.be> wrote:
On 2012-02-24 12:15:03 (+0200), Kosta Zertsekel <zertsekel@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
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 <rajathnr@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 <kristof@sigsegv.be>wrote:
On 2012-02-24 12:15:03 (+0200), Kosta Zertsekel <zertsekel@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
participants (8)
-
Anuz Pratap Singh Tomar -
Dave Hylands -
Konstantin Zertsekel -
Kosta Zertsekel
-
Kristof Provost -
Rajath N R -
SaNtosh kuLkarni -
Sri Ram Vemulpali