Semaphore

Semaphore

[SaNtosh kuLkarni]

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 

Semaphore

[Konstantin Zertsekel]

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

Semaphore

[Dave Hylands]

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

Semaphore

[Konstantin Zertsekel]

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

Semaphore

[Kristof Provost]

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

Semaphore

[Anuz Pratap Singh Tomar]

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 

Semaphore

[Kristof Provost]

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

Semaphore

[Sri Ram Vemulpali]

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.

Semaphore

[SaNtosh kuLkarni]

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 

Semaphore

[Kosta Zertsekel]

>> > 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

Semaphore

[Kristof Provost]

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

Semaphore

[Kosta Zertsekel]

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

Semaphore

[Kristof Provost]

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

Semaphore

[Kosta Zertsekel]

>> >> 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

Semaphore

[Kristof Provost]

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

Semaphore

[Rajath N R]

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 

Semaphore

[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 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