linux-kernel - [PATCH v3 00/12] locking/ww_mutex: Keep sorted wait list to avoid stampedes

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

Message-Id: <1482346000-9927-1-git-send-email-nhaehnle@gmail.com>
Date:   Wed, 21 Dec 2016 19:46:28 +0100
From:   Nicolai Hähnle <nhaehnle@...il.com>
To:     linux-kernel@...r.kernel.org
Subject: [PATCH v3 00/12] locking/ww_mutex: Keep sorted wait list to avoid stampedes

Here's a v3 of the series. Some comments:

Patch #1 is already in drm-misc, but I left it here for now for completeness.

Patch #2 is new and affects all types of locks, not just the w/w case. It's
a race that is exceedingly unlikely: basically, we have to be interrupted
right between checking our wait_list position and setting the task state for
long enough that two other tasks can conspire against us in the meantime
(and one of them must have received a signal).

Patch #5 is also new; it gets rid of the static inline ww_mutex_lock
wrappers.

Patch #6 (the heart of the series): Changed to be much less invasive to the
trylock calls. I've also changed the __ww_mutex_add_waiter loop to scan the
wait list in reverse order. It's probably a wash overall.

I kept the logic as far as setting ww_ctx in mutex_waiter is concerned.

About the changes to optimistic spin: I've moved them towards the end so
that they're easy to take or leave. They didn't change much in my
measurements, so I'm not very attached to them, but they do seem more
"right" to me for the w/w case.

Is there a verdict on the whole "use_ww_ctx doesn't work for
mutex_spin_on_owner" question?

Thanks,
Nicolai