linux-kernel - Re: [PATCH 3/5] zram: use zram_slot_lock instead of raw bit_spin

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: <20170403060858.GA17309@jagdpanzerIV.localdomain>
Date:   Mon, 3 Apr 2017 15:08:58 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:     Minchan Kim <minchan@...nel.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        kernel-team@....com
Subject: Re: [PATCH 3/5] zram: use zram_slot_lock instead of raw
 bit_spin_lock op

Hello Minchan,

On (04/03/17 14:17), Minchan Kim wrote:
> With this clean-up phase, I want to use zram's wrapper function
> to lock table access which is more consistent with other zram's
> functions.

which reminds me of...

there was a discussion a long time ago, -rt people absolutely
hate bit spin_locks and they suggested us to replace it with
normal spin_locks (and I promised to take a look at it, but
got interrupted and never really returned back to it).

for !lockdep builds the impact is somewhat small; for lockdep
builds we increase the memory usage, but

a) lockdep builds are debug builds by definition, no one runs lockdep
   enabled kernels in production

b) we have lockdep in zram now, which is nice

c) spin_locks probably have better fairness guarantees


what do you think? can we, in this patch set, also replce bit
spin_locks with a normal spin_lock?

	-ss