linux-kernel - Re: [PATCH v0] add nano semaphore in kernel

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201012301656.03788.arnd@arndb.de>
Date:	Thu, 30 Dec 2010 16:56:03 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Hillf Danton <dhillf@...il.com>
Cc:	Daniel Walker <dwalker@...eaurora.org>,
	linux-kernel@...r.kernel.org, Mike Christie <michaelc@...wisc.edu>
Subject: Re: [PATCH v0] add nano semaphore in kernel

On Thursday 30 December 2010, Hillf Danton wrote:
> >>  /*
> >>   * In the DEBUG case we are using the "NULL fastpath" for mutexes,
> >> @@ -248,7 +249,11 @@ __mutex_lock_common(struct mutex *lock,
> >>               /* didnt get the lock, go to sleep: */
> >>               spin_unlock_mutex(&lock->wait_lock, flags);
> >>               preempt_enable_no_resched();
> >> -             schedule();
> >> +             do {
> >> +                     /* sleep 10,000 nanoseconds per loop */
> >> +                     ktime_t kt = ktime_set(0, 10000);
> >> +                     schedule_hrtimeout(&kt, HRTIMER_MODE_REL);
> >> +             } while (0);
> >>               preempt_disable();
> >>               spin_lock_mutex(&lock->wait_lock, flags);
> >>       }
> >>
> >
> > Doing this would be extremely inefficient, because now the mutex wait
> > function would wake up very frequently instead of just once when the
> 
> Is it waked up less than jeffy?
> If not, checking more frequently in the endless loop could help receive
> signal, other than that is extremely meaningless, as the holder of
> mutex is not ready to release.

It should normally only wake up once, at exactly the time that the other
thread releases the mutex. What exactly happens depends on the relative
priorities of the two lock holders and whether all CPUs are busy already.

If there is nothing else to do and the blocking thread is made runnable
by giving up the mutex, it will run immediately. Even if we keep the
current thread running, the jiffie timer is rather meaningless and
does not directly impact when the new one wakes up.

> As to timeout, it is another story, in which waiter is able to determine
> how many jiffies or nanoseconds are acceptable if waiting is necessary.

Actually, the timeout is the time after which the waiter gives up and
does something else because it no longer expects to get the lock. This
is very rarely needed.

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