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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 7 Aug 2020 08:22:36 +0800 From: Guo Ren <guoren@...nel.org> To: Peter Zijlstra <peterz@...radead.org> Cc: Ren Guo <ren_guo@...ky.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-csky@...r.kernel.org, mathieu.desnoyers@...icios.com, Will Deacon <will@...nel.org> Subject: Re: csky: smp_mb__after_spinlock Hi Peter, On Thu, Aug 6, 2020 at 3:53 AM <peterz@...radead.org> wrote: > > Hi, > > While doing an audit of smp_mb__after_spinlock, I found that csky > defines it, why? > > CSKY only has smp_mb(), it doesn't override __atomic_acquire_fence or > otherwise special cases it's atomic*_acquire() primitives. It has an > explicit smp_mb() in its arch_spin_lock(). Yes, csky didn't implement ACQUIRE/RELEASE in spinlock.h. So it is a redundant and side-effect wrong macro, we should remove it to fixup. TODO: - implement csky's ACQUIRE/RELEASE barrier > Also, why have two implementations of all the locking? I just kept my baby's codes :P. Now, we could remove it and just keep the ticket's one. BTW, I want to change the spinlock to qspinlock, but csky only has 32-bit atomic operation in hardware. Any plan to deal with this in spinlock? Maybe for the embedded scenario, qspinlock seems a bit heavy, are any tickets-like comm spinlock infrastructures in the plan? -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
Powered by blists - more mailing lists