Hi Guys,<div><br></div><div>Thanks for the replies and your interest and your time :) :) cause i did not know if it was a valid doubt</div><div>, 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..</div>
<div><br></div><div>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??!<br>
<br></div><div>Thanks</div><div><br><div class="gmail_quote">On Wed, Feb 22, 2012 at 8:01 PM, Sri Ram Vemulpali <span dir="ltr"><<a href="mailto:sri.ram.gmu06@gmail.com">sri.ram.gmu06@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The original question was "how can one can handle safe release of<br>
semaphore when a process dies after acquiring semaphore?". This is<br>
causing the semaphore to be in acquired state, resulting other<br>
processes to wait on it.<br>
<br>
Regardless of file handling in the kernel, how kernel cleans up the<br>
resources held up by the process this question is more specific to<br>
locking mechanism.<br>
<br>
Semaphore design and solution has inherent problem of determining who<br>
held the lock. If the owner ship of the lock is unknown it would be<br>
easy to release the lock if process dies after acquiring the lock. To<br>
overcome this problem, mutex was designed as solution. Mutex provides<br>
the ownership of the lock. So, whenever the lock is held by thread,<br>
ownership is assigned to that thread. This way one can know which when<br>
to release lock if in event of thread dies. In POSIX there are mutex<br>
handlers called push and pop handler. Check POSIX API.<br>
<br>
Regards,<br>
Sri.<br>
<br>
<br>
<br>
<br>
<br>
<br>
On Wed, Feb 22, 2012 at 7:11 AM, Kristof Provost <<a href="mailto:kristof@sigsegv.be">kristof@sigsegv.be</a>> wrote:<br>
> On 2012-02-22 11:53:12 (+0000), Anuz Pratap Singh Tomar <<a href="mailto:chambilkethakur@gmail.com">chambilkethakur@gmail.com</a>> wrote:<br>
>> On Wed, Feb 22, 2012 at 9:48 AM, Kristof Provost <<a href="mailto:kristof@sigsegv.be">kristof@sigsegv.be</a>> wrote:<br>
>><br>
>> > On 2012-02-22 11:01:52 (+0200), Konstantin Zertsekel <<a href="mailto:zertsekel@gmail.com">zertsekel@gmail.com</a>><br>
>> > wrote:<br>
>> > > On Tue, Feb 21, 2012 at 6:14 PM, Dave Hylands <<a href="mailto:dhylands@gmail.com">dhylands@gmail.com</a>><br>
>> > wrote:<br>
>> > > > I'm assuming that the semaphore is one which is held across multiple<br>
>> > > > calls into the kernel, otherwise you don't have an issue in the first<br>
>> > > > place, unless there is a bug on the kernel side of things which<br>
>> > > > actually caused the process to terminate.<br>
>> > ><br>
>> > > Ok, but what happens if things go wrong?<br>
>> > > For example, it driver exists abnormally (segmentation fault or<br>
>> > something)?<br>
>> > > Anyway, it seems very strange that the responsibility is of a driver<br>
>> > alone!<br>
>> > > There is the *kernel* in the system to take care of abnormal<br>
>> > > situation, not the exit function of a driver...<br>
>> > ><br>
>> > The driver is part of the kernel. If it dies the whole kernel can<br>
>> > (perhaps even should) die.<br>
>> ><br>
>> > There are systems, like Minix, where drivers don't run in kernel mode<br>
>> > and where a crashing driver won't take the system down.<br>
>> > There are advantages and disadvantages to that approach.<br>
>> > See <a href="http://en.wikipedia.org/wiki/Microkernel" target="_blank">http://en.wikipedia.org/wiki/Microkernel</a><br>
>> ><br>
>> ><br>
>> I am curious though if userspace gets segmentation fault, which is SIGSEGV,<br>
>> kernel should be the one sending that to user space. And while sending<br>
>> SIGSEGV, it must be doing some exit cleanup, wherein it frees all<br>
>> resources. However unlike memory, i haven't seen exit code which frees lock<br>
>> as well?<br>
>><br>
> You're talking about a user space application crashing, Konstantin was<br>
> talking about crashes in kernel space. These are two very different<br>
> things.<br>
><br>
> In either case we're talking about a lock inside the kernel.<br>
><br>
> For the first case:<br>
> Imagine a driver which only one app can use at a time (perhaps a serial<br>
> port). The kernel will take a lock when the user space app open()s the<br>
> device node and release it when it close()s.<br>
> If the app segfaults in between the open() and close() the lock will<br>
> still get released. The kernel always cleans up open files for stopped<br>
> processes, regardless of how they stop. During this cleanup the kernel<br>
> will close() the device node, and as a result the driver will release<br>
> the lock.<br>
><br>
> In the second case:<br>
> A kernel thread has a lock held, for whatever reason. It can be<br>
> terminated for a variety of reasons (*all* of them bugs or hardware<br>
> problems). For example it fails a BUG_ON check, or causes a fault by<br>
> accessing unmapped memory. In that case the oops handler will terminate<br>
> the thread, but in that case the lock will still be held, and never<br>
> unlocked.<br>
> This results in an incorrect state of the kernel! Some things might<br>
> still work, others will be broken.<br>
><br>
> Regards,<br>
> Kristof<br>
><br>
><br>
> _______________________________________________<br>
> Kernelnewbies mailing list<br>
> <a href="mailto:Kernelnewbies@kernelnewbies.org">Kernelnewbies@kernelnewbies.org</a><br>
> <a href="http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies" target="_blank">http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Regards,<br>
Sri.<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><b style="color:rgb(102,102,204)">Regards,<br>Santosh Kulkarni</b><br><br>
</div>