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
| ||
|
Date: Mon, 30 Mar 2015 18:59:56 +0200 From: Borislav Petkov <bp@...en8.de> To: Dave Hansen <dave@...1.net> Cc: linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de, dave.hansen@...ux.intel.com Subject: Re: [PATCH 15/17] x86, mpx: do 32-bit-only cmpxchg for 32-bit apps On Mon, Mar 30, 2015 at 09:57:14AM -0700, Dave Hansen wrote: > > + if (is_64bit_mm(mm)) > > + return user_atomic_cmpxchg_inatomic(actual_old_val_ptr, > > + bd_entry_addr, > > + expected_old_val, > > + new_bd_entry); > > + else > > + return futex_atomic_cmpxchg_inatomic((u32 *)actual_old_val_ptr, > > + (u32 __user *)bd_entry_addr, > > + expected_old_val, > > + new_bd_entry); > > } > > That does look tempting, and I appreciate the analysis. > > But, I'd really rather not hide this behind another layer of abstraction > in order to save a few variable declarations. It's definitely _smaller_ > code, but it's a little less obvious what is going on. If you rename futex_atomic_cmpxchg_inatomic to atomic_cmpxchg_inatomic_32 or so, it is perfectly clear what's going on. if (is_64bit_mm()) return user_atomic_cmpxchg_inatomic() else /* 32-bit */ return user_atomic_cmpxchg_inatomic_32() It can't get any more obvious than that. :-D -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists