(lp0
(dp1
S'text'
p2
S'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?'
p3
sS'hate'
p4
F0.27520477805473287
sa(dp5
g2
S'What drugs are you on? Your example is moronic, and against all _documented_ uses of chroot.'
p6
sg4
F0.3011801299692075
sa(dp7
g2
S'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*.'
p8
sg4
F0.401778212265373
sa(dp9
g2
S'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*.'
p10
sg4
F0.40353982951892287
sa(dp11
g2
S'Andy, you need to lay off the drugs.'
p12
sg4
F0.4465161295570569
sa(dp13
g2
S"Because you screwed up that pull request, and I argue that you screwed up exactly *because* it's ambiguous and confusing."
p14
sg4
F0.4482903428839735
sa(dp15
g2
S'And that audit code really is aushit. I think I found a bug in it while just scanning it:'
p16
sg4
F0.4497502159878837
sa(dp17
g2
S'Congratulations, you seem to have found a whole new and unique way of screwing up ;) Linus "my mom called me \'special\' too" Torvalds'
p18
sg4
F0.4613196205893423
sa(dp19
g2
S'Are we trying to win some obfuscated C contest here?'
p20
sg4
F0.4868557751547127
sa(dp21
g2
S'Seriously. People who use BUG() statements like some kind of assert() are a menace to society. They kill machines.'
p22
sg4
F0.49000780599437455
sa(dp23
g2
S'David, what the heck are you doing? ... Seriously. Those commits now have TOTALLY MISLEADING summary messages. ...'
p24
sg4
F0.49979846957843743
sa(dp25
g2
S"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."
p26
sg4
F0.5207378235075887
sa(dp27
g2
S"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."
p28
sg4
F0.5254318615350907
sa(dp29
g2
S'David, I want to make it very clear that if you *ever* suggest another big include file cleanup, I will say "f*ck 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".'
p30
sg4
F0.5272125566149333
sa(dp31
g2
S"Christ. This is so ugly that it's almost a work of art."
p32
sg4
F0.5435223306059218
sa(dp33
g2
S"WRONG. Alan, you're not getting it. Loading firmware as part of suspend/resume is WRONG."
p34
sg4
F0.5482156506373634
sa(dp35
g2
S"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."
p36
sg4
F0.5584212573284328
sa(dp37
g2
S'WHAT? NONE OF WHAT YOU SAY MAKES ANY SENSE.'
p38
sg4
F0.5609879912918221
sa(dp39
g2
S"That's just disgusting crazy talk. Christ, David, get a grip on yourself. ..."
p40
sg4
F0.5617764857509643
sa(dp41
g2
S'Ok. So your commit message and explanation was pure and utter tripe,'
p42
sg4
F0.56989378938028
sa(dp43
g2
S'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,'
p44
sg4
F0.5835065754744607
sa(dp45
g2
S"Ugh. Your diffstat is crap, because you don't show the inexact renames that are very abundant in the nouveau driver."
p46
sg4
F0.5854653490310119
sa(dp47
g2
S'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, ...'
p48
sg4
F0.5858136278335135
sa(dp49
g2
S'...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.'
p50
sg4
F0.5878761330573111
sa(dp51
g2
S'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)'
p52
sg4
F0.5893440056351167
sa(dp53
g2
S'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.'
p54
sg4
F0.5894206644406071
sa(dp55
g2
S"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."
p56
sg4
F0.5917782985862905
sa(dp57
g2
S'That\'s f*cking 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.'
p58
sg4
F0.5947676945714664
sa(dp59
g2
S'Don\'t try to change the rules because you think you are "clever". You\'re only making things worse.'
p60
sg4
F0.5958461581038789
sa(dp61
g2
S'Please, Debabrata, humor me, and just try the patch. And try reading the source code. Because your statement is BS.'
p62
sg4
F0.5966823729721406
sa(dp63
g2
S'What a crock. That direct-IO code is hack-upon-hack. Whoever wrote it should be shot. ...'
p64
sg4
F0.5969650366936845
sa(dp65
g2
S'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.'
p66
sg4
F0.6018116750393498
sa(dp67
g2
S"Did anybody ever actually look at this sh*t-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."
p68
sg4
F0.6033242178323879
sa(dp69
g2
S'Umm. I think your argument is totally braindead and wrong. My counter-argument is very simple: "So what?"'
p70
sg4
F0.6065125267770252
sa(dp71
g2
S'The games with "max_block" are hilarious. In a really sad way. That whole blkdev_get_blocks() function is pure and utter shit.'
p72
sg4
F0.609408807546925
sa(dp73
g2
S"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."
p74
sg4
F0.609458734134122
sa(dp75
g2
S'You make no sense. The commits you list were all on top of plain 4.0-rc2.'
p76
sg4
F0.6122008243719
sa(dp77
g2
S'It appears Intel is fixing their braindamage'
p78
sg4
F0.6132644828017194
sa(dp79
g2
S"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."
p80
sg4
F0.6137721099390107
sa(dp81
g2
S'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.'
p82
sg4
F0.6153743800086194
sa(dp83
g2
S"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 f*cking insane beyond belief."
p84
sg4
F0.6167289494632293
sa(dp85
g2
S"Your arguments only make sense if you accept those insane assumptions to begin with. And I don't."
p86
sg4
F0.6176119930963673
sa(dp87
g2
S'... Christ. That code is a mess. ...'
p88
sg4
F0.6192799969735421
sa(dp89
g2
S"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 F*CKING BYTE AT A TIME with system calls for each byte should be retroactively aborted. Who the f*ck 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?"
p90
sg4
F0.6210100248236998
sa(dp91
g2
S"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...."
p92
sg4
F0.6253973681379242
sa(dp93
g2
S'... 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.'
p94
sg4
F0.6257981606555768
sa(dp95
g2
S'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.'
p96
sg4
F0.6295136856419652
sa(dp97
g2
S'Oh, please, that\'s a British-level understatement. It\'s like calling WWII "a small bother". That\'s too ugly to live.'
p98
sg4
F0.6301846210610489
sa(dp99
g2
S"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."
p100
sg4
F0.630892693369288
sa(dp101
g2
S'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.'
p102
sg4
F0.6344161953611994
sa(dp103
g2
S'Christoph, stop arguing. Trust me, Paul knows memory ordering. You clearly do *not*.'
p104
sg4
F0.6383285547138791
sa(dp105
g2
S'Stop being a moron. Go back and read the "nobody can work with you".'
p106
sg4
F0.6389533107811186
sa(dp107
g2
S'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.'
p108
sg4
F0.6394392385636707
sa(dp109
g2
S'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.'
p110
sg4
F0.6418009529098407
sa(dp111
g2
S"I'm a moron."
p112
sg4
F0.6428015433596385
sa(dp113
g2
S'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...'
p114
sg4
F0.6442688807221422
sa(dp115
g2
S'How f*cking 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.'
p116
sg4
F0.6470514200973677
sa(dp117
g2
S"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"
p118
sg4
F0.647358037294621
sa(dp119
g2
S"Well, that's one way of reading that callchain. I think it's the *wrong* way of reading it, though. Almost dishonestly so."
p120
sg4
F0.6497172173159032
sa(dp121
g2
S"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."
p122
sg4
F0.6507907365954533
sa(dp123
g2
S"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. ..."
p124
sg4
F0.6520034837534499
sa(dp125
g2
S"Christ, why can't people learn?"
p126
sg4
F0.6547076153082676
sa(dp127
g2
S'and this, btw, is just another example of why MCE hardware designers are f*cking morons that should be given extensive education about birth control and how not to procreate.'
p128
sg4
F0.6558956701473204
sa(dp129
g2
S"Yeah, I'm a f*cking moron."
p130
sg4
F0.658394270909275
sa(dp131
g2
S'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.'
p132
sg4
F0.6633325780254008
sa(dp133
g2
S'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. ...'
p134
sg4
F0.6648610850175812
sa(dp135
g2
S"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."
p136
sg4
F0.6655628135523088
sa(dp137
g2
S'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.'
p138
sg4
F0.666816599355471
sa(dp139
g2
S'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 f*cking 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...'
p140
sg4
F0.6688304255216247
sa(dp141
g2
S"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."
p142
sg4
F0.6700635035159841
sa(dp143
g2
S"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 *proof* to the exact contrary behavior! What f*cking planet are you from, again? Christ, that's hubris. ..."
p144
sg4
F0.6735483994285129
sa(dp145
g2
S'Ingo, stop this idiotic nonsense. You seem to think that "kvmtool is useful for kernel" is somehow relevant. IT IS TOTALLY IRRELEVANT.'
p146
sg4
F0.6749470293279405
sa(dp147
g2
S"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."
p148
sg4
F0.6760944134005538
sa(dp149
g2
S'So stop spouting garbage.'
p150
sg4
F0.6763883775150119
sa(dp151
g2
S'Christ, we should just try to get rid of the personality bits entirely, they are completely insane'
p152
sg4
F0.6798668047659948
sa(dp153
g2
S'Quite frankly, this is f*cking moronic.'
p154
sg4
F0.6876318867401255
sa(dp155
g2
S"Grr. I've pulled it, but looking at that history, it's just pure and utter f*cking garbage."
p156
sg4
F0.6902609711816332
sa(dp157
g2
S"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."
p158
sg4
F0.6908697958193426
sa(dp159
g2
S'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 f*cking stupid".... Because people who think that "we\'ll just redesign everything" are actually f*cking morons. Really. There\'s a real reason the kernel has the "no regression" policy. And that reason is that I\'m not a moron.'
p160
sg4
F0.6909405395866941
sa(dp161
g2
S"I'll let you think about just how stupid that comment was for a moment."
p162
sg4
F0.69095835350407
sa(dp163
g2
S'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.'
p164
sg4
F0.691796243178145
sa(dp165
g2
S"...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?"
p166
sg4
F0.6974132745024295
sa(dp167
g2
S'Yes it damn well is. Stop the f*cking 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. ...'
p168
sg4
F0.698227424180082
sa(dp169
g2
S"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."
p170
sg4
F0.7003878157022334
sa(dp171
g2
S'The reading comprehension here is abysmal. ...And none of that matters for my argument AT ALL.'
p172
sg4
F0.7005104776547095
sa(dp173
g2
S"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 sh*t you send me. Comprende?"
p174
sg4
F0.7013781127365946
sa(dp175
g2
S'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.'
p176
sg4
F0.7097152222724888
sa(dp177
g2
S'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.'
p178
sg4
F0.7116556669807639
sa(dp179
g2
S'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.'
p180
sg4
F0.716957130137101
sa(dp181
g2
S"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."
p182
sg4
F0.7183062080139838
sa(dp183
g2
S'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.'
p184
sg4
F0.7193511040393217
sa(dp185
g2
S'What BS is that? If you use an "atomic_store_explicit()", by definition you\'re either (a) f*cking 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.'
p186
sg4
F0.7208914928670503
sa(dp187
g2
S'This is the kind of totally bogus crap that no sane person should ever spout. Stop it.'
p188
sg4
F0.7228884292942104
sa(dp189
g2
S'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?'
p190
sg4
F0.724450098397838
sa(dp191
g2
S"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."
p192
sg4
F0.7260907702568797
sa(dp193
g2
S'Ugh. I pulled it, but things like this makes me want to dig my eyes out with a spoon:...'
p194
sg4
F0.7282438863837265
sa(dp195
g2
S"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. ..."
p196
sg4
F0.730275869385983
sa(dp197
g2
S'NOOO!... Get rid of the f*cking size checks etc on READ_ONCE() and friends. ... Hell f*cking no. The "something like so" is huge and utter crap, because the barrier is on the wrong side.'
p198
sg4
F0.7311487138680152
sa(dp199
g2
S"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?"
p200
sg4
F0.7338889133156115
sa(dp201
g2
S"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."
p202
sg4
F0.7345173280929542
sa(dp203
g2
S'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. ...'
p204
sg4
F0.7351130067196627
sa(dp205
g2
S'I never *ever* want to see this code ever again. Sorry, but last time was too f*cking painful.'
p206
sg4
F0.7367643369256935
sa(dp207
g2
S'This looks totally invalid....Your patch is horribly wrong.'
p208
sg4
F0.7401150258921102
sa(dp209
g2
S"No it's not. Please fix your crappy script. First off, that '#' is wrong. It should be a space."
p210
sg4
F0.7426792635047614
sa(dp211
g2
S'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.'
p212
sg4
F0.743261689308738
sa(dp213
g2
S'What the F*CK is wrong with people?'
p214
sg4
F0.7451454396703296
sa(dp215
g2
S'...And a C++ person who says that "(vodi *)0" is just any "void *" is a *fucking*moron*, ...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.'
p216
sg4
F0.7454519550857
sa(dp217
g2
S"No, guys. That cannot work. It's a completely moronic idea."
p218
sg4
F0.7462408239078641
sa(dp219
g2
S"Yeah, it's a hack, and it's wrong, and we should figure out how to do it right."
p220
sg4
F0.7463157575296538
sa(dp221
g2
S'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 f*cking late too. ... I\'m grumpy, because all of this code is UTTER SH*T, and it was sent to me. Why?'
p222
sg4
F0.7469102462898389
sa(dp223
g2
S'My point is that I have sixteen pointless messages in my mbox, half of which are due to just your argumentative nature.'
p224
sg4
F0.7469964835334935
sa(dp225
g2
S"So this is definitely crap.  You can't return an error. ... Same deal. Returning an error is wrong."
p226
sg4
F0.74723713946293
sa(dp227
g2
S"This seems to be just pure stupid. ...Even the help message is pure and utter garbage ... Asking the user questions that make no f*cking sense to ask is stupid. And I'm not knowingly pulling stupid crap."
p228
sg4
F0.7481964958616176
sa(dp229
g2
S'And if you cannot understand what tens of people have tried to explain to you, you are just f*cking stupid.'
p230
sg4
F0.7488398264300431
sa(dp231
g2
S'They may be readable, but they are total shit. ... So no. Hell no.'
p232
sg4
F0.7490401448416896
sa(dp233
g2
S'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 f*cking thing. NAK on the patch until sanity is restored. This is just total voodoo programming.'
p234
sg4
F0.7493741531193527
sa(dp235
g2
S'This is why I don\'t like it when I see Torvald talk about "proving" things. It\'s bullshit.'
p236
sg4
F0.7511155197081347
sa(dp237
g2
S'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 sh*t 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.'
p238
sg4
F0.7526992070200629
sa(dp239
g2
S'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.'
p240
sg4
F0.7537096548107397
sa(dp241
g2
S"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."
p242
sg4
F0.7537251528715909
sa(dp243
g2
S'Ugh: ... Can we please move that abortion into arch/powerpc/? Instead of making generic code even uglier..'
p244
sg4
F0.7552048443254205
sa(dp245
g2
S"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 f*ck you are making a big deal of it. Go away, stop bothering people."
p246
sg4
F0.7560838366009982
sa(dp247
g2
S'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.'
p248
sg4
F0.7562240955547168
sa(dp249
g2
S"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 f*cking moron. I'm stupider for just reading your email. Go away."
p250
sg4
F0.7573115381946609
sa(dp251
g2
S".. 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."
p252
sg4
F0.7580508860722449
sa(dp253
g2
S"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 f*cking moronic. ... Stop the idiocy. ..."
p254
sg4
F0.7613214610690521
sa(dp255
g2
S"That's absolutely insane. It's insane for two reasons: - it's not SUFFICIENT. ... - it's POINTLESS and WRONG. ..."
p256
sg4
F0.7622273445742606
sa(dp257
g2
S"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."
p258
sg4
F0.7625617442861903
sa(dp259
g2
S"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."
p260
sg4
F0.764044129341103
sa(dp261
g2
S'Bullshit. That\'s exactly the wrong kind of thinking. ... This whole discussion has been f*cking 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.'
p262
sg4
F0.7643113407762194
sa(dp263
g2
S"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)."
p264
sg4
F0.7644553813120065
sa(dp265
g2
S"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."
p266
sg4
F0.7664637795638153
sa(dp267
g2
S"Guys, this is not a dick-sucking contest. ... If Red Hat wants to deep-throat Microsoft, that's *your* issue."
p268
sg4
F0.7680006651105272
sa(dp269
g2
S'sizeof without parenthesis is an abomination, and should never be used. ... The sane solution is: just add the f*cking 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. ...'
p270
sg4
F0.7684528654812404
sa(dp271
g2
S'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".'
p272
sg4
F0.7714453966473782
sa(dp273
g2
S'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.'
p274
sg4
F0.7720327748326408
sa(dp275
g2
S"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."
p276
sg4
F0.7725198031833707
sa(dp277
g2
S'So adding the loop looks like just voodoo programming, not actually fixing anything.'
p278
sg4
F0.7767215408126428
sa(dp279
g2
S'... 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. ...'
p280
sg4
F0.777722536063855
sa(dp281
g2
S'... 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 f*cking 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 f*cking crazy. And please don\'t use "armv8", because it\'s just completely retarded and confused.'
p282
sg4
F0.7811281591516777
sa(dp283
g2
S"Stop right there. ... This is about your patch BREAKING EXISTING BINARIES. So stop the f*&^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."
p284
sg4
F0.7825150243941044
sa(dp285
g2
S'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 ;)'
p286
sg4
F0.7830813361037369
sa(dp287
g2
S'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.'
p288
sg4
F0.7841595442902811
sa(dp289
g2
S"...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?"
p290
sg4
F0.7865562146315987
sa(dp291
g2
S'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.'
p292
sg4
F0.7873434558648165
sa(dp293
g2
S'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.'
p294
sg4
F0.7895454699421509
sa(dp295
g2
S"Really. Stop this idiocy. We have gone through this before. It's a disaster."
p296
sg4
F0.7899533604712485
sa(dp297
g2
S'I think that code is bad, and you should feel bad.'
p298
sg4
F0.7907568143335979
sa(dp299
g2
S'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'
p300
sg4
F0.7918722805993774
sa(dp301
g2
S'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!'
p302
sg4
F0.796587186134485
sa(dp303
g2
S"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?"
p304
sg4
F0.7975509400529777
sa(dp305
g2
S'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 f*ck 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 sh*t. ...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.'
p306
sg4
F0.7987151585936965
sa(dp307
g2
S'... I don\'t understand why this seems to be so hard for people to understand. ...this whole thread is a wonderful example of how F*CKING 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).'
p308
sg4
F0.8008857942638532
sa(dp309
g2
S'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.'
p310
sg4
F0.8011116731689472
sa(dp311
g2
S'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.'
p312
sg4
F0.8014264696501292
sa(dp313
g2
S'*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 f*cking 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?'
p314
sg4
F0.801731111695407
sa(dp315
g2
S"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*."
p316
sg4
F0.8017644563947721
sa(dp317
g2
S'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.'
p318
sg4
F0.8022031025193204
sa(dp319
g2
S"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."
p320
sg4
F0.8026464596433878
sa(dp321
g2
S'Hmm. Less vomit-inducing, except for this part:...Ugh, that just *screams* for a helper function.'
p322
sg4
F0.802683443638446
sa(dp323
g2
S'... 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 f*cking insane things ... The code is shit. Just fix the shit, instead of trying to come up with some totally different model. Ok? ...'
p324
sg4
F0.8038211248696474
sa(dp325
g2
S"Duh. That is just broken. ... That's just stupid."
p326
sg4
F0.8049355034388979
sa(dp327
g2
S'No. I\'m not pulling 3000 lines of broken defconfig crap. That defconfig update is pure and utter shit, and changes from the minimal kind of defconfig to the old-style "everything and the kitchen sink" crap. We started doing that defconfig minimization for a reason. See commit 8b1bb90701f9 for example. We\'re not going back to the bad old days, and I\'m not pulling thousands of lines or pure garbage noise just because you were too lazy to do it right.'
p328
sg4
F0.806512451074602
sa(dp329
g2
S'No it\'s not. Thomas, stop this crap already. Look at the f*cking 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 f*ck 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.'
p330
sg4
F0.8082092019063171
sa(dp331
g2
S"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 f*cking insane. Stop this kind of idiocy. The code looks bad, and the logic is pure shit too."
p332
sg4
F0.8089388655340428
sa(dp333
g2
S'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.'
p334
sg4
F0.8093202085297696
sa(dp335
g2
S"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."
p336
sg4
F0.8102418937082152
sa(dp337
g2
S'Stop the idiotic arguing already.'
p338
sg4
F0.810709046585318
sa(dp339
g2
S"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."
p340
sg4
F0.8113774269329408
sa(dp341
g2
S'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 f*cking 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.'
p342
sg4
F0.8116823499648296
sa(dp343
g2
S"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."
p344
sg4
F0.8127415613736015
sa(dp345
g2
S'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.'
p346
sg4
F0.8129376023678443
sa(dp347
g2
S'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.'
p348
sg4
F0.8129752569843693
sa(dp349
g2
S'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.'
p350
sg4
F0.8132106003206262
sa(dp351
g2
S"What the F*CK, 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 *IF* 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\xc3\xa4\xc3\xa4 just to express my disgust and frustration with this crap."
p352
sg4
F0.8139540249123025
sa(dp353
g2
S'This looks completely broken to me. ... Wtf? Am I missing something?'
p354
sg4
F0.8140783660458883
sa(dp355
g2
S'.. 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 f*cking stop with the "we can break peoples setups" mentality./ Hans, seriously. You have the wrong mental model. Fix it.'
p356
sg4
F0.8148479940696665
sa(dp357
g2
S"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 f*ck 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."
p358
sg4
F0.814898612788688
sa(dp359
g2
S"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."
p360
sg4
F0.8157836516258494
sa(dp361
g2
S'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.'
p362
sg4
F0.8163050498769295
sa(dp363
g2
S'Yes, I\'m upset. Very upset. ... So your question "why would pulseaudio care" is totally *irrelevant*, senseless, and has nothing to do with anything.'
p364
sg4
F0.8163674033539857
sa(dp365
g2
S"I absolutely detest these types. I realize that we already have a few users, but just looking at these diffs *hurts*. It's disgusting."
p366
sg4
F0.8197295535360578
sa(dp367
g2
S"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."
p368
sg4
F0.8198414293995426
sa(dp369
g2
S'Grr. I hate it when people do this. Your merge message sucks.'
p370
sg4
F0.8207332940990693
sa(dp371
g2
S"Christ. This one is too ugly to live. I'm not pulling crap like this. It's f*^&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."
p372
sg4
F0.8215065507011629
sa(dp373
g2
S"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 f*ck happens to the name hash which is unconditionally done with a swap() right afterwards. There's no way that patch is correct"
p374
sg4
F0.8215622542634073
sa(dp375
g2
S"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."
p376
sg4
F0.8216988903895655
sa(dp377
g2
S"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."
p378
sg4
F0.8239366893463678
sa(dp379
g2
S"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."
p380
sg4
F0.8248763577834479
sa(dp381
g2
S"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. ..."
p382
sg4
F0.824927722167148
sa(dp383
g2
S'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 f*cking 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?'
p384
sg4
F0.8283600499747166
sa(dp385
g2
S'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 f*cking 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.'
p386
sg4
F0.828849409027625
sa(dp387
g2
S'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.'
p388
sg4
F0.8299087057272497
sa(dp389
g2
S"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...."
p390
sg4
F0.8314109841244047
sa(dp391
g2
S'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 sh*t patches that doesn\'t actually change the deeper issue. Stop it. Seriously. This idiotic thread has been going on for too long.'
p392
sg4
F0.8323267749129
sa(dp393
g2
S'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, f*ck 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!...'
p394
sg4
F0.8326730446019563
sa(dp395
g2
S"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."
p396
sg4
F0.8348503697757049
sa(dp397
g2
S'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.'
p398
sg4
F0.8349956577323447
sa(dp399
g2
S'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.'
p400
sg4
F0.8350117641043012
sa(dp401
g2
S'.. 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'
p402
sg4
F0.838218598944263
sa(dp403
g2
S'I would love to blame gcc, but no, I think the code is crap. ... And gcc would be completely correct. That test is moronic.'
p404
sg4
F0.8385927406257188
sa(dp405
g2
S"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 f*cking retarded. ..."
p406
sg4
F0.8389756777018744
sa(dp407
g2
S'If this comes from some man-page, then the man-page is just full of sh*t, 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()?'
p408
sg4
F0.8397813542139798
sa(dp409
g2
S'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.'
p410
sg4
F0.8398371907439319
sa(dp411
g2
S'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.'
p412
sg4
F0.8401642774498181
sa(dp413
g2
S"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?"
p414
sg4
F0.8407231992027466
sa(dp415
g2
S"This has so much wrong that I don't know where to start."
p416
sg4
F0.8417064101827453
sa(dp417
g2
S'NO I AM NOT! Dammit, this feature is f*cking 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.'
p418
sg4
F0.8424148553127997
sa(dp419
g2
S'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*f&^#ing*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.'
p420
sg4
F0.8425100124780881
sa(dp421
g2
S'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.'
p422
sg4
F0.8434476248737879
sa(dp423
g2
S"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..."
p424
sg4
F0.8441764538366523
sa(dp425
g2
S"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* f*cking 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. ..."
p426
sg4
F0.8443138084082528
sa(dp427
g2
S'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".'
p428
sg4
F0.844400180291415
sa(dp429
g2
S'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*'
p430
sg4
F0.8448858194517508
sa(dp431
g2
S'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.'
p432
sg4
F0.8457555416068469
sa(dp433
g2
S'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"'
p434
sg4
F0.8458575409888278
sa(dp435
g2
S"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."
p436
sg4
F0.8474158356369889
sa(dp437
g2
S'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. ...'
p438
sg4
F0.8475229805962871
sa(dp439
g2
S'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.'
p440
sg4
F0.8480862125699891
sa(dp441
g2
S'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?'
p442
sg4
F0.8481493300006194
sa(dp443
g2
S"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."
p444
sg4
F0.8502581437028554
sa(dp445
g2
S"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."
p446
sg4
F0.8506653143731778
sa(dp447
g2
S"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."
p448
sg4
F0.8521833259539588
sa(dp449
g2
S'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...'
p450
sg4
F0.8521992066383708
sa(dp451
g2
S'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.'
p452
sg4
F0.8532715024553228
sa(dp453
g2
S"...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?"
p454
sg4
F0.8534513412321592
sa(dp455
g2
S'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. ...'
p456
sg4
F0.8542957166678475
sa(dp457
g2
S'... 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 f*cking moron. ...This is the kind of thinking and code that just makes me go "No way, not today, not ever". It\'s *stupid*.'
p458
sg4
F0.8543501607268051
sa(dp459
g2
S'...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".'
p460
sg4
F0.8547854359966223
sa(dp461
g2
S"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 f*cking primadonna involved."
p462
sg4
F0.8554723792056538
sa(dp463
g2
S".. And how the f*^& 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."
p464
sg4
F0.8560065729226336
sa(dp465
g2
S'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 sh*t, 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 *half* (and patch-wise, the bulk) of the commits in this queue are completely broken.'
p466
sg4
F0.8560482082252309
sa(dp467
g2
S"That's a cop-out. ... See? It's stupid. It's wrong. It's *bad*."
p468
sg4
F0.8566992640799118
sa(dp469
g2
S"Not acceptable. ... Plase stop sending me untested crap that doesn't even compile cleanly!"
p470
sg4
F0.8569026842796138
sa(dp471
g2
S"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 f*cking disgrace. ... Stop making excuses for it. Really. It just makes you look even worse. ..."
p472
sg4
F0.857176751784924
sa(dp473
g2
S'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.'
p474
sg4
F0.8577694243214468
sa(dp475
g2
S"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!"
p476
sg4
F0.8582253166579739
sa(dp477
g2
S'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.'
p478
sg4
F0.8589598049817351
sa(dp479
g2
S'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.'
p480
sg4
F0.859209414339482
sa(dp481
g2
S'Ugh, this is disgusting.'
p482
sg4
F0.8596986686485475
sa(dp483
g2
S'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 f*cking "compliance tool", because it is obviously broken. And fix your approach to kernel programming'
p484
sg4
F0.8617790975244219
sa(dp485
g2
S'... 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 f*cking 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?'
p486
sg4
F0.8623463787609112
sa(dp487
g2
S"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."
p488
sg4
F0.8625105510296714
sa(dp489
g2
S'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? ...'
p490
sg4
F0.862733574040647
sa(dp491
g2
S'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....'
p492
sg4
F0.8630689004755419
sa(dp493
g2
S'Ugh. This is getting really ugly. ... because quite frankly, the whole spinunlock inlining logic is *already* unreadable, and you just made it worse.'
p494
sg4
F0.8639408003469052
sa(dp495
g2
S'Whjat the f*ck 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!'
p496
sg4
F0.8645812553613907
sa(dp497
g2
S'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.'
p498
sg4
F0.8647867861849572
sa(dp499
g2
S'Ugh.  This is too ugly, it needs to die.  ...   Because this is unreadable.'
p500
sg4
F0.8647894373012335
sa(dp501
g2
S"No. That patch is braindead. I wouldn't pull it even if it wasn't this late. ... What the f*ck is the point? ... What am I missing?"
p502
sg4
F0.8648319423654469
sa(dp503
g2
S'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.'
p504
sg4
F0.8650075121616609
sa(dp505
g2
S"Improve the debugger, don't make kernel code worse because your out-of-tree debugging infrastructure is too broken to live."
p506
sg4
F0.8660573622760088
sa(dp507
g2
S'Actually, the real fix would be to not be stupid, and just make the code do something like ...'
p508
sg4
F0.8660928659488061
sa(dp509
g2
S'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....'
p510
sg4
F0.8670972003346735
sa(dp511
g2
S"So? Even if we hadn't had this bug before (we have), your argument is utter crap. ...Stop arguing for crap."
p512
sg4
F0.8675693737271911
sa(dp513
g2
S'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 f*ck 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...'
p514
sg4
F0.8725632140721964
sa(dp515
g2
S'And by "their" you mean Kay Sievers. Key, I\'m f*cking 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.'
p516
sg4
F0.8733085814530921
sa(dp517
g2
S'...This is wrong. Or at least stupid.'
p518
sg4
F0.8740438418393008
sa(dp519
g2
S'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.'
p520
sg4
F0.8752290359895759
sa(dp521
g2
S"No, please don't use this idiotic example. It is wrong....Anybody who argues anything else is wrong, or confused, or confusing."
p522
sg4
F0.8758330252540889
sa(dp523
g2
S"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."
p524
sg4
F0.8759558527608902
sa(dp525
g2
S"Yeah, this is pure crap. It doesn't even compile. ... Why the f*ck do you send me totally untested crap?"
p526
sg4
F0.8779530803153877
sa(dp527
g2
S'Quite frankly, I doubt that anybody will ever care, ... Plus quite frankly, signing random kernel vendor modules (indirectly) with a MS key is f*cking 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 f*cking 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.'
p528
sg4
F0.8786887559491157
sa(dp529
g2
S'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.'
p530
sg4
F0.8798260774329535
sa(dp531
g2
S"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."
p532
sg4
F0.8804025135480664
sa(dp533
g2
S'Hell no! Why do you send me this sh*t? 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 f*cked 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 F*CK 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.'
p534
sg4
F0.8811830076566898
sa(dp535
g2
S'F*ck 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.'
p536
sg4
F0.8813177197915513
sa(dp537
g2
S'...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.'
p538
sg4
F0.8832933435983175
sa(dp539
g2
S'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 f*cking 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....'
p540
sg4
F0.8836283239903309
sa(dp541
g2
S'Oh, *HELL*NO*! 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. F*ck me, but how I hate those random notifiers. And I hate people who add them willy nilly.'
p542
sg4
F0.8859424567555312
sa(dp543
g2
S"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."
p544
sg4
F0.8867316249675589
sa(dp545
g2
S'... 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.'
p546
sg4
F0.8869408108678131
sa(dp547
g2
S'Christ people. This is just sh*t.... 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 sh*t, 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 f*cking 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.'
p548
sg4
F0.8872516420525115
sa(dp549
g2
S'Ugh. But my patch was crap. It fixed up "arg", but it *should* have fixed up "cmd". Stupid.'
p550
sg4
F0.8893266304291456
sa(dp551
g2
S'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.'
p552
sg4
F0.8896352174304606
sa(dp553
g2
S'I hate this patch. Why? Because mindless checks like this would just lead to people making things worse and intermixing spaces there instead.'
p554
sg4
F0.8907875619705043
sa(dp555
g2
S'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 f*cking mindset. We don\'t accept *any* crap. Why are we still discussing this idiocy? It\'s irrelevant. ...'
p556
sg4
F0.8913690051586426
sa(dp557
g2
S'... 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. ...'
p558
sg4
F0.8925969672741785
sa(dp559
g2
S'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 f*ck is *wrong* with you people? Seriously?'
p560
sg4
F0.8942922536884803
sa(dp561
g2
S'This is not at all equivalent, and it looks stupid.'
p562
sg4
F0.8946708465438693
sa(dp563
g2
S"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?"
p564
sg4
F0.8949603331117116
sa(dp565
g2
S'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 *F*CKING*BROKEN*. ... 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.'
p566
sg4
F0.8950065498131429
sa(dp567
g2
S'Stop doing this f*cking 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 f*cking 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.'
p568
sg4
F0.8951546996599549
sa(dp569
g2
S'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 f*ck? ... and which is something we have actively *avoided* in the past, because back-off is a f*cking 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 f*cking thing looks incredibly broken. At least give some good explanations for why crap like this is needed ...'
p570
sg4
F0.8981712125398874
sa(dp571
g2
S"That patch is really ugly. And it doesn't make much sense. ... So the patch seems to make things just worse."
p572
sg4
F0.898389071886843
sa(dp573
g2
S"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_."
p574
sg4
F0.8985184859950796
sa(dp575
g2
S"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."
p576
sg4
F0.9013203432957358
sa(dp577
g2
S'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.'
p578
sg4
F0.9033555262260762
sa(dp579
g2
S"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?"
p580
sg4
F0.9036994927994524
sa(dp581
g2
S"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 f*^& 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?"
p582
sg4
F0.9041152483237724
sa(dp583
g2
S'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.'
p584
sg4
F0.9049216250896333
sa(dp585
g2
S"Ugh. The placement of that #ifndef is just horrible, please don't do that."
p586
sg4
F0.9056580732064586
sa(dp587
g2
S'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...'
p588
sg4
F0.9057126077012241
sa(dp589
g2
S'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 f*cking abomination, and says "somebody is doing something horribly wrong".'
p590
sg4
F0.9075231564837242
sa(dp591
g2
S'Ugh. Sorry, but this patch just looks stupid.'
p592
sg4
F0.9075714965032426
sa(dp593
g2
S"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 f*cking 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 ..."
p594
sg4
F0.9077818506306568
sa(dp595
g2
S'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. ...'
p596
sg4
F0.9097456950992109
sa(dp597
g2
S'Ugh, I personally hate it. ... Your suggested format just sucks, and has the worst of all worlds.'
p598
sg4
F0.911366092099658
sa(dp599
g2
S'I think this patch is horrible, and broken. And making the feature a config option is just stupid.'
p600
sg4
F0.9128586305498089
sa(dp601
g2
S"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."
p602
sg4
F0.9142368587967362
sa(dp603
g2
S'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.'
p604
sg4
F0.9146180484990465
sa(dp605
g2
S'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.'
p606
sg4
F0.9167109437957595
sa(dp607
g2
S'Ugh. No. That is too disgusting for words.'
p608
sg4
F0.9199559970474506
sa(dp609
g2
S'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.'
p610
sg4
F0.9204556652092494
sa(dp611
g2
S'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 f*cking 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 f*cking 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.'
p612
sg4
F0.9210425402099706
sa(dp613
g2
S"PLEASE NO! Dammit, why is this disease still so prevalent, and why do people continue to do this crap? __HAVE_ARCH_xyzzy is a f*cking retarded thing to do, and that's actually an insult to retarded people. ... The ... thing is a disease. ..."
p614
sg4
F0.922058179089756
sa(dp615
g2
S'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.'
p616
sg4
F0.9222085253557236
sa(dp617
g2
S'You need to also explain *why* people should apply it, and stop the f*cking 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 f*cking 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 f*cking 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.'
p618
sg4
F0.9239062843384185
sa(dp619
g2
S'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*.  ...'
p620
sg4
F0.9281930144523933
sa(dp621
g2
S"For a vmalloc() address, you'd have to actually walk the page tables. Which is a f*cking horrible idea. Don't do it. ... Where the hell does this crop up, and who does this insane thing anyway? It's wrong."
p622
sg4
F0.9334743027225808
sa(dp623
g2
S'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.'
p624
sg4
F0.9351505550163554
sa(dp625
g2
S'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.'
p626
sg4
F0.9545236048707093
sa.