* Semaphore @ 2012-02-21 13:47 SaNtosh kuLkarni 2012-02-21 15:12 ` Semaphore Konstantin Zertsekel 2012-02-21 16:14 ` Semaphore Dave Hylands 0 siblings, 2 replies; 17+ messages in thread From: SaNtosh kuLkarni @ 2012-02-21 13:47 UTC (permalink / raw) To: kernelnewbies 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* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120221/f34f25ef/attachment.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-21 13:47 Semaphore SaNtosh kuLkarni @ 2012-02-21 15:12 ` Konstantin Zertsekel 2012-02-21 16:14 ` Semaphore Dave Hylands 1 sibling, 0 replies; 17+ messages in thread From: Konstantin Zertsekel @ 2012-02-21 15:12 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-21 13:47 Semaphore SaNtosh kuLkarni 2012-02-21 15:12 ` Semaphore Konstantin Zertsekel @ 2012-02-21 16:14 ` Dave Hylands 2012-02-22 9:01 ` Semaphore Konstantin Zertsekel 1 sibling, 1 reply; 17+ messages in thread From: Dave Hylands @ 2012-02-21 16:14 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-21 16:14 ` Semaphore Dave Hylands @ 2012-02-22 9:01 ` Konstantin Zertsekel 2012-02-22 9:48 ` Semaphore Kristof Provost 0 siblings, 1 reply; 17+ messages in thread From: Konstantin Zertsekel @ 2012-02-22 9:01 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-22 9:01 ` Semaphore Konstantin Zertsekel @ 2012-02-22 9:48 ` Kristof Provost 2012-02-22 11:53 ` Semaphore Anuz Pratap Singh Tomar 0 siblings, 1 reply; 17+ messages in thread From: Kristof Provost @ 2012-02-22 9:48 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-22 9:48 ` Semaphore Kristof Provost @ 2012-02-22 11:53 ` Anuz Pratap Singh Tomar 2012-02-22 12:11 ` Semaphore Kristof Provost 0 siblings, 1 reply; 17+ messages in thread From: Anuz Pratap Singh Tomar @ 2012-02-22 11:53 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120222/ad48c8c6/attachment-0001.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-22 11:53 ` Semaphore Anuz Pratap Singh Tomar @ 2012-02-22 12:11 ` Kristof Provost 2012-02-22 14:31 ` Semaphore Sri Ram Vemulpali 0 siblings, 1 reply; 17+ messages in thread From: Kristof Provost @ 2012-02-22 12:11 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-22 12:11 ` Semaphore Kristof Provost @ 2012-02-22 14:31 ` Sri Ram Vemulpali 2012-02-23 6:12 ` Semaphore SaNtosh kuLkarni 0 siblings, 1 reply; 17+ messages in thread From: Sri Ram Vemulpali @ 2012-02-22 14:31 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Sri. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-22 14:31 ` Semaphore Sri Ram Vemulpali @ 2012-02-23 6:12 ` SaNtosh kuLkarni 2012-02-24 7:07 ` Semaphore Kosta Zertsekel 0 siblings, 1 reply; 17+ messages in thread From: SaNtosh kuLkarni @ 2012-02-23 6:12 UTC (permalink / raw) To: kernelnewbies 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 at 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 at 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 at kernelnewbies.org > > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > > -- > Regards, > Sri. > -- *Regards, Santosh Kulkarni* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120223/47bf0a0f/attachment.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-23 6:12 ` Semaphore SaNtosh kuLkarni @ 2012-02-24 7:07 ` Kosta Zertsekel 2012-02-24 9:04 ` Semaphore Kristof Provost 0 siblings, 1 reply; 17+ messages in thread From: Kosta Zertsekel @ 2012-02-24 7:07 UTC (permalink / raw) To: kernelnewbies >> > 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-24 7:07 ` Semaphore Kosta Zertsekel @ 2012-02-24 9:04 ` Kristof Provost 2012-02-24 9:25 ` Semaphore Kosta Zertsekel 0 siblings, 1 reply; 17+ messages in thread From: Kristof Provost @ 2012-02-24 9:04 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-24 9:04 ` Semaphore Kristof Provost @ 2012-02-24 9:25 ` Kosta Zertsekel 2012-02-24 9:28 ` Semaphore Kristof Provost 0 siblings, 1 reply; 17+ messages in thread From: Kosta Zertsekel @ 2012-02-24 9:25 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-24 9:25 ` Semaphore Kosta Zertsekel @ 2012-02-24 9:28 ` Kristof Provost 2012-02-24 10:15 ` Semaphore Kosta Zertsekel 0 siblings, 1 reply; 17+ messages in thread From: Kristof Provost @ 2012-02-24 9:28 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-24 9:28 ` Semaphore Kristof Provost @ 2012-02-24 10:15 ` Kosta Zertsekel 2012-02-24 10:24 ` Semaphore Kristof Provost 0 siblings, 1 reply; 17+ messages in thread From: Kosta Zertsekel @ 2012-02-24 10:15 UTC (permalink / raw) To: kernelnewbies >> >> 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-24 10:15 ` Semaphore Kosta Zertsekel @ 2012-02-24 10:24 ` Kristof Provost 2012-02-28 8:23 ` Semaphore Rajath N R 0 siblings, 1 reply; 17+ messages in thread From: Kristof Provost @ 2012-02-24 10:24 UTC (permalink / raw) To: kernelnewbies 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-24 10:24 ` Semaphore Kristof Provost @ 2012-02-28 8:23 ` Rajath N R 2012-02-28 8:33 ` Semaphore Rajath N R 0 siblings, 1 reply; 17+ messages in thread From: Rajath N R @ 2012-02-28 8:23 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -- Thanks & Regards, Rajath N R -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120228/76eed4ab/attachment.html ^ permalink raw reply [flat|nested] 17+ messages in thread
* Semaphore 2012-02-28 8:23 ` Semaphore Rajath N R @ 2012-02-28 8:33 ` Rajath N R 0 siblings, 0 replies; 17+ messages in thread From: Rajath N R @ 2012-02-28 8:33 UTC (permalink / raw) To: kernelnewbies 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 at kernelnewbies.org >> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >> > > > > -- > Thanks & Regards, > Rajath N R > -- Thanks & Regards, Rajath N R -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120228/cc6c4eb1/attachment.html ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2012-02-28 8:33 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-21 13:47 Semaphore SaNtosh kuLkarni 2012-02-21 15:12 ` Semaphore Konstantin Zertsekel 2012-02-21 16:14 ` Semaphore Dave Hylands 2012-02-22 9:01 ` Semaphore Konstantin Zertsekel 2012-02-22 9:48 ` Semaphore Kristof Provost 2012-02-22 11:53 ` Semaphore Anuz Pratap Singh Tomar 2012-02-22 12:11 ` Semaphore Kristof Provost 2012-02-22 14:31 ` Semaphore Sri Ram Vemulpali 2012-02-23 6:12 ` Semaphore SaNtosh kuLkarni 2012-02-24 7:07 ` Semaphore Kosta Zertsekel 2012-02-24 9:04 ` Semaphore Kristof Provost 2012-02-24 9:25 ` Semaphore Kosta Zertsekel 2012-02-24 9:28 ` Semaphore Kristof Provost 2012-02-24 10:15 ` Semaphore Kosta Zertsekel 2012-02-24 10:24 ` Semaphore Kristof Provost 2012-02-28 8:23 ` Semaphore Rajath N R 2012-02-28 8:33 ` Semaphore Rajath N R
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).