linux-kernel - Re: [PATCH 0/8] infiniband: Remove semaphores

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6244597.a6XMUIxjP0@wuerfel>
Date:   Mon, 17 Oct 2016 22:06:16 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Bart Van Assche <bart.vanassche@...disk.com>
Cc:     Binoy Jayan <binoy.jayan@...aro.org>,
        Doug Ledford <dledford@...hat.com>,
        Sean Hefty <sean.hefty@...el.com>,
        Hal Rosenstock <hal.rosenstock@...il.com>,
        linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/8] infiniband: Remove semaphores

On Monday, October 17, 2016 9:57:34 AM CEST Bart Van Assche wrote:
> On 10/17/2016 09:30 AM, Binoy Jayan wrote:
> > These are a set of patches which removes semaphores from infiniband.
> > These are part of a bigger effort to eliminate all semaphores from the
> > linux kernel.
> 
> Hello Binoy,
> 
> Why do you think it would be a good idea to eliminate all semaphores 
> from the Linux kernel? I don't know anyone who doesn't consider 
> semaphores a useful abstraction.

There are a several reasons why the semaphores as defined in the
kernel are bad and we should get rid of them:

- semaphores cannot be analysed using lockdep, since they don't
  always fit in the simpler 'mutex' semantics

- those that are basically mutexes should be converted to mutexes
  for efficiency and consistency anyway

- the semaphores that are not just used as mutexes are typically
  used as completions and should just be converted to completions
  for simplicity

- when running a preempt-rt kernel, semaphores suffer from priority
  inversion problems, while mutexes use use priority inheritance
  as a countermeasure

There are very few remaining semaphores in the kernel and generally
speaking we'd be better off removing them all so no new users
show up in the future. Most of them are trivial to replace with
mutexes or completions. For the ones that are not trivially replaced,
we have to look at each one and decide what to do about them,
there usually is some solution that actually improves the code.

Using an open-coded semaphore as a replacement is probably just
the last resort that we can consider once we are down to the
last handful of users. I haven't looked at drivers/infiniband/
yet for this, but I believe that drivers/acpi/ is a case for
which I see no better alternative (the AML bytecode requires
counting semaphore semantics).

	Arnd