Re: Pthread mutex lock validator

[sanketh nalli <nalli dot sanketh at gmail dot com>]

Hi,
I shall get back after resolving the copyright/license issues.
I hope the code is acceptable then.
Thank you.

On Thu, Apr 19, 2012 at 10:53 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Thu, Apr 19, 2012 at 12:52 PM, sanketh nalli <nalli.sanketh@gmail.com> wrote:
>> Hi,
>> Pardon me for an extremely delayed response.
>> I shall keep up next time.
>> I have answered your questions inline.
>
> Please keep the list in the CC. Thank you.
>
>> On Wed, Apr 11, 2012 at 1:14 AM, Carlos O'Donell
>> <carlos@systemhalted.org> wrote:
>>>
>>> On Tue, Apr 10, 2012 at 3:16 PM, sanketh nalli <nalli.sanketh@gmail.com> wrote:
>>> > As part of my senior thesis, I worked on writing a
>>> > lock dependency validator for libpthread,
>>> > which is similar to lockdep in Linux.
>>> > My codes are available here :
>>> > git@github.com:Sanketh/liblockdep.git
>>> >
>>> > I wish to contribute this to glibc/nptl.
>>>
>>> Thank you for contacting the community!
>>>
>>> We are always interested in more volunteers :-)
>>>
>>> Could you please talk about:
>>>
>>> * License and copyright?
>>> ?- Contributing to glibc community requires that the copyright of
>>> your contribution be given to the FSF.
>>> ?- Who owns the license and copyright to the code?
>>> ?- Your school?
>>> ?- You?
>>> ?- Are you able to sign a copyright assignment form for glibc?
>>
>>
>> Well, no body has the copy rights to the code, not me nor my college.
>> But, I borrowed the idea and some of the code from the Linux kernel.
>> And the copyrights for that particular piece of code are with Ingo Molnar
>> and Peter Zijlstra.
>
> We would need the code to be appropriately licensed and copyright
> handed over to the FSF to accept it as part of the project.
>
> Unfortunately because you've seen the original code you can likely no
> longer work on an independent version for glibc if we were to ask you
> to rewrite it.
>
>>> * Theory of operation?
>>
>> The lock-validator tracks the sequence of locks taken when the program
>> is in execution. It plots a resource graph where the nodes are the locks.
>> There is a directed edge from node i to node j, if lock j was taken after
>> lock i.
>>
>> The validator runs BFS (breadth first search) over the graph every time
>> a lock is requested. If any cycles are detected upon the acquisition of
>> the lock, they are reported as deadlocks.
>> Bugs are reported even if the current locking scenario does not cause
>> any deadlock at this point.
>> I.e. if anytime in the past two locks were taken in a different order,
>> even if it happened for another task, even if those were different
>> locks (but of the same class as this lock), this code will detect it.
>>
>> The validator also checks for recursive locks i.e. lock taken twice
>> and lock release bug i.e a lock being released without ever being held.
>
> That's a good description thanks.
>
>>> * Current results against glibc trunk?
>>>
>> i am not sure what this means. Please elaborate.
>
> Have you tried using your lock dependency validator with a build of
> glibc trunk? Did you find any bugs?
>
>>> * Do you plan to stay involved with glibc and maintain this test?
>>
>> Yes... I plan to stay involved and merge this in the main stream library.
>
> ... and after that? Are you interested in maintaining the code?
>
> You *could* use LD_PRELOAD and library auditing to track all lock
> operations, and use internal knowledge of the lock layout to run your
> algorithm.
>
> As I mentioned above though, we can't accept your code unless you
> cleanup the copyright/license issues.
>
> Cheers,
> Carlos.



-- 
Regards

Sanketh Nalli
B.Tech Final year
Department of Information Technology
National Institute of Technology, Karnataka