Re: [PATCH] 2nd try: i386 rw_semaphores fix
Linus Torvalds wrote: > > > On Wed, 11 Apr 2001, Bernd Schmidt wrote: > See? Do you see why a "memory" clobber is _not_ comparable to a "ax" > clobber? And why that non-comparability makes a memory clobber equivalent > to a read-modify-write cycle? I had to think about this, so I'll explain it a different way in case it is helpful. An "ax" clobber says "the whole of eax is undefined after this". In contrast, a "memory" clobber says "we are writing unspecified values to unspecified addresses, but the values are actually valid if you read memory later". All earlier writes to any part of _addressed_ memory (or the named register) must be either discarded, or placed earlier in the instruction stream. For "memory" this is a "compiler write barrier". Addressed memory means everything except local variables whose addresses are not taken. Later reads from memory could be reading from a region that was written by the "memory" clobbering instruction. The compiler doesn't know, so it must assume so. Therefore later reads must be placed later in the instruction stream. This means that "memory" acts as a "compiler read barrier". > In short: I disagree 100%. A "memory" clobber -does- effectively tell the > compiler that memory is read. If the compiler doesn't realize that, then > it's a compiler bug waiting to happen. No ifs, buts of maybes. Indeed. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
Linus Torvalds wrote: On Wed, 11 Apr 2001, Bernd Schmidt wrote: See? Do you see why a "memory" clobber is _not_ comparable to a "ax" clobber? And why that non-comparability makes a memory clobber equivalent to a read-modify-write cycle? I had to think about this, so I'll explain it a different way in case it is helpful. An "ax" clobber says "the whole of eax is undefined after this". In contrast, a "memory" clobber says "we are writing unspecified values to unspecified addresses, but the values are actually valid if you read memory later". All earlier writes to any part of _addressed_ memory (or the named register) must be either discarded, or placed earlier in the instruction stream. For "memory" this is a "compiler write barrier". Addressed memory means everything except local variables whose addresses are not taken. Later reads from memory could be reading from a region that was written by the "memory" clobbering instruction. The compiler doesn't know, so it must assume so. Therefore later reads must be placed later in the instruction stream. This means that "memory" acts as a "compiler read barrier". In short: I disagree 100%. A "memory" clobber -does- effectively tell the compiler that memory is read. If the compiler doesn't realize that, then it's a compiler bug waiting to happen. No ifs, buts of maybes. Indeed. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
On Wed, 11 Apr 2001, Bernd Schmidt wrote: > > > > The example in there compiles out-of-the box and is much easier to > > experiment on than the whole kernel :-) > > That example seems to fail because a "memory" clobber only tells the compiler > that memory is written, not that it is read. The above makes no sense. The notion of "memory is written" is a true superset of the "memory is read", and must be a complete memory barrier (ie telling the compiler that "we read memory" is non-sensical: it can't give the compiler any more information). Because the memory clobber doesn't tell _what_ memory is clobbered, you cannot consider memory dead after the instruction. As such, the compiler HAS to treat a clobber as a "read-modify-write" - because on a very fundamental level it _is_. Clobbering memory is logically 100% equivalent to reading all of memory, modifying some of it, and writing the modified information back. (This is different from a "clobber specific register" thing, btw, where the compiler can honestly assuem that the register is dead after the instruction and contains no useful data. That is a write-only dependency, and means that gcc can validly use optimization techniques like removing previous dead writes to the register.) See? Do you see why a "memory" clobber is _not_ comparable to a "ax" clobber? And why that non-comparability makes a memory clobber equivalent to a read-modify-write cycle? In short: I disagree 100%. A "memory" clobber -does- effectively tell the compiler that memory is read. If the compiler doesn't realize that, then it's a compiler bug waiting to happen. No ifs, buts of maybes. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
On Wed, 11 Apr 2001, Andreas Franck wrote: > Hello David, > > > I've been discussing it with some other kernel and GCC people, and they > > think > > that only "memory" is required. > > Hmm.. I just looked at my GCC problem report from December, perhaps you're > interested, too: > > http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00554.html > > The example in there compiles out-of-the box and is much easier to > experiment on than the whole kernel :-) That example seems to fail because a "memory" clobber only tells the compiler that memory is written, not that it is read. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
Hello David, > I've been discussing it with some other kernel and GCC people, and they > think > that only "memory" is required. Hmm.. I just looked at my GCC problem report from December, perhaps you're interested, too: http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00554.html The example in there compiles out-of-the box and is much easier to experiment on than the whole kernel :-) It should reflect the situation in the kernel as of December 2000, where no outputs were declared at all. I can try this examples again with current GCC snapshots and will see if I can find a working solution without reserving more registers. > Apart from the risk of breaking it, you mean? Well, "=m" seems to reserve > an > extra register to hold a second copy of the semaphore address, probably > since > it thinks EAX might get clobbered. > > Also, as a minor point, it probably ought to be "+m" not "=m". Perhaps, I'm no real expert on this things, and "=m" worked for me, so I used it :) Greetings, Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
I've been discussing it with some other kernel and GCC people, and they think that only "memory" is required. > What are the reasons against mentioning sem->count directly as a "=m" > reference? This makes the whole thing less fragile and no more dependent > on the memory layout of the structure. Apart from the risk of breaking it, you mean? Well, "=m" seems to reserve an extra register to hold a second copy of the semaphore address, probably since it thinks EAX might get clobbered. Also, as a minor point, it probably ought to be "+m" not "=m". David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
Hello David and people, > I've just consulted with one of the gcc people we have here, and he says > that > the '"memory"' constraint should do the trick. > > Do I take it that that is actually insufficient? I don't remember exactly, it's been a while, but I think it was not sufficient when I came up with this change. I can look at it in a few hours. The GCC manual is not really precise here: > If your assembler instruction modifies memory in an unpredictable fashion, > add `memory' to the list of clobbered registers. This will cause GNU CC to > not keep memory values cached in registers across the assembler > instruction. You will also want to add the volatile keyword if the memory > affected is not listed in the inputs or outputs of the > asm, as the `memory' clobber does not count as a side-effect of the asm. So 'memory' alone won't probably do the trick, as caching is not the problem here, but the unknown storage size of the semaphore. Perhaps the __voaltile__ will help, but I don't know. What are the reasons against mentioning sem->count directly as a "=m" reference? This makes the whole thing less fragile and no more dependent on the memory layout of the structure. Greetings, Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
> I'd like you to look over it. It seems newer GCC's (snapshots and the > upcoming 3.0) will be more strict when modifying some values through > assembler-passed pointers - in this case, the passed semaphore structure got > freed too early, causing massive stack corruption on early bootup. > > The solution was to directly mention the modified element (in this case, > sem->count) with a "=m" qualifier, which told GCC that the contents of the > semaphore structure are still really needed. It does not seem to have any > bad side effects on older GCC, but lets the code work on people trying to > use the newer snapshots. I've just consulted with one of the gcc people we have here, and he says that the '"memory"' constraint should do the trick. Do I take it that that is actually insufficient? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
I'd like you to look over it. It seems newer GCC's (snapshots and the upcoming 3.0) will be more strict when modifying some values through assembler-passed pointers - in this case, the passed semaphore structure got freed too early, causing massive stack corruption on early bootup. The solution was to directly mention the modified element (in this case, sem-count) with a "=m" qualifier, which told GCC that the contents of the semaphore structure are still really needed. It does not seem to have any bad side effects on older GCC, but lets the code work on people trying to use the newer snapshots. I've just consulted with one of the gcc people we have here, and he says that the '"memory"' constraint should do the trick. Do I take it that that is actually insufficient? David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
Hello David and people, I've just consulted with one of the gcc people we have here, and he says that the '"memory"' constraint should do the trick. Do I take it that that is actually insufficient? I don't remember exactly, it's been a while, but I think it was not sufficient when I came up with this change. I can look at it in a few hours. The GCC manual is not really precise here: If your assembler instruction modifies memory in an unpredictable fashion, add `memory' to the list of clobbered registers. This will cause GNU CC to not keep memory values cached in registers across the assembler instruction. You will also want to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm, as the `memory' clobber does not count as a side-effect of the asm. So 'memory' alone won't probably do the trick, as caching is not the problem here, but the unknown storage size of the semaphore. Perhaps the __voaltile__ will help, but I don't know. What are the reasons against mentioning sem-count directly as a "=m" reference? This makes the whole thing less fragile and no more dependent on the memory layout of the structure. Greetings, Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
I've been discussing it with some other kernel and GCC people, and they think that only "memory" is required. What are the reasons against mentioning sem-count directly as a "=m" reference? This makes the whole thing less fragile and no more dependent on the memory layout of the structure. Apart from the risk of breaking it, you mean? Well, "=m" seems to reserve an extra register to hold a second copy of the semaphore address, probably since it thinks EAX might get clobbered. Also, as a minor point, it probably ought to be "+m" not "=m". David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
Hello David, I've been discussing it with some other kernel and GCC people, and they think that only "memory" is required. Hmm.. I just looked at my GCC problem report from December, perhaps you're interested, too: http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00554.html The example in there compiles out-of-the box and is much easier to experiment on than the whole kernel :-) It should reflect the situation in the kernel as of December 2000, where no outputs were declared at all. I can try this examples again with current GCC snapshots and will see if I can find a working solution without reserving more registers. Apart from the risk of breaking it, you mean? Well, "=m" seems to reserve an extra register to hold a second copy of the semaphore address, probably since it thinks EAX might get clobbered. Also, as a minor point, it probably ought to be "+m" not "=m". Perhaps, I'm no real expert on this things, and "=m" worked for me, so I used it :) Greetings, Andreas -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
On Wed, 11 Apr 2001, Andreas Franck wrote: Hello David, I've been discussing it with some other kernel and GCC people, and they think that only "memory" is required. Hmm.. I just looked at my GCC problem report from December, perhaps you're interested, too: http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00554.html The example in there compiles out-of-the box and is much easier to experiment on than the whole kernel :-) That example seems to fail because a "memory" clobber only tells the compiler that memory is written, not that it is read. Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2nd try: i386 rw_semaphores fix
On Wed, 11 Apr 2001, Bernd Schmidt wrote: The example in there compiles out-of-the box and is much easier to experiment on than the whole kernel :-) That example seems to fail because a "memory" clobber only tells the compiler that memory is written, not that it is read. The above makes no sense. The notion of "memory is written" is a true superset of the "memory is read", and must be a complete memory barrier (ie telling the compiler that "we read memory" is non-sensical: it can't give the compiler any more information). Because the memory clobber doesn't tell _what_ memory is clobbered, you cannot consider memory dead after the instruction. As such, the compiler HAS to treat a clobber as a "read-modify-write" - because on a very fundamental level it _is_. Clobbering memory is logically 100% equivalent to reading all of memory, modifying some of it, and writing the modified information back. (This is different from a "clobber specific register" thing, btw, where the compiler can honestly assuem that the register is dead after the instruction and contains no useful data. That is a write-only dependency, and means that gcc can validly use optimization techniques like removing previous dead writes to the register.) See? Do you see why a "memory" clobber is _not_ comparable to a "ax" clobber? And why that non-comparability makes a memory clobber equivalent to a read-modify-write cycle? In short: I disagree 100%. A "memory" clobber -does- effectively tell the compiler that memory is read. If the compiler doesn't realize that, then it's a compiler bug waiting to happen. No ifs, buts of maybes. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
