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
| ||
|
Message-Id: <20190412.173458.2194302001630174696.davem@davemloft.net> Date: Fri, 12 Apr 2019 17:34:58 -0700 (PDT) From: David Miller <davem@...emloft.net> To: linux@...ck-us.net Cc: neilb@...e.com, tgraf@...g.ch, herbert@...dor.apana.org.au, netdev@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 0/5] Fix rhashtable bit-locking for m68k From: Guenter Roeck <linux@...ck-us.net> Date: Fri, 12 Apr 2019 11:08:41 -0700 > On 4/11/19 6:52 PM, NeilBrown wrote: >> As reported by Guenter Roeck, the new rhashtable bit-locking >> doesn't work on m68k as it only requires 2-byte alignment, so BIT(1) >> is addresses is not unused. >> We current use BIT(0) to identify a NULLS marker, but that is only >> needed in ->next pointers. The bucket head does not need a NULLS >> marker, so the lsb there can be used for locking. >> the first 4 patches make some small improvements and re-arrange some >> code. The final patch converts to using only BIT(0) for these two >> different special purposes. >> I had previously suggested dropping the series until I fix it. Given >> that this was fairly easy, I retract that I think it best simply to >> add these patches to fix the code. >> > For the series: > > Tested-by: Guenter Roeck <linux@...ck-us.net> Series applied.
Powered by blists - more mailing lists