Messages in this thread | | | Date | Wed, 23 May 2018 12:40:37 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH] vsprintf: Fix memory barriers of ptr_key to have_filed_random_ptr_key |
| |
On Tue 2018-05-15 14:57:44, Steven Rostedt wrote: > On Tue, 15 May 2018 09:55:13 -0700 > Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Tue, May 15, 2018 at 7:06 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > > - smp_mb(); > > > + smp_wmb(); > > > WRITE_ONCE(have_filled_random_ptr_key, true); > > > > > > > + /* Read ptr_key after reading have_filled_random_ptr_key */ > > > + smp_rmb(); > > > + > > > #ifdef CONFIG_64BIT > > > hashval = (unsigned long)siphash_1u64((u64)ptr, &ptr_key); > > > > Hmm. smp_wmb/rmb are basically free on x86, but on some architectures > > smp_rmb() in particular can be pretty expensive. > > > > So when you have a "handoff" situation like this, it's _probably_ better to > > use use "smp_store_release()" and "smp_load_acquire()". To some degree that > > might also be better for documentation purposes, because that's exactly the > > "release-acquire" pattern. > > > > That said, I'm not convinced this really matters all that much for a > > boot-time flag like this. The race is pretty theoretical. > > > > I was thinking the same. But since the smp_mb() is there, then it > should be correct, which it currently isn't. > > We could change this to a static key, and enable it after we set up > the ptr_key. That would be a one time change at boot up, wont have > races, and have no overhead.
OTOH... fixing theoretical races is nice, but probably should not go to stable? Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [unhandled content-type:application/pgp-signature] | |