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@xxxxxxxxxx> wrote: > On 2012-02-22 11:53:12 (+0000), Anuz Pratap Singh Tomar <chambilkethakur@xxxxxxxxx> wrote: >> On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <kristof@xxxxxxxxxx> wrote: >> >> > On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <zertsekel@xxxxxxxxx> >> > wrote: >> > > On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <dhylands@xxxxxxxxx> >> > 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@xxxxxxxxxxxxxxxxx > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Sri. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
