Re: Memory corruption due to word sharing

[Andrew MacLeod]

> > And I assume that since the compiler does them, that would now make it
> > impossible for us to gather a list of all the 'lock' prefixes so that
> > we can undo them if it turns out that we are running on a UP machine.
> >
> > When we do SMP operations, we don't just add a "lock" prefix to it. We do this:
> >
> >    #define LOCK_PREFIX_HERE \
> >                  ".section .smp_locks,\"a\"\n"   \
> >                  ".balign 4\n"                   \
> >                  ".long 671f - .\n" /* offset */ \
> >                  ".previous\n"                   \
> >                  "671:"
> >
> >    #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "

I don't see why  we cant do something  similar when the compiler issues 
a lock on an atomic operation.  I would guess we'd want to put it under 
some sort of flag control (something like -fatomic-lock-list ) since 
most applications aren't going to want that section.  It certainly seems 
plausible to me anyway.
> > and I'm sure you know that, but I'm not sure the gcc people realize
> > the kinds of games we play to make things work better.
No, but someone just needs to tell us -)

> > > > We need both variants in the kernel. If the compiler generates one of
> > > > them for us, that doesn't really much help.
> > > I must admit that the non-x86 per-CPU atomics are, ummm, "interesting".
> > Most non-x86 cpu's would probably be better off treating them the same
> > as smp-atomics (load-locked + store-conditional), but right now we
> > have this insane generic infrastructure for having versions that are
> > irq-safe by disabling interrupts etc. Ugh. Mainly because nobody
> > really is willing to work on and fix up the 25 architectures that
> > really don't matter.
The atomic intrinsics were created for c++11  memory model compliance, 
but I am certainly open to enhancements that would make them more 
useful.   I am planning some enhancements for 4.8 now, and it sounds 
like you may have some suggestions...

Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/