Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

On Thu, Aug 25, 2022 at 7:38 AM Joseph Myers wrote: > > I've not yet implemented it for glibc or for GCC format checking, but C23 > adds 'wN' format length modifiers so you will be able to e.g. use "%w64d" > with printf to print an int64_t and won't need those PRI macros any more. Yeah, that's

Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar wrote: > > This patch is not about kernel, but about the section 2 and 3 manual > pages, which are directed towards user-space readers most of the time. They are about the types to the kernel interfaces. Those types that the kernel defines and

Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer wrote: > > The justifications brought forward are just regurgitating previous > misinformation. If you do that, it's hard to take you seriously. Pot, meet kettle. > There is actually a good reason for using __u64: it's always based on > long

Re: [PATCH v3] Many pages: Document fixed-width types with ISO C naming

On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar wrote: > > I'm trying to be nice, and ask for review to make sure I'm not making > some big mistake by accident, and I get disrespect? No thanks. You've been told multiple times that the kernel doesn't use the "standard" names, and *cannot* use

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:13 AM Linus Torvalds wrote: > > > +#define __unqual_typeof(type) typeof( (typeof(type))type ) > > that's certainly a much nicer version than the existing pre-processor > expansion from hell. Oh, and sparse doesn't handle this, and doesn't rem

Re: Re: typeof and operands in named address spaces

On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote: > > It would need to be typeof( (typeof(type)) (type) ) to not be that > constrained on what kind of expressions it accepts as arguments. Yup. > Anyway, it won't work with array types at least, > int a[10]; > typeof ((typeof (a)) (a)) b;

Re: Re: typeof and operands in named address spaces

On Mon, Nov 16, 2020 at 3:11 AM Peter Zijlstra wrote: > > XXX: I've only verified the below actually compiles, I've not verified > the generated code is actually 'correct'. Well, it was mainly the arm64 code generation for load-acquire and store-release that wanted this - so it's really the

Re: [PATCH] x86/retpoline: Switch thunk names to match final GCC patches

On Sun, Jan 14, 2018 at 3:23 PM, David Woodhouse wrote: > I think we *shouldn't* do this. Uros said we could look at it and make > a decision, and GCC would implement what we decide. Up to Linus. Regardless of whether we end up having to do this, I'm not doing rc8 with it, and

Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

On Sun, Jan 14, 2018 at 3:09 PM, David Woodhouse wrote: > > I think we should stick with what we have now, with the names of the > thunks actually being the *full* name of the register (rax, eax, etc.) > that they use. It that works for the gcc people, then yes, I agree. The

Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

On Sun, Jan 14, 2018 at 2:39 PM, David Woodhouse wrote: > > I'm not convinced we want to do this, but I'll defer to Linus. Well, I guess we have no choice, if gcc ends up using the stupid names. And yes, apparently this just made our macros worse instead of cleaning

Re: [PATCH 0/5] x86: CVE-2017-5715, aka Spectre

On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote: > Review on the GCC patches has led to a request that the thunk symbols > be changed from e.g. __x86_indirect_thunk_rax to > __x86_indirect_thunk_ax without the 'r'. Ok. I think that just makes it easier for us, since

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

On Mon, Feb 29, 2016 at 9:37 AM, Michael Matz wrote: > >The important part is with induction variables controlling > loops: > > short i; for (i = start; i < end; i++) > vs. > unsigned short u; for (u = start; u < end; u++) > > For the former you're allowed to assume that the

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf wrote: >> > >> > -fno-strict-overflow >> >> -fno-strict-aliasing. > > Do not forget -fno-delete-null-pointer-checks. > > So the kernel obviously is already using its own C dialect, that is > pretty far from standard

Re: Compilers and RCU readers: Once more unto the breach!

On Thu, May 21, 2015 at 1:02 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: The compiler can (and does) speculate non-atomic non-volatile writes in some cases, but I do not believe that it is permitted to speculate either volatile or atomic writes. I do *not* believe that a compiler

Re: Compilers and RCU readers: Once more unto the breach!

On Tue, May 19, 2015 at 5:55 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: http://www.rdrop.com/users/paulmck/RCU/consume.2015.05.18a.pdf From a very quick read-through, the restricted dependency chain in 7.9 seems to be reasonable, and essentially covers thats' what hardware

Re: Compilers and RCU readers: Once more unto the breach!

On Tue, May 19, 2015 at 6:57 PM, Linus Torvalds torva...@linux-foundation.org wrote: - the you can add/subtract integral values still opens you up to language lawyers claiming (char *)ptr - (intptr_t)ptr preserving the dependency, which it clearly doesn't. But language-lawyering it does

Re: [RFC] Design for flag bit outputs from asms

On Tue, May 5, 2015 at 6:50 AM, Segher Boessenkool seg...@kernel.crashing.org wrote: Since it is pre-processed, there is no real reason to overlap this with the constraints namespace; we could have e.g. =@[xy] (and @[xy] for inputs) mean the target needs to do some xy transform here. In fact,

Re: [RFC] Design for flag bit outputs from asms

On Mon, May 4, 2015 at 1:14 PM, H. Peter Anvin h...@zytor.com wrote: I would argue that for x86 what you actually want is to model the *conditions* that are available on the flags, not the flags themselves. Yes. Otherwise it would be a nightmare to try to describe simple conditions like le,

Re: [RFC] Design for flag bit outputs from asms

On Mon, May 4, 2015 at 1:33 PM, Richard Henderson r...@redhat.com wrote: A fair point. Though honestly, I was hoping that this feature would mostly be used for conditions that are weird -- that is, not normally describable by arithmetic at all. Otherwise, why are you using inline asm for it?

Re: [PATCH] tell gcc optimizer to never introduce new data races

