linux-kernel - Non-zero preemption count on voluntary preemptive 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>] [day] [month] [year] [list]

Date:   Fri, 2 Dec 2016 19:30:24 +0100
From:   Alexander Lochmann <alexander.lochmann@...dortmund.de>
To:     linux-kernel@...r.kernel.org
Subject: Non-zero preemption count on voluntary preemptive kernel

Hi folks!

I'm sorry to bother you, guys, but neither the mailing list
'kpreempt-tech@...ts.sourceforge.net' nor Robert's address
'rml@...h9.net' exist anymore.
If I have to address someone else, pls let me know.

We're currently investigating the locking of data structures in the
Linux Kernel -- namely 3.16.
Doing so, we've been logging every call to *lock() or *unlock(). For
further analysis, we log the preempt count as well.
Although we use a voluntary preemptive kernel
(defined(CONFIG_PREEMPT_VOLUNTARY) && !defined(CONFIG_PREEMPT) &&
!defined(CONFIG_PREEMPT_COUNT), the actual preemption count, the first
eight bits, aren't zero all time.
I'd expect the kernel to not touch those bits, because the
preempt_{enable,disable} functions do nearly nothing in my case.
They actually insert a memory barrier, but nothing more.
As you can see in the file (query.txt) attached to this mail, there are
several occasions where the preemption count is above zero. I'm a bit
puzzled why this happens...

The format is as follows:
The first three columns donate the position within the source code where
a lock has been acquired. The fourth column is the preemption count, as
returned by preemption_count(), after acquiring the lock.
The last column tells how often this happens.
I attached my kernel config as well.

Can you please tell why this happens?
Have I missed something? Might this be a bug?

Thanks!

Regards,
Alex
-- 
Technische Universität Dortmund
Alexander Lochmann                PGP key: 0xBC3EF6FD
Otto-Hahn-Str. 16                 phone:  +49.231.7556141
D-44227 Dortmund                  fax:    +49.231.7556116
http://ess.cs.tu-dortmund.de/Staff/al

View attachment "config" of type "text/plain" (81834 bytes)

View attachment "query.txt" of type "text/plain" (2665 bytes)

Download attachment "signature.asc" of type "application/pgp-signature" (851 bytes)