LINUS_RANTS.csv

0
What the heck is your problem? Go back and read it. If it wasn't loaded before, THEN IT WASN'T WORKING BEFORE EITHER! ... Why the hell do you keep on harping on idiotic issues? Stop being a moron, just repeat after me: A caching firmware loader fixes all these issues and is simple to boot. Stop the idiotic blathering already.
Why do you make up all these idiotic theoretical cases that nobody cares about and has no relevance what-so-ever for the 99%? Seriously? It's just stupid. ... You seem to intentionally be off in some random alternate reality that is not relevant to anybody else, or to the actual reported problems at hand.
Whjat the fuck is the logic there? Just fix the obvious breakage in BLKROSET. It's clearly what the code intends to do, it just didn't check for ENOIOCTLCMD. ... It's a DISEASE how you seem to think that "we have ugly mistakes in the kernel, SO LET'S ADD ANOTHER ONE". That's not how we do things. We fix things, instead of making things even worse. Stop this insanity from spreading, instead of making it spread more!
You are the one who seems to just want to add hack upon hack to things. THAT is what I really hate. It's not only in bad taste, it will come back and bite us some day.
Hell no! Why do you send me this shtit ? The "Use NMI instead of REBOOT_VECTOR" commit has been reported to not work AT ALL. It was totally broken... yet you send me this KNOWN BROKEN CRAP. And yes, I checked. The version you sent me is the fucked one. I was hoping that you would have fixed it up. But no. In short, you didn't merge the fix, and yet you sent me a patch series that was known to be broken for the last three+ weeks! ... Why? WHAT THE fuCK HAPPENED, INGO? Yes, I'm angry as hell. Shit like this should NOT happen.  I don't want people sending me known-buggy pull requests.
Mark, I pulled this, but I was this close to unpulling it because it's such an unholy mess. You seem to do the crazy "daily pull" crap that NOBODY IS EVER SUPPOSED TO DO. There are lots of totally pointless ... merge commits, and no, that's not ok.... Just don't do it. There's no excuse. The only time you should merge is when a sub lieutenant asks you to - and if you have people who work with you and ask you to do pointless merges almost every day, just tell them to shut the fuck up already!...But dammit, don't then do development on top of that kind of crap - use that branch only for linux-next, not for anything else, and don't ask me to pull that polluted piece of shit. ...But never ever have those stupid pointless "Merge remote-tracking branch 'regulator/for-linus' into regulator-next" in the branch you actually use for development, and the branch you send to me.
No it's not. Please fix your crappy script. First off, that '#' is wrong. It should be a space.
...You did two of the merges within hours of each other! ... That's just crazy. The fact that you then say that you have some kind of excuse for that craziness is just sad. Stop doing that. It's stupid. It just makes it harder for everybody to see what you are doing. ...Can't you see how crazy that is?
Stop being a moron. Go back and read the "nobody can work with you".
That statement is so nonsensical that I can't get past it. When you understand why it is nonsensical, you understand why the bit is cleared. Feel free to bring this up again without that idiotic statement as an argument.
So stop spouting garbage.
.. And how the fuck did you imagine that something like chrome would do that? You need massive amounts of privileges, and it's a total disaster in every single respect. Stop pushing crap. No, ptrace isn't wonderful, but your LSM+auditing idea is a billion times worse in all respects. ... THERE IS NO WAY IN HELL YOU CAN EVER FIX LSM+AUDIT TO BE USABLE! Stop bothering to even bring it up. It's dead, Jim.
And this is just insanity. The "barrier()" cannot possibly do anything sane. If it really makes a difference, there is again some serious problem with the whole fucking thing. NAK on the patch until sanity is restored. This is just total voodoo programming.
This still doesn't make sense. Why do that stupid allocation? Why not just move the entry? Why doesn't just the sane approach work? What the fuck does that pci_stop_bus_device() function do ...And if it does anything else, it should damn well stop doing that. The exact same loop is then apparently working for the virtual device case, so what the hell is going on that it wouldn't work for the physical one? What's the confusion? Why all the crazy idiotic code that makes no sense?
...which at least isn't butt ugly. ... Who is in charge of the whole 'is_virtfn' mess? How realistic is it to fix that crud?
Ugh. Ok, so that's a disgusting hack, but it's better than messing up the generic PCI subsystem. At least it's a disgusting hack in the IOV code.
I think this patch is horrible, and broken. And making the feature a config option is just stupid.
I hate this patch. Why? Because mindless checks like this would just lead to people making things worse and intermixing spaces there instead.
I never ever want to see this code ever again. Sorry, but last time was too fucking painful. 
Duh. That is just broken. ... That's just stupid. 
Ingo, stop with the stupid denialism. NOBODY likes that name. NOBODY. It's wrong. It's stupid. It sounds like a stronger "unlikely()", and it simply IS NOT. So rename it already. ...
There's two of those stupid merges that have no reason for existing, no explanation, and are just ugly. Don't do this, guys! ... Christ. I really don't like stupid unnecessary merges. ... The above is really just a fucking abomination, and says "somebody is doing something horribly wrong".
Congratulations, you seem to have found a whole new and unique way of screwing up ;) Linus "my mom called me 'special' too" Torvalds
Oh christ. This is exactly what the scheduler has ALWAYS ALREADY DONE FOR YOU. ... Stop doing it. You get zero advantages from just doing what the scheduler natively does for you, and the scheduler does it better.
Ugh. But my patch was crap. It fixed up "arg", but it should have fixed up "cmd". Stupid.
Stop right there. ... This is about your patch BREAKING EXISTING BINARIES. So stop the fu&^ing around already. The patch was shown to be broken, stop making excuses, and stop blathering. End of story. Binary compatibility is more important than any of your patches. If you continue to argue anything else or making excuses, I'm going to ask people to just ignore your patches entirely. Seriously. ... Dammit, I'm continually surprised by the idiots out there that don't understand that binary compatibility is one of the absolute top priorities. ... Breaking existing binaries ... is just about the worst offense any kernel developer can do. Because that shows that they don't understand what the whole point of the kernel was after all. We're not masturbating around with some research project.  We never were. Even when Linux was young, the whole and only point was to make a usable system. It's why it's not some crazy drug-induced microkernel or other random crazy thing. Really.
Christ. This one is too ugly to live. I'm not pulling crap like this. It's fu^&ing stupid to take a lock, calculate a bitqueue, and just generally be an absolute ass-hat about things for waiting for a bit that is already set 99.999% of the time.
Umm. I think your argument is totally braindead and wrong. My counter-argument is very simple: "So what?"
Sorry, you're wrong. And Rafael told you why you are wrong, and you ignored him and talked about "exec" some more. So go back and read Rafael's email. ... So please, read the emails. People actually agree that the name may be a bit misleading, but instead of harping on bogus issues, just read the emails from people like Rafael about it. So STOP with this idiocy already. ... Seriously. Get that through your head already.
So I have to say, I hate this entire series. ... So quite frankly, I think the whole series is total and utter garbage. And there isn't even any explanation" for the garbage. You say that you are unifying things, but dammit, in order to unify them you end up adding new fucking code. ... So a honking big NAK on this whole series unless you can explain with numbers and show with numbers what the advantage of the abortion is.
Ugh, this is disgusting.
Stop these idiotic games already! ... Your moronic "let's change the test to something else" is entirely and utterly misguided and totally misses the point. ... Stop the idiocy already. How hard is it to understand? How many times do people have to tell you? ... Rafael, please consider everything along these IDIOTIC lines completely NAK'ed. In fact, until Stephen starts showing any sign of understanding that it's not about just some random small detail, just ignore anything and everything from him. Stephen, you've been told multiple times that that WARN_ON() is correct. Until you understand that, just stop sending these entirely random patches that change it to something completely wrong. How hard can it be to understand that you cannot and must not load firmware when the system isn't up-and-running. And dammit, the fact that you send these kinds of completely nonsensical patches ... all you are showing is that you don't understand the problem. Stop, think, and read the emails that have been in this thread and that have explained how it could be solved. Until you do that, any patch you send is just worthless. Really.
Ugh. This is getting really ugly. ... because quite frankly, the whole spinunlock inlining logic is already unreadable, and you just made it worse.
... Why do I call it a total disaster? ... More importantly, they are both IDENTICALLY BAD. They are crap because: ... Doing a function call for these things is stupid. ...
... I will not be pulling this tree at all. It's pure and utter shit, and I wonder how long (forever?) this has been going on. ...the thing that makes me go "uhhuh, no way in hell should I pull this" is that you have apparently totally broken all sign-offs. Avi, you ABSOLUTELY MUST NOT rebase other peoples commits. That's a total no-no. And one thing I notice when I look through the commits is that you have totally broken the Signed-off-by: series in the process, exactly because what you do is crap, crap, CRAP. ... That's simply not true in your tree. Maybe because you have rebased other peoples (Alexander's) commits? I see commits where the sign-off ends with Alexander, but then the committer is you. WTF? Fix your fucking broken shit now. I'm not pulling crap like this. And it makes me unhappy to realize that this has probably happened a long time and I haven't even noticed. The whole "you MUST NOT rebase other peoples commits" is the thing I've been telling people for years now. Why the hell is it still going on?
Ugh: ... Can we please move that abortion into arch/powerpc/? Instead of making generic code even uglier..
Your original email used "torv...@osdl.org", which goes into a kind-of-black hole. Please fix whatever crazy-old address book you have - that address is old, old, old. Oh, and your new email had totally broken email headers too. WTF? That ... is just pure and utter garbage. What the hell is wrong with your email setup? When I reply to that email, I sure as hell want to reply to you, not to me. So fix your email, right now it's terminally broken. Will look at the pull requests now that I actually see them, and when I'm over being upset by your idiotic email issues.
Finally, people - your merge messages suck. Leaving the list of conflicting files without talking about what the conflict actually was is not a good merge message. Len, you're not the only one that does this, but it is yet another reason why I absolutely detest some of the merges I see: they are just very uninformative, and don't add anything useful to the tree - quite the reverse. They hide a problem, without actually talking about what the problem was. ...And yes, sometimes my merge messages suck too (although I've tried very hard to become better at them).
Grr. Most of these patches have the same stupid problem: why the hell do you repeat the single-line top-level description in both the Subject line and the body of the email? It only results in stupid duplicate lines in the commit logs. This is a disease. I don't know who the heck started doing it, but it's WRONG. It's stupid. What broken piece-of-shit tool is it that does this braindamage? Fix it. Stop sending these broken commit messages to people. I'm grumpy, yes, because this is a common problem. I see it all over the place, and it makes our commit logs look fucking retarded. ...
... Why has this been explicitly designed to be as ugly as humanly possible, and to be so inconvenient to parse too? ... So here's a serious suggestion: aim for "line oriented". ... ...That's stupid. Don't do it. ...Because this is just pure and utter shit: ...This part gets a big NAK from me. I don't see the point of this. It's pure crap. There's no advantage. And the "use an uint64_t" is a classic case of just being a fucking moron. ...This is the kind of thinking and code that just makes me go "No way, not today, not ever". It's stupid.
Oh, HELLNO! It's a fucking disaster in "Oh, one notifier was broken, SO LET'S ADD ANOTHER RANDOM ONE TO FIX THAT". The definition of insanity is doing the same thing over and over and thinking you get a different result. Let's not do that kind of idiotic thing. Notifiers are evil crap. Let's make fewer of them, not add yet-another-random-notifier-for-some-random-reason. fuck me, but how I hate those random notifiers. And I hate people who add them willy nilly.
...So stop complaining. Reverts really are just patches, Greg is 100% right, and you are simply wrong. ...and the fact that you continue to complain just makes you look stupid.
You're a fucking moron. ... So just reverting it from stable, WITHOUT LEARNING THE LESSON, is not a no-op at all, it's a sign of being a fucking moron. I'm stupider for just reading your email. Go away.
Stop the idiotic arguing already.
Please don't continue to spread this total bogosity. ...That's a total idiotic lie by C++ apologists, and I hate hearing it repeated over and over again. And it really is a lie. ... Which is clearly insane, but is also technically simply wrong. ... Which is utter and complete bullshit, and any amount of brains would have realized that ... It has always been just nothing but a moronic hang-up, and it has always been wrong. So don't spread that lie. It was wrong. ... which is pure and utter garbage. And then they lie, and claim that their weaker type system NULL is "stronger". Pure idiocy.
...And a C++ person who says that "(vodi )0" is just any "void " is a fuckingmoron, ...There is absolutely zero excuse for the idiotic traditional C++ brain damage of saying "NULL cannot be '(void )0', because 'void ' will warn". Anybody who says that is lying. ... The C++ people? They are morons, and they never got it, and in fact they spent much of their limited mental effort arguing against it. ... The whole "it's a stronger type system, so NULL has to be 0" is pure and utter garbage. It's wrong. It's stupid. ... Yeah, I'm not a fan of C++. It's a cruddy language.
They may be readable, but they are total shit. ... So no. Hell no.
And if you cannot understand what tens of people have tried to explain to you, you are just fucking stupid.
Ugh, I personally hate it. ... Your suggested format just sucks, and has the worst of all worlds.
...This is wrong. Or at least stupid.
Oh christ. What insane version of gcc is that? Can you please make a gcc bug-report? ... is just so fricking stupid that it's outright buggy. That's just crazy. It's demented. It's an "and" with all bits set.
...which is obviously completely bogus - it's even broken the constant. Your address simplification does something horribly bad. ... That's a totally worthless instruction. ... That ",1" is completely bogus, and I don't understand why the tools show that idiotic format to begin with. It's pure garbage. It adds zero information.... That "0x0" is more useless garbage in the same vein. ... Btw, don't get me wrong. I really like the changes. 
Oh christ, I also cannot be bothered to continue arguing with you since you seemingly randomly drop other people from the discussion. So don't expect any more replies from me.
Don't try to change the rules because you think you are "clever". You're only making things worse.
So? Even if we hadn't had this bug before (we have), your argument is utter crap. ...Stop arguing for crap.
I absolutely detest these types. I realize that we already have a few users, but just looking at these diffs hurts. It's disgusting.
Ok, this code is a rats nest. ... The code is crazy. It's an unreadable mess. Not surprising that it then also is buggy.... Looking at the code, I don't think it has been written by a human. ... Some of that code is clearly pure garbage. ... In fact, it's all crap. 
NAK NAK NAK. Ingo, please don't take any of these patches if they are starting to make NUMA scheduling be some arch-specific crap. Peter - you're way off base. You are totally and utterly wrong for several reasons: ...so making some arch-specific NUMA crap is idiotic. Your argument ...is pure crap. ... Christ, people. ...is just fucking moronic. ... Stop the idiocy. ...
Wrong. ... so you're just full of it. ... Checking the MCE data is stupid and wrong. Stop doing it, and stop making idiotic excuses for it. ...you are just doing moronic things. Stop doing stupid things.
Ugh. No. That is too disgusting for words.
NEITHER of your points actually address my issue. ... IOW, why the hell do you set a name that is so useful that no sane person would ever want to use it? ... So let me be more blunt and direct: which part of "that's fucking stupid" do you disagree with? So instead of making drivers do stupid things because you've made the input layer names so damn useless, why don't you make the input layer use better naming? Doesn't that seem to be the smart thing to do?
I'll let you think about just how stupid that comment was for a moment.
Ugh, looking more at the patch, I'm getting more and more convinces that it is pure and utter garbage. ... WTF? ... This is crap, guys. Seriously. Stop playing russian rulette with this code.
No, that's just crazy. Now you make broken shit code work, and then you break the correct code... Just face it: if somebody doesn't have an interrupt-time function pointer, they need to rethink their code. It's a mistake. It's broken shit. Why pander to crap? 
This is too damn ugly. These kinds of "conditionally take lock" things are always just bugs waiting to happen. Don't do it. ... These kinds of "bool lock" crap things have to die. They are wrong. They are a sign of bad locking rules.
Umm. That just smells like BS to me. ... Also, your protection claim seems to be invalidated by the actual code. ... So your claim that it hedges around it by looking at the inquiry data is pure crap. It's simply not true. ... So no, I simply don't see the careful testing or the checking that you claim exists.
This is horrible, I think. NAK NAK NAK. ... So don't do this. It's stupid. ... I absolutely detest patches like this that make practical security worse, in the name of some idiotic theoretical worry that nobody has any reason to believe is real.
Kay, this needs to be fixed. ... Of course, I'd also suggest that whoever was the genius who thought it was a good idea to read things ONE fuCKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the fuck does idiotic things like that? How did they noty die as babies, considering that they were likely too stupid to find a tit to suck on?
sizeof without parenthesis is an abomination, and should never be used. ... The sane solution is: just add the fucking parenthesis, and don't use the parsing oddity. ... And talking about "prefix operators" is a moronic thing to do. ... Think of it as a function, and get over your idiotic pissing match over how long you've both known C. That's irrelevant. ...
Absolutely. Anybody who does that is just terminally confused. "return()" is in no way a function. ... Here's an example of a really bad use of "sizeof" that doesn't have the parenthesis around the argument: sizeof(p)->member. Quite frankly, if you do this, you should be shot. ... And let's face it: if you write your code so that it's easy to parse for a machine, and ignore how easy it is to parse for a human, I don't want you writing kernel code. ...
... However, please don't use the INSANE ARM "v8" naming. There must be something in the water in Cambridge, but the ARM "version" naming is just totally broken. ...maybe it all makes sense if you have drunk the ARM cool-aid and have joined the ARM cult, but to sane people and outsiders, it is just a fucking mess. So - aarch64 is just another druggie name that the ARM people came up with after drinking too much of the spiked water in cambridge. ... - armv8 is totally idiotic and incomprehensible to anybody else...complete and utter nonsense. It's only confusing. Christ. Seriously. The insanity is so strong in the ARM version names that it burns. If it really makes sense to anybody ... you need to have your head examined. So please don't use "aarch64", because it's just fucking crazy. And please don't use "armv8", because it's just completely retarded and confused.
Guys, stop it now. Your "problem" isn't what any sane person cares about, and isn't what I started the RFC for. Seriously. NOBODY CARES. ... Stop whining.
Seriously. People who use BUG() statements like some kind of assert() are a menace to society. They kill machines.
And the commit seems to be pure shit. Why is it pure shit? Look at what users are left. THERE ARE NO USERS THAT SET THAT FIELD ANY MORE! ... I've pulled the changes for now, but I absolutely detest seeing things like this. ...
Stop this "we can break stuff" crap. Who maintains udev? Regressions are not acceptable. I'm not going to change the kernel because udev broke, fuck it. Seriously. More projects need to realize that regressions are totally and utterly unacceptable. ... That just encourages those package maintainers to be shit maintainers. ... And stop blaming the kernel for user space breakage!...
This patch is insane. This is pure garbage. Anybody who thinks this: ... is a good idea should be shot. Don't do it. ...That's just fucking insane. Stop this kind of idiocy. The code looks bad, and the logic is pure shit too.
... And it really is all stupidly and badly done. I bet we can make that code faster without really changing the  end result at all, just changing the algorithm. ... In fact, looking at select_idle_sibling(), I just want to puke. The thing is crazy. ... instead it does totally fucking insane things ... The code is shit. Just fix the shit, instead of trying to come up with some totally different model. Ok? ...
... I don't understand why this seems to be so hard for people to understand. ...this whole thread is a wonderful example of how fuCKING STUPID it was to even consider it. ... SO STOP DOING ABI CHANGES. WE DON'T DO THEM. ...but anybody who does it on purpose "just because" should not be involved in kernel development (or library development for that matter).
Stop this idiocy. ... The fact that you then continually try to make this a "kernel issue" is just disgusting. Talking about the kernel solving it "properly" is pretty dishonest, when the kernel wasn't the problem in the first place. 
I also call bullshit on your "it will surely be fixed when we know what's the right fix" excuses. The fact is, you've spent the last several months blaming everybody but yourself, and actively told people to stop blaming you: ... despite having clearly seen the patch (you replied to it, for chissake, and I even told you in that same thread why that reply was wrong at the time). ... Kay, you are so full of shit that it's not funny. You're refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around your bugs, and say that we should have done so from the very beginning. Yes, doing it in the kernel is "more robust". But don't play games, and stop the lying.
David, I want to make it very clear that if you ever suggest another big include file cleanup, I will say "fuck no" and block you from my emails forever. Ok? So don't bother. We're done with these kinds of games. Forever. It's not worth it, don't ever suggest it again for some other "cleanup".
That's just disgusting crazy talk. Christ, David, get a grip on yourself. ...
Stop doing this fucking crazy ad-hoc "I have some other name available" #defines. Use the same name, for chissake! Don't make up new random names. Just do ... to define the generic thing. Instead of having this INSANE "two different names for the same fucking thing" crap. Stop it. Really. ...So NAK on this whole patch. It's bad. It's ugly, it's wrong, and it's actively buggy.
Did anybody ever actually look at this shit-for-brains patch? Yeah, I'm grumpy. But I'm wasting time looking at patches that have new code in them that is stupid and retarded. This is the VM, guys, we don't add stupid and retarded code. LOOK at the code, for chrissake. Just look at it. And if you don't see why the above is stupid and retarded, you damn well shouldn't be touching VM code.
Rik, LOOK at the code like I asked you to, instead of making excuses for it. I'm not necessarily arguing with what the code tries to do. I'm arguing with the fact that the code is pure and utter garbage. It has two major (and I mean MAJOR) problems, both of which individually should make you ashamed for ever posting that piece of shit: The obvious-without-even-understanding-semantics problem: - it's humongously stupidly written. It calculates that 'flush_remote' flag WHETHER IT GETS USED OR NOT. Christ. I can kind of expect stuff like that in driver code etc, but in VM routines? Yes, the compiler may be smart enough to actually fix up the idiocy. That doesn't make it less stupid. The more-subtle-but-fundamental-problem: - regardless of how stupidly written it is on a very superficial level, it's even more stupid in a much more fundamental way. ... In other words, everything that was added by that patch is PURE AND UTTER SHIT. And THAT is what I'm objecting to. ... Because everything I see about "flush_remote" looks just wrong, wrong, wrong. And if there really is some reason for that whole flush_remote braindamage, then we have much bigger problems ... So that patch should be burned, and possibly used as an example of horribly crappy code for later generations. At no point should it be applied.
But dammit, every single discussion I see, you use some other argument for it, like "people don't have initrd" or whatever crazy crap. That's what I was objecting to.
Kees, you don't seem to understand. Breaking applications is unacceptable. End of story. It's broken them. Get over it. ... Your "IT HAS TO BE DONE AT BOOT TIME, THE SKY IS FALLING, NOTHING ELSE IS ACCEPTABLE!" ranting is a disease. Stop it.
We've been here before, haven't we? There's so much wrong with this that it's not funny. ... And I know you can do them, because you've done them in the past. So please don't continue to do the above.
What part of "We don't break user space" do you have trouble understanding? ... End of discussion. I don't understand why people have such a hard time understanding such a simple concept. ... Seriously, IT IS THAT SIMPLE.
PLEASE NO! Dammit, why is this disease still so prevalent, and why do people continue to do this crap? __HAVE_ARCH_xyzzy is a fucking retarded thing to do, and that's actually an insult to retarded people. ... The ... thing is a disease. ...
Ingo, stop doing this kind of crap. ... You seem to be in total denial. ... Stop it. That kind of "head-in-the-sand" behavior is not conducive to good code, ... Seriously. If you can't make the non-THP case go faster, don't even bother sending out the patches. Similarly, if you cannot take performance results from others, don't even bother sending out the patches. ... So stop ignoring the feedback, and stop shooting the messenger. Look at the numbers, and admit that there is something that needs to be fixed.
Ingo, stop it already! This is exactly the kind of "blame everybody else than yourself" behavior that I was talking about earlier. ... Ingo, look your code in the mirror some day, and ask yourself: why do you think this fixes a "regression"? ...So by trying to make up for vsyscalls only in your numbers, you are basically trying to lie about regressions, and try to cover up the schednuma regression by fixing something else. ... See? That's bogus. When you now compare numbers, YOU ARE LYING. You have introduced a performance regression, and then trying to hide it by making something else go faster. ...The same is true of all your arguments about Mel's numbers wrt THP etc. Your arguments are misleading - either intentionally, of because you yourself didn't think things through. ...
... Christ. That code is a mess. ...
The games with "max_block" are hilarious. In a really sad way. That whole blkdev_get_blocks() function is pure and utter shit.
What a crock. That direct-IO code is hack-upon-hack. Whoever wrote it should be shot. ...
No. That patch is braindead. I wouldn't pull it even if it wasn't this late. ... What the fuck is the point? ... What am I missing?
Christ guys. This whole thread is retarded. The ONLY reason people seem to have for reverting that is a "ooh, my feelings are hurt by how this was done, and now I'm a pissy bitch and I want to get this reverted". Stop the fucking around already. ... And if your little feelings got hurt, get your mommy to tuck you in, don't email me about it. Because I'm not exactly known for my deep emotional understanding and supportive personality, am I?
Ugh. This patch makes my eyes bleed. ... So I guess this patch fixes things, but it does make me go "That's really really ugly".
Christ, I promised myself to not respond any more to this thread, but the insanity just continues, from people who damn well should know better. ... So stop these dishonest and disingenious arguments. They are full of crap. ... Every single argument I've heard of from the "please revert" camp has been inane. And they've been transparently inane, to the point where I don't understand how you can make them with a straght face and not be ashamed. ... Bullshit.... Anybody who claims that our "process" requires that things like that go on the mailing list and pass long reviews and discussions IS JUST LYING. ... Read the above arguments, and realise how shrill and outright STUPID that kind of "we can now do anything without review" argument is. ... You seem to seriously argue that it's a bad thing to put a note that one bit is already in use. That's fucking moronic.... But that's not what the insane and pointless arguments in this thread have been. The whole thread has been just choch-full of pure STUPID. Please stop the inane and idiotic arguments already. The "we must review every one-liner, and this destroys and makes a mockery of our review process" argument in particular has been dishonest and pure crap....
The reading comprehension here is abysmal. ...And none of that matters for my argument AT ALL.
So please, just remove that idiotic "if (!event->attr.exclude_guest)" test. It's wrong. It cannot possibly do the right thing.  It is totally misdesigned, exactly because you don't even know beforehand if somebody uses virtualization or not.
Christ, why can't people learn?
Ugh. This patch is just too ugly. Conditional locking like this is just too disgusting for words. ... I'm not applying disgusting hacks like this. ... No "if (write) up_write() else up_read()" crap. 
Grr. This is still bullshit. Doing this: ... is fundamentally crap ... So doing any of these calculations in bytes is pure and utter crap. ... Anything that works in bytes is simply pure crap. And don't talk to me about 64-bit math and doing it in "u64" or "loff_t", that's just utterly moronic too. ... So the math is confused, the types are confused, and the naming is confused. Please, somebody check this out, because now I am confused. And btw, that whole commit happened too fucking late too. ... I'm grumpy, because all of this code is UTTER SHIT, and it was sent to me. Why?
Christ, Mel. Your reasons in b22d127a39dd are weak as hell, and then you come up with THIS shit instead: ... Heck no. In fact, not a fucking way in hell. Look yourself in the mirror, Mel. This patch is ugly, and guaranteed to result in subtle locking issues, and then you have the gall to quote the "uhh, that's a bit ugly due to some trivial duplication" thing in commit...  compared to the diseased abortion you just posted...
Mauro, SHUT THE FUCK UP! It's a bug alright - in the kernel. How long have you been a maintainer? And you still haven't learnt the first rule of kernel maintenance? ... Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious garbage and idiocy from a kernel maintainer again. Seriously. ...The fact that you then try to make excuses for breaking user space, and blaming some external program that used to work, is just shameful. It's not how we work. Fix your fucking "compliance tool", because it is obviously broken. And fix your approach to kernel programming
Yes, I'm upset. Very upset. ... So your question "why would pulseaudio care" is totally irrelevant, senseless, and has nothing to do with anything.1/2/2013 10:14:00
Christ people. I already reported that it DOES NOT EVEN COMPILE. ... Alan apparently doesn't care about the patch he wrote to even bother fixing that, and the only person who does seem to care enough to carry two fixes around (Andrew) apparently doesn't feel that he's comfortable forwarding it to me ... I'm not picking up random patches from people who don't care enough about those patches to even bother fixing compile errors when reportyed and didn't even send them to me to begin with.
Bullshit. That expectation is just a fact. ... We do not say "user mode shouldn't". Seriously. EVER. User mode does, and we deal with it. Learn it now, and stop ever saying that again. This is really starting to annoy me. Kernel developers who say "user mode should be fixes to not do that" should go somewhere else. 
No way. ... In fact, just to prove how bad it is, YOU SCREWED IT UP YOURSELF. ... But the "hacky workaround" absolutely needs to be automatic. Because the "driver writers need to get this subtle untestable thing right" is not acceptable. That's the patch that Ming Lei did, and I refuse to have that kind of fragile crap in the kernel.
No. You guys need to realize that I'm not talking crap like this this late. This is not major bugfixes. I already looked away once just because it's a new filesystem, but enough is enough. This is way way WAY too late to start sendign "enhancements". Seriously.
No. Your pull requests are just illogical. I have yet to see a single reason why it should be merged. ... That's total bullshit. ... Again, total bullshit. ... ... Ingo, it's not us being silly, it is you. ... So here, let me state it very very clearly: I will not be merging kvmtool. ... In other words, I don't see any advantage to merging kvmtool. I think merging it would be an active mistake, and would just tie two projects together that just shouldn't be tied together. So nobody is "hurting useful code", except perhaps you. Explain to me why I'm wrong. I don't think you can. You certainly haven't so far.
NONE of your statements made any sense at all, since everything you talk about could have been done with a separate project. The only thing the lock-step does is to generate the kind of dependency that I ABSOLUTELY DETEST,
You do realize that none of your arguments touched the "why should Linus merge the tree" question at all? Everything you said was about how it's more convenient for you and Ingo, not at all about why it should be better for anybody else. ... You're the only one working on it, so being convenient for you is the primary issue. Arguments like that actively make me not want to merge it, ...
Why? You've made this statement over and over and over again, and I've dismissed it over and over and over again because I simply don't think it's true. It's simply a statement with nothing to back it up. Why repeat it? THAT is my main contention. I told you why I think it's actually actively untrue. ... So you make these unsubstantiated claims about how much easier it is, and they make no sense. You never explain why it's so magically easier. ... Anyway, I'm done arguing. You can do what you want, but just stop misrepresenting it as being "linux-next" material unless you are willing to actually explain why it should be so.
Ingo, stop this idiotic nonsense. You seem to think that "kvmtool is useful for kernel" is somehow relevant. IT IS TOTALLY IRRELEVANT.
Christ. This is so ugly that it's almost a work of art.
Did anybody actually look at the code generation of this? Adding an external function call is horrible, ... Guys, the biggest cost of a function call is not the "call" instruction, it's all the crap around it ... And the excuse is "so that we can add stuff to the wait loop". What the fuck? ... and which is something we have actively avoided in the past, because back-off is a fucking idiotic thing, and the only real fix for contended spinlocks is to try to avoid the contention and fix the caller to do something smarter to begin with. In other words, the whole fucking thing looks incredibly broken. At least give some good explanations for why crap like this is needed ...
So you're potentially making things worse for just about everybody, in order to fix a problem that almost nobody can actually see. And apparently you don't even know the problem.. and as I already explained, THAT IS PURE AND UTTER BULLSHIT. It may make things WORSE. On all the things you haven't run to check that it does better. You just stated something that is not at all necessarily true. .... That's pure bullshit. ... And yet you go on to say that it will fix performance problems THAT WE DON'T EVEN KNOW ABOUT! After seeing proofu to the exact contrary behavior! What fucking planet are you from, again? Christ, that's hubris. ...
Christ, we should just try to get rid of the personality bits entirely, they are completely insane
Quite frankly, this is fucking moronic.
Guys, this is not a dick-sucking contest. ... If Red Hat wants to deep-throat Microsoft, that's your issue.
Quite frankly, I doubt that anybody will ever care, ... Plus quite frankly, signing random kernel vendor modules (indirectly) with a MS key is fucking stupid to begin with. In other words, I really don't see why we should bend over backwards, when there really is no reason to. It's adding stupid code to the kernel only to encourage stupidities in other people. ... And the whole "no, we only think it makes sense to trust MS keys" argument is so fucking stupid that if somebody really brings that up, I can only throw my hands up and say "whatever". In other words, none of this makes me think that we should do stupid things just to perpetuate the stupidity. 
Ugh. The placement of that #ifndef is just horrible, please don't do that.
Your arguments only make sense if you accept those insane assumptions to begin with. And I don't.
The softirq semantics are perfectly fine. Don't blame softirq for the fact that irq_exit() has had shit-for-brains for a long time. ... Don't blame the wrong code here.
Rafael, please don't ever write that crap again. ... Seriously. Why do I even have to mention this? Why do I have to explain this to somebody pretty much every fucking merge window? This is not a new rule. ... So you should be well acquainted with the rule, and I'm surprised to hear that kind of utter garbage from you in particular. ...
And you're happy shilling for a broken model? ... Your arguments constantly seem to miss that rather big point. You think this is about bending over when MS whispers sweet nothings in your ear.. ... You, on the other hand, seem to have drunk the cool-aid on the whole "let's control the user" crap. Did you forget what security was all about?
How fucking hard is it for you to understand? Stop arguing about what MS wants. We do not care. We care bout the user. You are continually missing the whole point of security, and then you make some idiotic arguments about what MS wants you to do. It's irrelevant. The only thing that matters is what our users want us to do, and protecting their rights. As long as you seem to treat this as some kind of "let's please MS, not our users" issue, all your arguments are going to be crap.
... Stop the fear mongering already. So here's what I would suggest, and it is based on REAL SECURITY and on PUTTING THE USER FIRST instead of your continual "let's please microsoft by doing idiotic crap" approach. ... Quite frankly, you are what he key-hating crazies were afraid of. You peddle the "control, not security" crap-ware. The whole "MS owns your machine" is exactly the wrong way to use keys.
This is the kind of totally bogus crap that no sane person should ever spout. Stop it.
I would love to blame gcc, but no, I think the code is crap. ... And gcc would be completely correct. That test is moronic.
Has Chris Ball been told what an incredible pain this kind of crap is, and that there's a damn good reason why WE DO NOT REBASE PUBLIC TREES THAT OTHERS MAY BE BASING THEIR DEVELOPMENT ON! Chris, can you hear me shouting? Don't do that.
Yeah, that would be a no. I finally got to look at the new architectures and be ready to pull them, and you just made sure I won't pull this. This is exactly the kind of crap I don't want to see in any pull requests, ... Why the fuck are you doing back-merges? There is no excuse for even a single one. And here you have just about one back-merge per commit. No, no no.
No, guys. That cannot work. It's a completely moronic idea. 
Yeah, I'm a fucking moron.
Bullshit. This is a regression, and it needs to be fixed. The "device needs power" crap is just that - crap. Nobody cares. ... Claiming that we need to know the power regulator for an accelerometer is total utter idiocy and crap. ... The notion that you have to have regulator information in order to use some random device is insanity. I don't understand how you can even start to make excuses like that. It's so obviously bogus that it's not even funny. Why do I have to explain the "no regressions" to long-time kernel maintainers EVERY SINGLE RELEASE? What the fuck is wrong with you people? Seriously?
No it's not. ... which is entirely and utterly pointless. Christ, the amount of confusion in that tree.  ... Don't do this kind of thing. That branch is pointless, and just confused you.
Because you screwed up that pull request, and I argue that you screwed up exactly because it's ambiguous and confusing.
This is all COMPLETELY wrong. ... Fix ARC, don't try to blame generic code. You should have asked yourself why only ARC saw this bug, when the code apparently works fine for everybody else!
That's absolutely insane. It's insane for two reasons: - it's not SUFFICIENT. ... - it's POINTLESS and WRONG. ...
I'm a moron.
Bullshit. That's exactly the wrong kind of thinking. ... This whole discussion has been fucking moronic. The "security" arguments have been utter shite with clearly no thinking behind it, the feature is total crap ... and I'm seriously considering just getting rid of this idiotic dmesg_restrict thing entirely. Your comment is the very epitome of bad security thinking.
Why does this have the crappy cputime scaling overflow code, ... WTF happened here? I and others spent efforts so that we wouldn't need this kind of crap.
Ugh. Sorry, but this patch just looks stupid.
fuck yes it does. It means that NOBODY EVEN TEST-COMPILED THE TREE THAT GOT SENT TO ME. WTF? If that's not "irresponsible and lame", I don't know what the hell is.
And you are making that excuse exactly why? ... Stop making excuses for bad behavior. Just admit that you guys screwed up rather than trying to soldier on. ... That's a fucking disgrace. ... Stop making excuses for it. Really. It just makes you look even worse. ...
This has so much wrong that I don't know where to start.
Not pulled, because your hamster smells of eldeberries. This is not just bugfixes. In fact, as far as I can tell, this introduces bugs, ... I'm fucking tired of people having problems understanding "we're past rc5". If it's not something you would call stable material, you shouldn't send it to me.
That patch is really ugly. And it doesn't make much sense. ... So the patch seems to make things just worse.
What the fuCK is wrong with people?
David, what the heck are you doing? ... Seriously. Those commits now have TOTALLY MISLEADING summary messages. ...
THIS IS SOME HORRIBLY BROKEN CRAP. ... Dammit, this has happened before, and it was broken then, and it is broken now. If they do, they are fuCKINGBROKEN. ... You need to start being more careful. ... There is no excuse for this. That commit is shit. ... And that totally crap commit is even marked for stable. I hate hate hate when this kind of crap happens. 
Grr. I hate it when people do this. Your merge message sucks.
That's fucking sad. You know why it's sad? ... Now, that should make you think about THE ABSOLUTE CRAP YOU MARK FOR -stable! ... Listen to yourself. In fact, there is a damn good solution": don't mark crap for stable, and don't send crap to me after -rc4. ... Greg, the reason you get a lot of stable patches seems to be that you make it easy to act as a door-mat. ... You may need to learn to shout at people.
What the fuCK, guys? This piece-of-shit commit is marked for stable, but you clearly never even test-compiled it, did you? ...The declaration for gate_desc is very very different for 32-bit and 64-bit x86 for whatever braindamaged reasons. Seriously, WTF? I made the mistake of doing multiple merges back-to-back with the intention of not doing a full allmodconfig build in between them, and now I have to undo them all because this pull request was full of unbelievable shit. And why the hell was this marked for stable even Ifu it hadn't been complete and utter tripe? It even has a comment in the commit message about how this probably doesn't matter. So it's doubly crap: it's wrong, and it didn't actually fix anything to begin with. There aren't enough swear-words in the English language, so now I'll have to call you perkeleen vittupää just to express my disgust and frustration with this crap.
Ok. So your commit message and explanation was pure and utter tripe,
Ugh. I dislike this RCU'ism. It's bad code. It doesn't just look ugly and complex, it's also not even clever. It is possible that the compiler can fix up this horrible stuff and turn it into the nice clever stuff, but I dunno.
Please don't do these ugly and pointless preprocessor macro expanders that hide what the actual operation is. And this is really ugly. Again it's also then hidden behind the ugly macro. ...
Yes it damn well is. Stop the fucking stupid arguments, and instead listen to what I say. Here. Let me bold-face the most important part for you, so that you don't miss it in all the other crap: ... Nothing else. Seriously. Your "you can't do it because we copy backwards" arguments are pure and utter garbage, ... You're complicating the whole thing for no good reason. ...
We should definitely drop it. The feature is an abomination. I thought gcc only allowed them at the end of structs, in the middle of a struct it's just fucking insane beyond belief.
What drugs are you on? Your example is moronic, and against all _documented_ uses of chroot.
I can't even begin to say whether this is a good solution or not, because that if-conditional makes me want to go out and kill some homeless people to let my aggressions out. Can we please agree to never write code like this? Ever?
The whole "it's more convenient to use sleeping locks" argument is PURE AND UTTER SHIT when it comes to really core code. ... Seriously. Your argument is bad, but more importantly, it is dangerously bad. It's crap that results in bad code: and the bad code is almost impossible to fix up later...
So get your act together, and push back on the people you are supposed to manage. Because this is not acceptable for post-rc5, and I'm giving this single warning. Next time, I'll just ignore the shit you send me. Comprende?
Not acceptable. ... Plase stop sending me untested crap that doesn't even compile cleanly!
Stop this idiotic "blame gcc bug" crap. Which part of my explanation for why it was NOT a compiler bug did you not understand? ... Stop the fucking around already! The  whole "we expect ww_ctx to be null" thing shows that YOU DO NOT SEEM TO UNDERSTAND WHAT THE TEST ACTUALLY IS! ... Christ, can you really not understand that? NO NO NO NO. No a fucking thousand times. It's not "too broken in gcc". It's too broken in the source code, and the fact that you don't even understand that is sad. You wrote the code, and you seem to be unable to admit that your code was buggy. It's not a compiler bug. It's your bug. Stand up like a man, instead of trying to flail around and blame anything else but yourself. So guys, get your act together, and stop blaming the compiler already.
This looks totally invalid....Your patch is horribly wrong.
You need to also explain why people should apply it, and stop the fucking idiotic arguing every time somebody comments about your patches.Stop this idiotic "blame gcc bug" crap. Which part of my explanation for why it was NOT a compiler bug did you not understand? ... Stop the fucking around already! The  whole "we expect ww_ctx to be null" thing shows that YOU DO NOT SEEM TO UNDERSTAND WHAT THE TEST ACTUALLY IS! ... Christ, can you really not understand that? NO NO NO NO. No a fucking thousand times. It's not "too broken in gcc". It's too broken in the source code, and the fact that you don't even understand that is sad. You wrote the code, and you seem to be unable to admit that your code was buggy. It's not a compiler bug. It's your bug. Stand up like a man, instead of trying to flail around and blame anything else but yourself. So guys, get your act together, and stop blaming the compiler already.
My point is that I have sixteen pointless messages in my mbox, half of which are due to just your argumentative nature.
This seems to be just pure stupid. ...Even the help message is pure and utter garbage ... Asking the user questions that make no fucking sense to ask is stupid. And I'm not knowingly pulling stupid crap.
Why? You're wrong. I mean, anybody who disagrees with me is pretty much wrong just on pure principles, but I actually mean a deeper kind of wrong than that. I mean a very objective "you're clearly wrong". ... .. and then you use a totally bogus example to try to "prove" your point. ... Your example is pure and utter shit, since you still get confused about what is actually const and what isn't. ... But that argument is BULLSHIT, because the fact is, the function doesn't do what you try to claim it does.
I think that code is bad, and you should feel bad.
Grr. I've pulled it, but looking at that history, it's just pure and utter fucking garbage.
No it's not. Thomas, stop this crap already. Look at the fucking code carefully instead of just dismissing cases. ... So, Christ, Thomas, you have now twice dismissed a real concern with totally bogus "that can never happen" by explaining some totally unrelated simple case rather than the much more complex case. So please. Really. Truly look at the code and thing about it, or shut the fuck up. No more of this shit where you glance at the code, find some simple case, and say "that can't happen", and dismiss the bug-report.
Ok, I'm sorry, but that's just pure bullshit then. ... This code is pure and utter garbage. It's beyond the pale how crazy it is.
No. I think it makes sense to put a big warning on any users you find, and fart in the general direction of any developer who did that broken pattern. Because code like that is obviously crap.
This looks completely broken to me. ... Wtf? Am I missing something?
Yeah, it's a hack, and it's wrong, and we should figure out how to do it right.
Yes, yes, it may "work", but I'm not pulling that kind of hack just before a release....But dammit, using this kind of hackery, ... is just not acceptable.
The fact that it doesn't even compile makes me doubt your statement that it has been in linux-next. ... I fixed it up properly in the merge, but please try to figure out how the hell this passed through the cracks.
You messed up the pull request too.. The branch name is missing from that git line, even if you did mention it a few lines earlier...
Adding Andrea to the Cc, because he's the author of that horridness. Putting Steven's test-case here as an attachement for Andrea, maybe that makes him go "Ahh, yes, silly case". Also added Kirill, because he was involved the last _PAGE_NUMA debacle.
It's misleading crap. Really. Just do a quick grep for that bit, and you see just how confused people are about it:...think about it. Just THINK about how broken that code is. The whole thing is a disaster. _PAGE_NUMA must die. It's shit.
This was obviously brought on by my frustration with the currently nasty do_notify_resume() always returning to iret for the task_work case, and PeterZ's patch that fixed that, but made the asm mess even worse.
But dammit, if you build with debug_info and then strip the end result, you're just insane. You made your build take ten times longer, use ten times more diskspace, and then you throw it all away. Crazy.
If most of the oopses you decode are on your own machine with your own kernel, you might want to try to learn to be more careful when writing code. And I'm not even kidding.
Dammit, this is pure shit, and after having to deal with yet another pointless merge conflict due to stupid "cleanups" in Makefiles, IT DOES NOT EVEN COMPILE. And no, that's not due to a merge error of mine. It was that way in your tree. Hulk angry. Hulk smash. I fixed it up in the merge, but I shouldn't need to. This should have been caught in -next, and even if you compile for ARM as your primary target, I know damn well that no sane ARM developer actually compiles on ARM (because there are no machines where it's worth the pain), so you should make sure that the x86-64 build works too. If I can find compile errors within a couple of minutes of pulling and it's not a merge error of mine, the tree I'm pulling from is clearly crap. So I'm more than a bit grumpy. Get your act together, and don't send me any more shit. In fact, I would suggest you send nothing but obvious fixes from now on in this release. Because I won't be taking anything else.
I don't think that works. That completely breaks randomize_stack_top(). So I'm not going to pull the parisc tree, this needs to be resolved sanely. In fact, I think that change to fs/exec.c is just completely broken:... and that "+1" just doesn't make sense, and fundamentally breaks STACK_RND_MASK. It also seems to be entirely pointless, ...So NAK on that whole fs/exec.c change. Afaik it's just wrong, and it's stupid.
Oh, please, that's a British-level understatement. It's like calling WWII "a small bother". That's too ugly to live.
And that audit code really is aushit. I think I found a bug in it while just scanning it:
Grr. You missed the branch name. I can see from the SHA1 (and historical pull requests) that you meant the usual 'v4l_for_linus' branch, but please be more careful.
I absolutely detest this patch....because the particular use in question is pure and utter garbage.... And btw, that horrid crap called "kmap_to_page()" needs to die too. When is it ever valid to use a kmap'ed page for IO? Here's a clue: never. I notice that we have a similar abortion in "get_kernel_page[s]()", which probably has the same broken source. We need to get rid of this crap, rather than add more of it. ... So who the fuck sends static module data as IO? Just stop doing that. What's And that idiotic kmap_to_page() really needs to die too. Those disgusting get_kernel_page[s]() functions ... Mel, Rik, this needs to die. I'm sorry I didn't notice how crap it was earlier. ...Please let's just fix the real problem, don't add more horridness on top...
What BS is that? If you use an "atomic_store_explicit()", by definition you're either (a) fucking insane (b) not doing sequential non-synchronizing code ... and a compiler that assumes that the programmer is insane may actually be correct more often than not, but it's still a shit compiler. Agreed? So I don't see how any sane person can say that speculative writes are ok. They are clearly not ok. Speculative stores are a bad idea in general. They are completely invalid for anything that says "atomic". This is not even worth discussing.
If you really think that, I hope to God that you have nothing to do with the C standard or any actual compiler I ever use. Because such a standard or compiler would be shit. It's sadly not too uncommon
Is this whole thread still just for the crazy and pointless "max_sane_readahead()"? Or is there some real reason we should care? Because if it really is just for max_sane_readahead(), then for the love of God, let us just do this ... and bury this whole idiotic thread.
Quite frankly, I think it's stupid, and the "documentation" is not a benefit, it's just wrong.... I don't understand why you even argue this. Seriously, Paul, you seem to want to think that "broken shit" is acceptable, and that we should then add magic markers to say "now you need to not be broken shit".... Seriously, this whole discussion has been completely moronic. I don't understand why you even bring shit like this up... I mean, really? Anybody who writes code like that, or any compiler where that "control_dependency()" marker makes any difference what-so-ever for code generation should just be retroactively aborted. ... Seriously. This thread has devolved into some kind of "just what kind of idiotic compiler cesspool crap could we accept". Get away from that fucking mindset. We don't accept any crap. Why are we still discussing this idiocy? It's irrelevant. ...
No, please don't use this idiotic example. It is wrong....Anybody who argues anything else is wrong, or confused, or confusing.
Please, Debabrata, humor me, and just try the patch. And try reading the source code. Because your statement is BS.
...it's a pointless and wrong example....So your argument is shit. Why do you continue to argue it?...It's really not that complicated....Really, why is so hard to understand?
This is why I don't like it when I see Torvald talk about "proving" things. It's bullshit.
But your (and the current C standards) attempt to define this with some kind of syntactic dependency carrying chain will _inevitably_ get this wrong, and/or be too horribly complex to actually be useful. Seriously, don't do it. ... So just give it up. It's a fundamentally broken model. It's wrong, but even more importantly, it's not even useful, ...I really really really think you need to do this at a higher conceptual level, get away from all these idiotic "these operations maintain the chain" crap. 
But that's BS. You didn't actually listen to the main issue. Paul, why do you insist on this carries-a-dependency crap? It's broken. ... The "carries a dependency" model is broken. Get over it.... I gave an alternate model (the "restrict"), and you didn't seem to understand the really fundamental difference. ... So please stop arguing against that. Whenever you argue against that simple fact, you are arguing against sane compilers....
Whee. Third time is the charm. I didn't know my email address was that hard to type in correctly.Usually it's the "torvalds" that trips people up, but you had some issues with "foundation", didn't you ;)
Oww, oww, oww. DAMMIT. ...So I'm pissed off. This patch was clearly never tested anywhere. Why was it sent to me?...Grr. Consider yourself cursed at. Saatana.
That's a technical issue, Stefani. ... And when Fengguang's automatic bug tester found the problem, YOU STARTED ARGUING WITH HIM.  Christ, well excuuse me for being fed up with this pointless discussion.
Ugh. This is way late in the release, and the patch makes me go: "This is completely insane", which doesn't really help...This is just pure bullshit....So the above locking change is at least terminally stupid, and at most a sign of something much much worse.... there is no way in hell I will apply this obviously crap patch this late in the game. Because this patch is just inexcusable crap, and it should not have been sent to me in this state. ...
Ugh. I pulled it, but things like this makes me want to dig my eyes out with a spoon:...
So I think that adding "visible" to asmlinkage is actively wrong and misguided. And the compiler even told you so, but somebody then chose to ignore the compiler telling them that they did stupid things. Don't do crap like this.
Ugh. I absolutely detest this patch. If we're going to leave the TLB dirty, then dammit, leave it dirty. Don't play some half-way games....
Why? This change looks completely and utterly bogus.... Guys, this is crap. ...  That's utter bullshit, guys. ...Exposing it at all is a disgrace. making it "default y" is doubly so. ... I'm not pulling crap like this. Get your act together. Why the heck should _I_ be the one that notices that this commit is insane and stupid? Yes, this is a pet peeve of mine. ... This cavalier attitude about asking people idiotic questions MUST STOP. Seriously. This is not some "small harmless bug". This mindset of crazy questions is a major issue!
That's a cop-out. ... See? It's stupid. It's wrong. It's bad.
So I absolutely hate how this was done.... I'm pulling it this time, but quite frankly, next time I see this kind of ugly AND TOTALLY POINTLESS layering violation, I will just drop the stupid pull request. ... In other words, this was NOT OK. This was stupid and wrong, and violated all sanity. ... What the hell was going on here?
And by "their" you mean Kay Sievers. Key, I'm fucking tired of the fact that you don't fix problems in the code you write, so that the kernel then has to work around the problems you cause. Kay - one more time: you caused the problem, you need to fix it. None of this "I can do whatever I want, others have to clean up after me" crap.
It does become a problem when you have a system service developer who thinks the universe revolves around him, and nobody else matters, and people sending him bug-reports are annoyances that should be ignored rather than acknowledged and fixed. At that point, it's a problem. It looks like Greg has stepped in as a baby-sitter for Kay, and things are going to be fixed. And I'd really like to avoid adding hacky code to the kernel because of Kay's continued bad behavior, so I hope this works. But it's really sad that things like this get elevated to this kind of situation, and I personally find it annoying that it's always the same fucking primadonna involved.
Why are you making up these completely invalid arguments? Because you are making them up....And given this fact, your denial that "PCI reboot should never be used" is counterfactual. It may be true in some theoretical "this is how the world should work" universe, but in the real world it is just BS. Why are you so deep in denial about this?
NO I AM NOT! Dammit, this feature is fucking brain-damaged. ...But even apart from the Xen case, it was just a confusing hell. Like Yoda said: "Either they are the same or they are not. There is no 'try'". So pick one solution. Don't try to pick the mixed-up half-way case that is a disaster and makes no sense.
Ugh, so I pulled this, but I'm going to unpull it, because I dislike your new "i_mmap_lastmap" field.... makes me just gouge my eyes out. It's not only uglifying generic code, it's _stupid_ even when it's used....But the fact that it adds code to the generic file just adds insult to injury and makes me go "no, I don't want to pull this".
No it didn't. There was nothing accidental about it, and it doesn't even change it the way you claim.... Your explanation makes no sense for _another_ reason.... ... So tell us more about those actual problems, because your patch and explanation is clearly wrong. ... So this whole thing makes no sense what-so-ever.
and this, btw, is just another example of why MCE hardware designers are fucking morons that should be given extensive education about birth control and how not to procreate.
BS. ...And you ignored the real issue: special-casing idle is stupid. It's more complicated, and gives fewer cases where it helps. It's simply fundamentally stupid and wrong.
It appears Intel is fixing their braindamage
Well, that's one way of reading that callchain. I think it's the wrong way of reading it, though. Almost dishonestly so.
Hmm. Less vomit-inducing, except for this part:...Ugh, that just screams for a helper function.
I did look at it, but the thing is horrible. I started on this something like ten times, and always ended up running away screaming.
.. so your whole argument is bogus, because it doesn't actually fix anything else.... You're not fixing the problem, you're fixing one unimportant detail that isn't worth fixing that way.
Greg, this is BS. ... so now you've re-introduced part of the problem, and marked it for stable too. The commit log shows nothing useful. ... And it really _isn't_ a good idea. ... Don't do this shit.
I'm ok with coding, I find your particular patch horrible. You add a dynamic allocator that will work horribly badly if people actually start using it for more complex cases, and then you use that for just about the least interesting case. And the way you do the dynamic allocator, nobody can ever allocate one of the wait-queue entries efficiently by just knowing that they are a leaf and there is never any recursive allocation....
Why the heck are you making up ew and stupid event types? Now you make the generic VM code do stupid things like this:... which makes no sense at all. The names are some horrible abortion too ("RANDW"? That sounds like "random write" to me, not "read-and-write", which is commonly shortened RW or perhaps RDWR. Same foes for RONLY/WONLY - what kind of crazy names are those? But more importantly, afaik none of that is needed. Instead, tell us why you need particular flags, and don't make up crazy names like this. ...., so all those badly named states you've made up seem to be totally pointless. They add no actual information, but they do add crazy code like the above to generic code that doesn't even WANT any of this crap. ... So things like this need to be tightened up and made sane before any chance of merging it.
I really get the feeling that somebody needs to go over this patch-series with a fine comb to fix these kinds of ugly things
I've pulled this, but I was pretty close to saying "screw this shit". Look at commit 9a630d15f16d, and pray tell me why those kinds of commit logs are excusable? That commit message is totally worthless noise. ... Seriously. ... That commit 9a630d15f16d is pure garbage. It's not the only crappy one, but it really does stand out. ...I'd really prefer it to talk about what it merges and why, but it's still much better than your completely information-free merge message.
If this comes from some man-page, then the man-page is just full of shit, and is being crazy. ...So NAK NAK NAK. This is insane and completely wrong. And the bugzilla is crazy too. Why would anybody think that readahead() is the same as read()?
I took it, but I think both your explanation and the patch itself is actually crap. It may fix the issue, but it's seriously confused. ... And the code is crap, because it uses ULONG_MAX etc in ways that simply make no fucking sense. And why does it care about sizeof? ... So I think this fixes a problem, but it's all ugly as hell. ...It's not just that the code is unnecessarily complex, it's WRONG. ... It's just stupid and misleading, and it just so happens to work by random luck ...
.. and apparently this whole paragraph is completely bogus. It does break things, and for normal people. That's what the bug report is all about. So don't waffle about it.... Wrong. We don't break existing setups, and your attitude needs fixing. ... The problem needs to be solved some other way, and developers need to fucking stop with the "we can break peoples setups" mentality./ Hans, seriously. You have the wrong mental model. Fix it.
Christoph, stop arguing. Trust me, Paul knows memory ordering. You clearly do not.
Ok, so I'm looking at the code generation and your compiler is pure and utter shit. ... Lookie here, your compiler does some absolutely insane things with the spilling, including spilling a constant. For chrissake, that compiler shouldn't have been allowed to graduate from kindergarten. We're talking "sloth that was dropped on the head as a baby" level retardation levels here: ... Because it damn well is some seriously crazy shit. However, that constant spilling part just counts as "too stupid to live". ... ... This is your compiler creating completely broken code. 
I really dislike this one.... The other patches look sane, this one I really don't like. You may have good reasons for it, but it's disgusting.
Tejun, absolutely nothing "justifies" things if they break. ...And if nothing breaks, you don't need the excuses. In other words, I'll happily pull this, but your excuses for it are wrong-headed. There is no "crazyness justifies this". That's crap. ... None of this "the interface is crazy, so we can change it".  Because that is pure and utter BS. Whether the interface is crazy or not is entirely irrelevant to whether it can be changed or not. The only thing that matters is whether people actually _trigger_ the issue you have in reality, not whether the issue is crazy.
Please don't. That thing is too ugly to exist. It also looks completely and utterly buggy. There's no way I'm taking it. If switch-names is suddenly conditional, what the fuck happens to the name hash which is unconditionally done with a swap() right afterwards. There's no way that patch is correct
Why do you think it's not acceptable? Why do you raise a stink one day after the patch - that seems to not be very important - is sent out?... I don't think the patch is necessarily wrong, but I don't see why it would be critical, and I definitely don't see why the fuck you are making a big deal of it. Go away, stop bothering people.
See what my complaint is? Not this half-assery that used to be a small random detail, and that the patch makes into an institutionalized and explicit half-assery. (And Mikhail - I'm not ragging on you, even if I'm ragging on the patch. I understand why you did it the way you did, and it makes sense exactly in the "let's reinstate old hackery" model. I just think we can and should do better than that, now that the "exchange" vs "move over" semantics are so explicit)
That's just complete bullshit. The fact is, release() is not synchronous. End of story. ... Anybody who confuses the two is wrong. ... So please kill this "FOPEN_SYNC_RELEASE" thing with fire. It's crazy, it's wrong, it's stupid. It must die.
This is disgusting. Many (most?) __gup_fast() users just want a single page, and the stupid overhead of the multi-page version is already unnecessary. This just makes things much worse.
Yeah, this is pure crap. It doesn't even compile. ... Why the fuck do you send me totally untested crap?
So adding the loop looks like just voodoo programming, not actually fixing anything.
Actually, the real fix would be to not be stupid, and just make the code do something like ...
You're doing completelt faulty math, and you haven't thought it through. ...That's insane. It's crap. All just to try to avoid one page copy. Don't do it. ...Really, you need to rethink your whole "zerocopy" model. It's broken. Nobody sane cares. You've bought into a model that Sun already showed doesn't work. ...
No they aren't. You think they are, and then you find one case, and ignore all the others. ... So no, your patch doesn't change the fundamental issue in any way, shape, or form. I asked you to stop emailing me with these broken "let's fix one special case, because I can't be bothered to understand the big picture" patches. This was another one of those hacky shit patches that doesn't actually change the deeper issue. Stop it. Seriously. This idiotic thread has been going on for too long.
No there isn't. Your "action by the holder" argument is pure and utter garbage, for a very simple and core reason: the filesystem doesn't know or care. ... ...Face it, your patch is broken. And it's fundamentally broken, which is why I'm so tired of your stupid ad-hoc hacks that cannot possibly work.
Yeah. Bloated, over-engineered, and stupid. ... Despite making the code slower, bigger, and buggier. I guess I'll fetch the git tree and see if they document this braindamage.. ...Oh well. What a cock-up. The code is insane in other ways too. ... I can't take it any more. That code is crazy.
And no, we should not play games with "tlb->local.next". That just sounds completely and utterly insane. That's a hack, it's unclear, it's stupid, and it's connected to a totally irrelevant implementation detail, namely that random RCU freeing. Set a flag, for chrissake.
Improve the debugger, don't make kernel code worse because your out-of-tree debugging infrastructure is too broken to live.
Ok, so things are somewhat calm, and I'm trying to take time off to see what's going on. And I'm not happy. ... Please don't call this thing a "generic page table". ... In other words, looking at this, I just go "this is re-implementing existing models, and uses naming that is actively misleading". I think it's actively horrible, in other words.  ... I also find it absolutely disgusting how you use USE_SPLIT_PTE_PTLOCKS for this, which seems to make absolutely zero sense. ... I'm also looking at the "locking". It's insane. It's wrong, and doesn't have any serialization. ... Rik, the fact that you acked this just makes all your other ack's be suspect. Did you do it just because it was from Red Hat, or do you do it because you like seeing Acked-by's with your name? ...
WHAT? NONE OF WHAT YOU SAY MAKES ANY SENSE.
Umm. We had oopses showing it. Several times. ... .. and you and Andi repeatedly refused to make the code more robust when I asked. Which is why I don't work with Andi or you directly any more, ... Every time there were just excuses. Like now. ... I'm done with your crazy unwinder games. ... But this patch I NAK'ed because the code is not readable, and the infrastructure is not bearable. Live with it.
Andy, you need to lay off the drugs.
You have also marked 3.18-rc1 bad twice, along with the network merge, and the tty merge. That's just odd. But it doesn't make the bisect wrong, it just means that you fat-fingered thing and marked the same thing bad a couple of times. Nothing to worry about, unless it's a sign of early Parkinsons...
For a vmalloc() address, you'd have to actually walk the page tables. Which is a fucking horrible idea. Don't do it. ... Where the hell does this crop up, and who does this insane thing anyway? It's wrong. 
Ugh. That's horrid. Do we need to even support O_DIRECT in that case? ... In general, it's really a horrible thing to use, and tends to be a big red sign that "somebody misdesigned this badly"
Gaah. Why do you do this to me? ... That's the wrong format, but it's also the wrong branch name. ... EXCEPT THAT'S WRONG TOO! ... Please fix your script/workflow. I'm not pulling this mess.
.. why did that commit ever even get far enough to get to me? ... Either way, it shows a rather distinct lack of actual testing, wouldn't you say? I really see no excuse for crap like this. ...Linus "not happy" Torvalds
I don't mind it if it's one line, and if people realize that the commentary in the commit in question was pure and utter shit. ... So really, I don't see the point of even a oneliner message. You guys know who the user is. There's no value in the message. Either you fix the user or you don't.
No. Really. No. ... Thomas, you're in denial. ... Your argument "it has a question mark in front of it" objection is bogus. ... I'm just saying that your arguments to ignore CPU0 are pretty damn weak.
So I'm not saying "ifconfig is wonderful". It's not. But I am saying that "changing user interfaces and then expecting people to change is fucking stupid".... Because people who think that "we'll just redesign everything" are actually fucking morons. Really. There's a real reason the kernel has the "no regression" policy. And that reason is that I'm not a moron.
To quote the standard response for people who ignore regressions: "SHUT THE FUCK UP"...I don't understand how people can't get this simple thing. You have two choices: - acknowledge and fix regressions - get the hell out of kernel development....Christ people. Why does this even have to be discussed any more?...But you guys need to shape up. We don't break things....
...End of discussion. Seriously. Your whinging about "support costs" is just crying over the fact that you have users. Deal with it. ...And dammit, I really never ever want to hear arguments against fixing regressions ever again. It really is the #1 rule for the kernel. There is no excuse for that NAK. There is only "sorry".
Really. Shut up.... And if you aren't ok with "wasting time" on trying to give that kind of reassurances to users, then you shouldn't be working on the kernel. I'm serious about this. You really need to understand that. Your job as a kernel developer is very much to support the users. Not try to make it easy for you at the cost of being nasty for them.
Yes, I actually would mind, unless you have a damn good reason for it....I really don't see why you should lie in your /proc/cpuinfo. ...Just give the real information. Don't lie. Quite frankly, the only actual real reason I've heard from you for not having the real bogomips there is "waste of time". And this whole thread has been nothing but waste of time. But it has been you wasting time, and that original commit. ... So quite frankly, my patience for you arguing "wasting time" is pretty damn low. I think your arguments are crap, I still think your NAK was way out of line, and I think it's completely insane to lie about bogomips. It's disasteful, it's dishonest, and there's no reason for it. ... Seriously, what kind of insane argument can you really marshal for lying to users?... Christ, this whole thing is annoying. I really find it offensive how you want to basically lie to users. Stop this idiocy. Really. There is no excuse.
Fuck no. ... You are just making shit up. Bad shit. Get off the drugs, because it's not the good kind.... Cry me a river. ... Bullshit.  This whole thread is now marked as "muted" for me, because I can't take the BS any more. You make no sense. ...You're crazy. Go away. Or don't. I won't be seeing your emails anyway, so why would I care?
Ugh.  This is too ugly, it needs to die.  ...   Because this is unreadable.
Why do I say "total crap"? ...it's really wrong. ...  The comment is also crap. ... So doing this in "__may_sleep()" is just bogus and horrible horrible crap. It turns the "harmless ugliness" into a real harmful bug. ...  PeterZ, please don't make "debugging" patches like this. Ever again. Because this was just stupid, and it took me too long to realize that despite the warning being shut up, the debug patch was still actively doing bad bad things.
Ugh.  This patch is too ugly to live. ...  I really detest debug code (or compiler warnings) that encourage people to write code that is worse than the code that causes the debug code or warning to trigger. It's fundamentally wrong when those "fixes" actually make the code less readable and maintainable in the long run.
Because code like this is just crap:  ... really. It's just crazy.  It makes no sense. It's all just avoiding the warning, it's not making the code any better.
This makes no sense.  You're trying to fix what you perceive as a problem in the page fault handling in some totally different place.  ... Don't try to make horrible code in insane places that have nothing to do with the fundamental problem. Why did you pick this particular get/put user anyway? There are tons others that we don't test, why did you happen pick these and then make it have that horrible and senseless error handling?  Because at NO point was it obvious that that patch had anything at all to do with "out of memory". Not in the code, not in your commit messages, nowhere.  ...
Ugh. Your diffstat is crap, because you don't show the inexact renames that are very abundant in the nouveau driver.
No. Really.  ... No. The whole concept of "drop the lock in the middle" is BROKEN. It's seriously crap. It's not just a bug, it's a really fundamentally wrong thing to do. ... No. That's still wrong. You can have two people holding a write-lock. Seriously. That's shit
No.  I pulled, and immediately unpulled again.  This is complete shit, and the compiler even tells you so:  ... I'm not taking "cleanups" like this. And I certainly don't appreciate being sent completely bogus shit pull requests at the end of the merge cycle.
... There is absolutely no sane reason to use this crap, as far as I can tell. The new "fs_inode_once()" thing is just stupid. ...  Dammit, if we add wrapper and "helper" functions, they should help, not confuse. This thing is just badly named, and there is no actual real explanation for why it exists in the first place, nor for when to use one or the other. There is just an endless series of patches with pointless churn....  Explain it, or that crap gets undone.  I'm annoyed, because shit like this that comes in at the end of the merge window when everybody and their dog sends me random crap on the Friday afternoon before the merge window closes is just annoying as hell. ... Today has been a huge waste of time for me, and reading through this was just the last drop.
And what possible situation could make that "_once()" version ever be valid? None. It's bogus. It's crap. It's insane. There is no way that it is ever a valid question to even ask.
So my patch was obviously wrong, and I should feel bad for suggesting it. I'm a moron, and my expectations that "pte_modify()" would just take the accessed bit from the vm_page_prot field was stupid and wrong.
You make no sense. The commits you list were all on top of plain 4.0-rc2.
NOOO!... Get rid of the fucking size checks etc on READ_ONCE() and friends. ... Hell fucking no. The "something like so" is huge and utter crap, because the barrier is on the wrong side.
Completely immaterial.  Seriously.  ... Answer: you don't. ... It's wrong. It's fundamentally invalid crap.  ... NO WAY IN HELL do we add generic support for doing shit. Really. If p9 does crazy crap, that is not an excuse to extend the crazy crap to more code.
Side note, you'll obviously also need to fix the actual bogus 'gp_init_delay' use in kernel/rcu/tree.c.  That code is horrible.
Why not just revert that commit. It looks like garbage. ... The reason I think it's garbage is... code like the above is just crap to begin with.. So I don't think this code is "fixable". It really smells like a fundamental mistake to begin with. Just revert it, chalk it up as "ok, that was a stupid idea", and move on...
Basically, I absolutely hate the notion of us doing something unsynchronized, when I can see us undoing a mmap that another thread is doing. It's wrong.  You also didn't react to all the other things that were wrong in that patch-set. The games you play with !fatal_signal_pending() etc are just crazy.  End result: I absolutely detest the whole thing. I told you what I consider an acceptable solution instead, that is much simpler and doesn't have any of the problems of your patchset.
Ok, I'm used to fixing up your whitespace and lack of capitalization, but you're getting so incoherent that I can no longer even parse it well enough to fix it up.  English is your first language, right? 
Hell no.  Stop with the random BUG_ON() additions.  ... Dammit, there's no reason to add a BUG_ON() here in the first place, and the reason of "but but it's an unused error return": is fucking retarded.  Stop this idiocy. We don't write crap code just to satisfy some random coding standard or shut up a compiler error.... NO NO NO. ... Really. I'm getting very tired indeed of people adding BUG_ON's like that. Stop it.
This is not at all equivalent, and it looks stupid.
Bullshit, Andrea.  That's exactly what you said in the commit message for the broken patch that I complained about. ... and I pointed out that your commit message was garbage, and that it's not at all as easy as you claim, and that your patch was broken, and your description was even more broken.... Your commit message was garbage, and actively misleading. Don't make excuses.
No. I refuse to touch this crap.... You really expect me to take crap like that? Hell no.  If your stuff isn't self-sufficient, then it's not something I want to ever pull. If the top of the tree you ask me to pull doesn't work (and quite frankly, every commit leading to it) then it's bad and unusable.  ...But it's one thing to have an unintentional bug, and another thing to do it on _purpose_.
No, it really isn't.  You still seem to be in denial:  ... NO YOU DID NOT! Stop claiming that.  You didn't actually test what you sent me. YOU TESTED SOMETHING ENTIRELY DIFFERENT.  Do you really not see the difference? Because that's a honking big difference. ...
Ugh. I hate that. It looks bad, but it's also pointless.  ...Compilers that warn for the good kind of safe range tests should be taken out and shot. ...  so I just detest that buggy piece of crap for so many reasons.  It's also sad that a one-liner commit that claims to "fix" something was this broken to begin with. Grr. Honza, not good.
What the hell have you done with the commit messages?  The first line is completely corrupted for those reverts, and as a result your own shortlog looks like crap and is completely misleading. ... presumably due to some horribly broken automation crap of yours that adds the "[media]" prefix or something.  How did you not notice this when you sent the shortlog? Or even earlier? This is some serious shit, since it basically means that your log messages are very misleading, since the one-liner actually implies exactly the reverse of what the commit does.  I unpulled this, because I think misleading commit messages is a serious problem, and basically halfu (and patch-wise, the bulk) of the commits in this queue are completely broken.
... Christ, people. Learn C, instead of just stringing random characters together until it compiles (with warnings). ... There are arguments for them, but they are from weak minds. ... A later patch then added onto the pile of manure by adding another broken array argument, ...It's basically just lying about what is going on, and the only thing it documents is "I don't know how to C". ... Please people. ...
No. You think WRONG.  ... YOUR CODE IS WRONG, AND REALITY SHOWS THAT YOUR DEFAULT IS CRAP.  Really. ... BS.  The only reason for your interface was that it was simpler to use. You broke that.  And you broke that for no good reason. .... So your "default" is not actually safe. It breaks real cases, and doesn't add any security.  It's broken.
Your arguments all are entirely irrelevant to the fundamental issue.  And then when I suggest a sane interface that doesn't have this problem, your arguments are crap - again. ...  Bullshit. You clearly didn't even read my proposal. ...  Anyway, I'm not discussing this. You are clearly unwilling to just admit that your patch-series was broken, ... As such, why bother arguing? 
No. Stop this theoretical idiocy.  We've tried it. I objected before people tried it, and it turns out that it was a horrible idea.... So this "people should check for allocation failures" is bullshit. It's a computer science myth. ... So no. ...Get over it. I refuse to go through that circus again. It's stupid. 
Really. Stop this idiocy. We have gone through this before. It's a disaster.
Christ people. This is just shit.... But what makes me upset is that the crap is for completely bogus reasons. ...  and anybody who thinks that the above is  (a) legible (b) efficient (even with the magical compiler support) (c) particularly safe  is just incompetent and out to lunch.  The above code is shit, and it generates shit code. It looks bad, and there's no reason for it.... Really. Give me one reason why it was written in that idiotic way with two different conditionals, and a shiny new nonstandard function that wants particular compiler support to generate even half-way sane code, and even then generates worse code? A shiny function that we have never ever needed anywhere else, and that is just compiler-masturbation. ... So I really see no reason for this kind of complete idiotic crap. ... Because I'm not pulling this kind of completely insane stuff that generates conflicts at rc7 time, and that seems to have absolutely no reason for being anm idiotic unreadable mess. ... And it's a fucking bad excuse for that braindamage.  I'm sorry, but we don't add idiotic new interfaces like this for idiotic new code like that. ...In fact, I want to make it clear to everybody that code like this is completely unacceptable. Anybody who thinks that code like this is "safe" and "secure" because it uses fancy overflow detection functions is so far out to lunch that it's not even funny. All this kind of crap does is to make the code a unreadable mess with code that no sane person will ever really understand what it actually does.  Get rid of it. And I don't ever want to see that shit again.
This code makes absolutely no sense.... So the code may end up working, but the comments in it are misleading, insane, and nonsensical. ...The comment is actively and entirely wrong. ... So the code looks insane to me. ...So in no case can that code make sense, as far as I can tell.
Stop this idiocy. ... And that disgusting "overflow_usub()" in no way makes the code more readable. EVER.  So stop just making things up.... It wasn't more efficient, it wasn't more legible, and it simply had no excuse for it. Stop making excuses for shit.
Really. That's it. Claiming that that is "complicated" and needs a helper function is not something sane people do. A fifth-grader that isn't good at math can understand that.  In contrast, nobody sane understands "usub_overflow(a, b, &res)".  So really. Stop making inane arguments.
Hell no.... In exactly WHAT crazy universe does that make sense as an argument?  It's like saying "I put literal shit on your plate, because there are potentially nutritious sausages that look superficially a bit like the dogshit I served you".  Seriously.  ... It's exactly the same argument as "dog poop superficially looks like good sausages".  Is that really your argument?  There is never an excuse for "usub_overflow()". It's that simple.  No amount of _other_ overflow functions make that shit palatable. 
No.  Your repository is bogus.  I don't know what the hell you have done or why you have done it, but you have actually rebased my 4-3-rc7 commit that updates the Makefile from rc6 to rc7...  and there is no way I will take things like this.
Your arguments make no sense.  ... NO IT DOES NOT.  Christ, Paul. ...  You have turned it into something else in your mind. But your mind is WRONG.  ... I really don't understand your logic. ... That is NOT WHAT I WANT AT ALL.
That's insane.  ... It is simply not sensible to have a "wait_for_unlock()" that then synchronizes loads or stores that happened before the wait. That's some crazy voodoo programming. ... Or just take the damn lock, and don't play any games at all.
Are we trying to win some obfuscated C contest here?
So this is definitely crap.  You can't return an error. ... Same deal. Returning an error is wrong.
Absolutely not.  I will not take this, and it's stupid in the extreme.  ...That's just crazy talk.  ... So I don't know how many ways I can say "NO", but I'll not take anythign like this. It's completely wrong.