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.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 <kris...@sigsegv.be> > wrote: > > On 2012-02-22 11:53:12 (+0000), 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*
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies