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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