On Tue, Jun 10, 2014 at 6:23 AM, Jiri Kosina jkos...@suse.cz wrote: We have been chasing a memory corruption bug, which turned out to be caused by very old gcc (4.3.4), which happily turned conditional load into a non-conditional one, and that broke correctness (the condition was met only if

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel trie...@redhat.com wrote: I agree that just considering syntactic properties of the program seems to be insufficient. Making it instead depend on whether there is a semantic dependency due to a value being necessary to compute a result seems

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: 3. The comparison was against another RCU-protected pointer, where that other pointer was properly fetched using one of the RCU primitives. Here it doesn't matter which pointer

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 10:00 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: So let me see if I understand your reasoning. My best guess is that it goes something like this: 1. The Linux kernel contains code that passes pointers from rcu_dereference() through external

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 23, 2014 at 11:31 AM, Linus Torvalds torva...@linux-foundation.org wrote: Let me think about it some more, but my gut feel is that just tweaking the definition of what ordered means is sufficient. So to go back to the suggested ordering rules (ignoring the restrict part, which

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 8:27 AM, Richard Biener richard.guent...@gmail.com wrote: To me that reads like int i; int *q = i; int **p = q; atomic_XXX (p, CONSUME); orders against accesses '*p', '**p', '*q' and 'i'. Thus it seems they want to say that it orders against aliased

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 8:37 AM, Linus Torvalds torva...@linux-foundation.org wrote: So yes, the atomic_read() would be ordered wrt '*ptr' (getting 'q') _and_ '**ptr' (getting 'i'), but nothing else - including just the aliasing access of dereferencing 'i' directly. Btw, what CPU architects

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 8:55 AM, Michael Matz m...@suse.de wrote: So, let me try to poke holes into your definition or increase my understanding :) . You said chain of pointers(dereferences I assume), e.g. if p is result of consume load, then access to p-here-there-next-prev-stuff is

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 9:21 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: 4. Bitwise operators (, |, ^, and I suppose also ~) applied to a chained pointer and an integer results in another chained pointer in that same pointer chain. No. You cannot define it this

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Good points. How about the following replacements? 3. Adding or subtracting an integer to/from a chained pointer results in another chained pointer in that same pointer chain. The

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 2:37 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: What if the nothing modifies 'p' part looks like this: if (p != myvariable) return; and now any sane compiler will happily optimize q = *p into q = myvariable, and we're all done - nothing

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 24, 2014 at 3:35 PM, Linus Torvalds torva...@linux-foundation.org wrote: Litmus test 1: p = atomic_read(pp, consume); if (p == variable) return p-val; is *NOT* ordered Btw, don't get me wrong. I don't _like_ it not being ordered, and I actually did spend

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sat, Feb 22, 2014 at 10:34 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Adding and subtracting integers to/from a RCU-protected pointer makes sense to me. Ack. And that's normal access to an object behavior anyway. Adding and subtracting integers to/from an RCU-protected integer

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 23, 2014 at 5:16 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: (a) we've said 'q' is restricted, so there is no aliasing between q and the pointers b/c. So the compiler is free to move those accesses around the q = p-next access. Ah, if I understand you, very good! My

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 23, 2014 at 8:59 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: On Sun, Feb 23, 2014 at 05:35:28PM -0800, Linus Torvalds wrote: But q = p-next is ordered by how something can alias p-next, not by 'q'! There is no need to restrict anything but 'p' for all of this to work

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sat, Feb 22, 2014 at 10:53 AM, Torvald Riegel trie...@redhat.com wrote: Stating that (1) the standard is wrong and (2) that you think that mo_consume semantics are not good is two different things. I do agree. They are two independent things. I think the standard is wrong, because it's

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sat, Feb 22, 2014 at 4:39 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Agreed, by far the most frequent use is - to dereference and assignment to store into a local variable. The other operations where the kernel expects ordering to be maintained are: o Bitwise to strip

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 21, 2014 at 10:25 AM, Peter Sewell peter.sew...@cl.cam.ac.uk wrote: If one thinks this is too fragile, then simply using memory_order_acquire and paying the resulting barrier cost (and perhaps hoping that compilers will eventually be able to optimise some cases of those barriers to

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 21, 2014 at 11:16 AM, Linus Torvalds torva...@linux-foundation.org wrote: Why would this be any different, especially since it's easy to understand both for a human and a compiler? Btw, the actual data path may actually be semantically meaningful even at a processor level

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 21, 2014 at 11:43 AM, Peter Sewell peter.sew...@cl.cam.ac.uk wrote: You have to track dependencies through other assignments, e.g. simple x=y That is all visible in the SSA form. Variable assignment has been converted to some use of the SSA node that generated the value. The use

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 12:30 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: So lets make this really simple: if you have a consume-cmp-read, is the ordering of the two reads guaranteed? Not as far as I know. Also, as far as I know, there is no difference between consume and relaxed

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 9:14 AM, Torvald Riegel trie...@redhat.com wrote: So the clarification is basically to the statement that the if (consume(p)) a version *would* have an ordering guarantee between the read of p and a, but the consume(p) ? a : b would *not* have such an ordering

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 9:49 AM, Torvald Riegel trie...@redhat.com wrote: Yes, mo_consume is more tricky than mo_acquire. However, that has an advantage because you can avoid getting stronger barriers if you don't need them (ie, you can avoid the auto-update to acquire you seem to have in

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: You really need that consume to be acquire. So I think we now all agree that that is what the standard is saying. And I'm saying that that is wrong, that the standard is badly written, and should be fixed.

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 10:25 AM, Linus Torvalds torva...@linux-foundation.org wrote: While in my *sane* model, where you can consume things even if they then result in control dependencies, there will still eventually be a sync instruction on powerpc (because you really need one between

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 11:02 AM, Linus Torvalds torva...@linux-foundation.org wrote: Again, the way I'd expect a compiler writer to actually *do* this is to just default to ac Oops, pressed send by mistake too early. I was almost done: I'd expect a compiler to just default to acquire

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 10:53 AM, Torvald Riegel trie...@redhat.com wrote: On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote: On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: You really need that consume to be acquire. So I think we now all agree

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 10:56 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: The example gcc breakage was something like this: i = atomic_load(idx, memory_order_consume); x = array[0 + i - i]; Then gcc optimized this to: i = atomic_load(idx,

Re: [RFC][PATCH 0/5] arch: atomic rework

On Thu, Feb 20, 2014 at 2:10 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Linus, given that you are calling me out for pushing legalistic and bad things, syntactic bullshit, and playing little games, I am forced to conclude that you have never attended any sort of standards-committee

Re: [RFC][PATCH 0/5] arch: atomic rework

On Wed, Feb 19, 2014 at 6:40 AM, Torvald Riegel trie...@redhat.com wrote: If all those other threads written in whichever way use the same memory model and ABI for synchronization (e.g., choice of HW barriers for a certain memory_order), it doesn't matter whether it's a hardware thread,

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 11:47 AM, Torvald Riegel trie...@redhat.com wrote: On Tue, 2014-02-18 at 09:44 -0800, Linus Torvalds wrote: Can you point to it? Because I can find a draft standard, and it sure as hell does *not* contain any clarity of the model. It has a *lot* of verbiage, but it's

Re: [RFC][PATCH 0/5] arch: atomic rework

On Wed, Feb 19, 2014 at 8:01 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: The control dependency should order subsequent stores, at least assuming that a and b don't start off with identical stores that the compiler could pull out of the if and merge. The same might also be true for

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 7:31 AM, Torvald Riegel trie...@redhat.com wrote: On Mon, 2014-02-17 at 16:05 -0800, Linus Torvalds wrote: And exactly because I know enough, I would *really* like atomics to be well-defined, and have very clear - and *local* - rules about how they can be combined

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 4:12 AM, Peter Sewell peter.sew...@cl.cam.ac.uk wrote: For example, suppose we have, in one compilation unit: void f(int ra, int*rb) { if (ra==42) *rb=42; else *rb=42; } So this is a great example, and in general I really like

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 8:17 AM, Torvald Riegel trie...@redhat.com wrote: Consume operation: no reads in the current thread dependent on the value currently loaded can be reordered before this load I can't remember seeing that language in the standard (ie, C or C++). Where is this from?

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 10:21 AM, Peter Sewell peter.sew...@cl.cam.ac.uk wrote: This is a bit more subtle, because (on ARM and POWER) removing the dependency and conditional branch is actually in general *not* equivalent in the hardware, in a concurrent context. So I agree, but I think that's

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 10:23 AM, Peter Sewell peter.sew...@cl.cam.ac.uk wrote: interesting list. So are you saying that value-range-analysis and such-like (I say glibly, without really knowing what such-like refers to here) are fundamentally incompatible with the kernel code No, it's fine

Re: [RFC][PATCH 0/5] arch: atomic rework

On Tue, Feb 18, 2014 at 1:21 PM, Torvald Riegel trie...@redhat.com wrote: So imagine that you have some clever global optimizer that sees that the program never ever actually sets the dirty bit at all in any thread, and then uses that kind of non-local knowledge to make optimization

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 11:55 AM, Torvald Riegel trie...@redhat.com wrote: Which example do you have in mind here? Haven't we resolved all the debated examples, or did I miss any? Well, Paul seems to still think that the standard possibly allows speculative writes or possibly value

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 1:21 PM, Torvald Riegel trie...@redhat.com wrote: On Mon, 2014-02-17 at 12:18 -0800, Linus Torvalds wrote: and then it is read by people (compiler writers) that intentionally try to mis-use the words and do language-lawyering (that depends on what the meaning

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 2:09 PM, Torvald Riegel trie...@redhat.com wrote: On Sat, 2014-02-15 at 11:15 -0800, Linus Torvalds wrote: if (atomic_load(x, mo_relaxed) == 1) atomic_store(y, 3, mo_relaxed)); No, please don't use this idiotic example. It is wrong. It won't be useful

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 2:25 PM, Torvald Riegel trie...@redhat.com wrote: On Mon, 2014-02-17 at 14:02 -0800, Linus Torvalds wrote: The argument was that an lvalue doesn't actually access the memory (an rvalue does), so this: volatile int *p = ...; *p; doesn't need to generate

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 3:10 PM, Alec Teal a.t...@warwick.ac.uk wrote: You mean unambiguous - try reading a patent (Apple have 1000s of trivial ones, I tried reading one once thinking how could they have phrased it so this got approved, their technique was to make the reader want to start

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 3:17 PM, Torvald Riegel trie...@redhat.com wrote: On Mon, 2014-02-17 at 14:32 -0800, Stop claiming it can return 1.. It *never* returns 1 unless you do the load and *verify* it, or unless the load itself can be made to go away. And with the code sequence given, that

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 3:41 PM, Torvald Riegel trie...@redhat.com wrote: There's an underlying problem here that's independent from the actual instance that you're worried about here: no sense is a ultimately a matter of taste/objectives/priorities as long as the respective specification is

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 7:00 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: One example that I learned about last week uses the branch-prediction hardware to validate value speculation. And no, I am not at all a fan of value speculation, in case you were curious. Heh. See the example

Re: [RFC][PATCH 0/5] arch: atomic rework

On Mon, Feb 17, 2014 at 7:24 PM, Linus Torvalds torva...@linux-foundation.org wrote: As far as I can tell, the intent is that you can't do value speculation (except perhaps for the relaxed, which quite frankly sounds largely useless). Hmm. The language I see for consume is not obvious

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sat, Feb 15, 2014 at 9:45 AM, Torvald Riegel trie...@redhat.com wrote: I think a major benefit of C11's memory model is that it gives a *precise* specification for how a compiler is allowed to optimize. Clearly it does *not*. This whole discussion is proof of that. It's not at all clear,

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sat, Feb 15, 2014 at 9:30 AM, Torvald Riegel trie...@redhat.com wrote: I think the example is easy to misunderstand, because the context isn't clear. Therefore, let me first try to clarify the background. (1) The abstract machine does not write speculatively. (2) Emitting a branch

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Linus, Peter, any objections to marking places where we are relying on ordering from control dependencies against later stores? This approach seems to me to have significant documentation benefits. Quite

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds torva...@linux-foundation.org wrote: Why are we still discussing this idiocy? It's irrelevant. If the standard really allows random store speculation, the standard doesn't matter, and sane people shouldn't waste their time arguing about it. Btw

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: One way of looking at the discussion between Torvald and myself would be as a seller (Torvald) and a buyer (me) haggling over the fine print in a proposed contract (the standard). Whether that makes you feel

Re: [RFC][PATCH 0/5] arch: atomic rework

On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds torva...@linux-foundation.org wrote: And conversely, the C11 people can walk away from us too. But if they can't make us happy (and by make us happy, I really mean no stupid games on our part) I personally think they'll have a stronger standard

Re: [RFC][PATCH 0/5] arch: atomic rework

On Wed, Feb 12, 2014 at 10:07 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: Us Linux-kernel hackers will often need to use volatile semantics in combination with C11 atomics in most cases. The C11 atomics do cover some of the reasons we currently use ACCESS_ONCE(), but not all of

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: Intuitively, this is wrong because this let's the program take a step the abstract machine wouldn't do. This is different to the sequential code that Peter posted because it uses atomics, and thus one can't easily

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 9, 2014 at 4:27 PM, Torvald Riegel trie...@redhat.com wrote: I wouldn't characterize the situation like this (although I can't speak for others, obviously). IMHO, it's perfectly fine on sequential / non-synchronizing code, because we know the difference isn't observable by a

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 9, 2014 at 5:16 PM, Torvald Riegel trie...@redhat.com wrote: (a) seems to say that you don't like requiring programmers to mark atomic accesses specially. Is that the case? In Paul's example, they were marked specially. And you seemed to argue that Paul's example could possibly

Re: [RFC][PATCH 0/5] arch: atomic rework

On Sun, Feb 9, 2014 at 5:46 PM, Torvald Riegel trie...@redhat.com wrote: IOW, I wrote that such a compiler transformation would be wrong in my opinion. Thus, it should *not* return 42. Ahh, I am happy to have misunderstood. The intuitively threw me, because I thought that was building up to a

Re: [RFC] gcc feature request: Moving blocks into sections

On Tue, Aug 6, 2013 at 7:19 AM, Steven Rostedt rost...@goodmis.org wrote: After playing with the patches again, I now understand why I did that. It wasn't just for optimization. [explanation snipped] Anyway, if you feel that update_jump_label is too complex, I can go the update at early

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 9:55 AM, Steven Rostedt rost...@goodmis.org wrote: Almost a full year ago, Mathieu suggested something like: if (unlikely(x)) __attribute__((section(.unlikely))) { ... } else __attribute__((section(.likely))) { ... } It's almost certainly a horrible

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 10:12 AM, Linus Torvalds torva...@linux-foundation.org wrote: Secondly, you don't want a separate section anyway for any normal kernel code, since you want short jumps if possible Just to clarify: the short jump is important regardless of how unlikely the code you're

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 10:55 AM, Steven Rostedt rost...@goodmis.org wrote: My main concern is with tracepoints. Which on 90% (or more) of systems running Linux, is completely off, and basically just dead code, until someone wants to see what's happening and enables them. The

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 11:20 AM, Linus Torvalds torva...@linux-foundation.org wrote: The static_key_false() approach with minimal inlining sounds like a much better approach overall. Sorry, I misunderstood your thing. That's actually what you want that section thing for, because right now you

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds torva...@linux-foundation.org wrote: Ugh. I can see the attraction of your section thing for that case, I just get the feeling that we should be able to do better somehow. Hmm.. Quite frankly, Steven, for your use case I think you actually want

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 11:39 AM, Steven Rostedt rost...@goodmis.org wrote: I had patches that did exactly this: https://lkml.org/lkml/2012/3/8/461 But it got dropped for some reason. I don't remember why. Maybe because of the complexity? Ugh. Why the crazy update_jump_label script stuff?

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 11:51 AM, H. Peter Anvin h...@linux.intel.com wrote: Also, how would you pass the parameters? Every tracepoint has its own parameters to pass to it. How would a trap know what where to get prev and next? How do you do that now? You have to do an IP lookup to find out

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 12:04 PM, Andi Kleen a...@firstfloor.org wrote: Steven Rostedt rost...@goodmis.org writes: Can't you just use -freorder-blocks-and-partition? This should already partition unlikely blocks into a different section. Just a single one of course. That's horrible. Not

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 12:40 PM, Marek Polacek pola...@redhat.com wrote: FWIW, we also support hot/cold attributes for labels, thus e.g. if (bar ()) goto A; /* ... */ A: __attribute__((cold)) /* ... */ I don't know whether that might be useful for what you want or not though...

Re: [RFC] gcc feature request: Moving blocks into sections

On Mon, Aug 5, 2013 at 12:54 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: I remember that choosing between 2 and 5 bytes nop in the asm goto was tricky: it had something to do with the fact that gcc doesn't know the exact size of each instructions until further down within

Re: Memory corruption due to word sharing

On Fri, Feb 3, 2012 at 8:38 AM, Andrew MacLeod amacl...@redhat.com wrote: 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

Re: Memory corruption due to word sharing

On Fri, Feb 3, 2012 at 11:16 AM, Andrew MacLeod amacl...@redhat.com wrote:    The special cases are because older x86 cannot do the generic add_return efficiently - it needs xadd - but can do atomic versions that test the end result and give zero or sign information. Since these are older x86

Re: Memory corruption due to word sharing

On Thu, Feb 2, 2012 at 8:28 AM, Michael Matz m...@suse.de wrote: Sure.  Simplest example: struct s {int i:24;} __attribute__((packed)). You must access only three bytes, no matter what.  The basetype (int) is four bytes. Ok, so here's a really *stupid* (but also really really simple) patch

Re: Memory corruption due to word sharing

On Thu, Feb 2, 2012 at 10:42 AM, Paul E. McKenney paul...@linux.vnet.ibm.com wrote: SMP-atomic or percpu atomic? Or both? Only SMP-atomic. 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

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 7:19 AM, Jan Kara j...@suse.cz wrote:  we've spotted the following mismatch between what kernel folks expect from a compiler and what GCC really does, resulting in memory corruption on some architectures. This is sad. We've had something like this before due to

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 8:37 AM, Colin Walters walt...@verbum.org wrote: 1) Use the same lock for a given bitfield That's not the problem. All the *bitfield* fields are all accessed under the same word already. 2) Split up the bitfield into different words Again, it's not the bitfield that is

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 9:08 AM, Torvald Riegel trie...@redhat.com wrote: What do the kernel folks think about the C11 memory model?  If you can spot any issues in there, the GCC community would certainly like to know. I don't think this is about memory models except very tangentially. Gcc

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 9:11 AM, Jiri Kosina jkos...@suse.cz wrote: On Wed, 1 Feb 2012, Linus Torvalds wrote: And I suspect it really is a generic bug that can be shown even with the above trivial example. I have actually tried exactly this earlier today (because while looking at this, I had

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 9:41 AM, Michael Matz m...@suse.de wrote: One problem is that it's not a new problem, GCC emitted similar code since about forever, and still they turned up only now (well, probably because ia64 is dead, but sparc64 should have similar problems).  The bitfield handling

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 10:09 AM, David Miller da...@davemloft.net wrote: Personally I've avoided C bitfields like the plague in any code I've written. I do agree with that. The kernel largely tries to avoid bitfields, usually because we have some really strict rules about different bitfields,

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 10:45 AM, Jeff Law l...@redhat.com wrote: Torvald Riegel I were told that was kernel policy when we brought up the upcoming bitfield semantic changes with some of the linux kernel folks last year. Btw, one reason this is true is that the bitfield ordering/packing is so

Re: Memory corruption due to word sharing

On Wed, Feb 1, 2012 at 9:42 AM, Torvald Riegel trie...@redhat.com wrote: We need a proper memory model. Not really. The fact is, the kernel will happily take the memory model of the underlying hardware. Trying to impose some compiler description of the memory model is actually horribly bad,

  1   2   >