linux-kernel - Re: new implementation of mutex

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <d364733c0906010228x2b977ccfl1c8b2862784e1bc0@mail.gmail.com>
Date:	Mon, 1 Jun 2009 17:28:29 +0800
From:	谢纲 <xiegang112@...il.com>
To:	Xiaotian Feng <xtfeng@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: new implementation of mutex

On Mon, Jun 1, 2009 at 5:06 PM, Xiaotian Feng <xtfeng@...il.com> wrote:
>
>
> On Mon, Jun 1, 2009 at 2:49 PM, 谢纲 <xiegang112@...il.com> wrote:
>>
>> There is new implementaion in newer kernel (my kernel version is
>> 2.6.27). Compared to the old implementaion which uses binary
>> semaphore, there are some new features:
>>  - 'struct mutex' semantics are well-defined and are enforced if
>>   CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have
>>   virtually no debugging code or instrumentation. The mutex subsystem
>>   checks and enforces the following rules:
>>
>>   * - only one task can hold the mutex at a time
>>   * - only the owner can unlock the mutex
>>   * - multiple unlocks are not permitted
>>   * - recursive locking is not permitted
>>   * - a mutex object must be initialized via the API
>>   * - a mutex object must not be initialized via memset or copying
>>   * - task may not exit with mutex held
>>   * - memory areas where held locks reside must not be freed
>>   * - held mutexes must not be reinitialized
>>   * - mutexes may not be used in hardware or software interrupt
>>   *   contexts such as tasklets and timers
>>
>> But in my test, I try to lock mutex in one thread, and unlock it in
>> the other thread. There is nothing wrong happens. It works just like
>> semaphore. I have had CONFIG_DEBUG_MUTEXES turned on.
>> The two threads are mostly like this:
>> struct mutex mutex;
>>
>> static int mysthread1(void * data){
>>  int i;
>>  i= 5;
>>  while(i -- > 0){
>>                mutex_lock(&mutex);
>>    printk("this is thread1\n");
>>    msleep(5000);
>>  }
>>        return 0;
>> }
>>
>> static int mysthread2(void * data){
>>  int i;
>>  i= 5;
>>  while(i -- > 0){
>>    printk("this is thread2\n");
>>    msleep(5000);
>>                mutex_lock(&mutex);
I typied wrong funcion. Actually, I unlock mutex with mutex_unlock here.
>
> unlock here?
yes.
>>
>>  }
>>        return 0;
>> }
>>
>> I debug it and find the debug_locks = 0.  Is this why there is no
>> warning message and how turn it on? (I also had CONFIG_LOCKDEP_SUPPORT
>> on.)
>>
>>
>> --
>> Xie Gang
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majordomo@...r.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>
>



-- 
Xie Gang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/