# Author: Squire, M. & Gazda, R. # License: Open Database License 1.0 # This data 2014LTinsultsLKML.tsv.txt is made available under the # Open Database License: http://opendatacommons.org/licenses/odbl/1.0/. # Any rights in individual contents of the database are licensed under the # Database Contents License: http://opendatacommons.org/licenses/dbcl/1.0/ # # filename: 2014LTinsultsLKML.tsv.txt # explanation: # This data set is part of a larger group of data sets # described in the paper below, and hosted on the FLOSSmole.org site. # Contains insults gleaned from messages sent to the LKML mailing list by # Linus Torvalds during the year 2014 # # fields: # date: this is the date the original email was sent # markmail permalink: this is a permalink to the email on markmail (for easy reading) # type: this is our code for what type of insult this is # mail excerpt: this is the fragment of the email containing the insult(s). # Ellipses (...) have been added where necessary. # # Please cite the paper and FLOSSmole as follows: # # Citations: # Squire, M. & Gazda, R. (2015). FLOSS as a source for profanity # and insults: Collecting the data. In Proceedings of 48th # Hawai'i International Conference on System # Sciences (HICSS-48). IEEE. Hawaii, USA. 5290-5298. # # Howison, J., Conklin, M., & Crowston, K. (2006). FLOSSmole: A # collaborative repository for FLOSS research data and analyses. # International Journal of Information Technology and Web # Engineering, 1(3), 17–26. # date markmail permalink type(code, personal, both, unsure) mail excerpt 1/6/2014 21:25:34 http://markmail.org/message/n3enavikpanbpb2g C This looks completely broken to me. ... Wtf? Am I missing something? 1/9/2014 15:53:18 http://markmail.org/message/u7ygpolgnjcnea2t C Yeah, it's a hack, and it's wrong, and we should figure out how to do it right. 1/17/2014 17:28:49 http://markmail.org/message/tlfqf2fwnayq3rn6 C 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. 1/21/2014 10:11:14 http://markmail.org/message/qp4kumio6pxploxd B 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. 1/21/2014 17:50:47 http://markmail.org/message/5rpvx3sf2wcvzrf4 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... 1/21/2014 18:46:44 http://markmail.org/message/i32holblxwzsml7q B 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. 1/22/2014 10:23:43 http://markmail.org/message/f4xaietzxxp4sziz C 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. 1/26/2014 14:27:52 http://markmail.org/message/uk2l2qvdklmg57ok C 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*. 1/28/2014 9:12:21 http://markmail.org/message/lsyehokft5zpedb6 B 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. 1/28/2014 12:24:52 http://markmail.org/message/njkznzxzq4hstqfa P 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. 1/28/2014 18:44:08 http://markmail.org/message/tb6h6vhyia34gc2h B 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. 2/2/2014 11:27:59 http://markmail.org/message/t5yj7ynloclmysyc C 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. 2/4/2014 12:18:18 http://markmail.org/message/5eb6xkp3u47zmjrm C Oh, please, that's a British-level understatement. It's like calling WWII "a small bother". That's too ugly to live. 2/4/2014 19:37:20 http://markmail.org/message/txurofhjfbinempf C And that audit code really is aushit. I think I found a bug in it while just scanning it: 2/7/2014 12:18:12 http://markmail.org/message/g26urbel3sxbrsae U 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. 2/8/2014 11:45:29 http://markmail.org/message/qlbh3nkuj6wcfy5q C 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... 2/9/2014 16:56:01 http://markmail.org/message/jetbeut5u63i4hf7 C 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. 2/9/2014 17:23:51 http://markmail.org/message/meuw4jl5eg3vbbtv C 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 2/13/2014 16:37:30 http://markmail.org/message/csyqhyykuv25rgxf C 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. 2/14/2014 11:50:01 http://markmail.org/message/bdrn7aqw4anxhqly B 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. ... 2/15/2014 11:15:34 http://markmail.org/message/q3qh7x54i6fzv2ah B No, please don't use this idiotic example. It is wrong....Anybody who argues anything else is wrong, or confused, or confusing. 2/16/2014 16:40:43 http://markmail.org/message/s4u47op2ah7f7mtc P Please, Debabrata, humor me, and just try the patch. And try reading the source code. Because your statement is BS. 2/17/2014 14:32:21 http://markmail.org/message/sh5uyajmtzm3p7as P ...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? 2/17/2014 16:05:18 http://markmail.org/message/63723dupyjgixgs6 P This is why I don't like it when I see Torvald talk about "proving" things. It's bullshit. 2/24/2014 11:54:07 http://markmail.org/message/md3zdmynnpuqvd3w C 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. 2/24/2014 15:34:34 http://markmail.org/message/67i6f5byztnbdfjj B 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.... 3/4/2014 8:43:34 http://markmail.org/message/6xcimeubggrc363d P 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 ;) 3/7/2014 19:02:46 http://markmail.org/message/bsmzhq7ldv7rgxe6 B 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. 3/12/2014 7:41:03 http://markmail.org/message/65qp77rfafxmqxrd B 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. 3/27/2014 11:16:15 http://markmail.org/message/p2ngrbevkgkup6de B 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. ... 3/31/2014 14:45:09 http://markmail.org/message/nyz7qc2lmgz4ztsq C Ugh. I pulled it, but things like this makes me want to dig my eyes out with a spoon:... 3/31/2014 14:53:53 http://markmail.org/message/hireftpiggdgkakl B 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. 4/1/2014 8:13:07 http://markmail.org/message/xzlivxt33glabna3 C 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.... 4/1/2014 10:08:58 http://markmail.org/message/zw6pyzowimwxylmb B 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! 4/1/2014 10:31:08 http://markmail.org/message/47rd62pg2mj4dgzp B That's a cop-out. ... See? It's stupid. It's wrong. It's *bad*. 4/1/2014 19:42:45 http://markmail.org/message/ywyyge6s43xawbn4 C 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? 4/2/2014 11:57:06 http://markmail.org/message/qmqu3z753juxxhyl B 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. 4/2/2014 16:13:00 http://markmail.org/message/hbk3vkrbahxj4wc7 B 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. 4/4/2014 9:09:09 http://markmail.org/message/b3l4m5jhqykhtulg P 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? 4/8/2014 10:01:16 http://markmail.org/message/o5z7xz3q23u2da6n C 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. 5/1/2014 12:22:46 http://markmail.org/message/xzj3luansvzver5m C 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". 5/3/2014 16:56:58 http://markmail.org/message/zw27s5rfoxregfu7 B 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. 5/21/2014 16:30:08 http://markmail.org/message/4nhnvp7ya5es2cib B 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. 5/21/2014 16:34:25 http://markmail.org/message/xrsb4efvmzixi6ab B 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. 5/21/2014 17:03:09 http://markmail.org/message/klec5zn6viixojai C It appears Intel is fixing their braindamage 5/28/2014 15:40:47 http://markmail.org/message/7bca7xasxmpqxagw B Well, that's one way of reading that callchain. I think it's the *wrong* way of reading it, though. Almost dishonestly so. 5/28/2014 21:20:35 http://markmail.org/message/xkuhl256e3uytxzj C Hmm. Less vomit-inducing, except for this part:...Ugh, that just *screams* for a helper function. 5/30/2014 18:45:03 http://markmail.org/message/rod62fgtn6l2xiyu C 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. 6/2/2014 13:53:24 http://markmail.org/message/effszxesk5qqfxd7 B .. 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. 6/3/2014 8:32:27 http://markmail.org/message/f7s6iyrumarujhci C 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. 6/8/2014 10:44:50 http://markmail.org/message/fjue5oda5l62ibi6 C 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.... 6/30/2014 18:56:58 http://markmail.org/message/mwcxdtsoit6nbizu B 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. 6/30/2014 19:03:44 http://markmail.org/message/nzbxtpx73356mvs5 C 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 7/1/2014 15:41:13 http://markmail.org/message/bnikwotx5a37bj5d C 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. 7/3/2014 8:41:33 http://markmail.org/message/2pm5rp5i6psswlcp C 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()? 7/6/2014 12:24:19 http://markmail.org/message/3vt2j3z7xavnfauk C 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 ... 7/14/2014 9:23:53 http://markmail.org/message/iega33rufreijaqf B .. 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. 7/15/2014 8:41:14 http://markmail.org/message/fzsyv2ciryr5cp44 P Christoph, stop arguing. Trust me, Paul knows memory ordering. You clearly do *not*. 7/24/2014 11:46:52 http://markmail.org/message/z32zxqgilnvbemgk C 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. 8/24/2014 13:05:16 http://markmail.org/message/dnru3mlv2dlv2ub3 C 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. 9/7/2014 20:16:44 http://markmail.org/message/udtdgjmmkmiifj3s B 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. 9/24/2014 12:20:12 http://markmail.org/message/vixwv5cq4hz4qkdc C 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 9/26/2014 16:31:55 http://markmail.org/message/z6pfbvh7gipggqiz P 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. 9/27/2014 10:56:34 http://markmail.org/message/nrotmwwl5jfdelwr C 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) 9/29/2014 20:54:44 http://markmail.org/message/pbkr65jmmbzbhm5c C 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. 10/3/2014 11:23:30 http://markmail.org/message/aer4l3fouh4wnbak C 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. 10/3/2014 13:04:10 http://markmail.org/message/p3wgzdz5532wkpwk B Yeah, this is pure crap. It doesn't even compile. ... Why the f*ck do you send me totally untested crap? 10/3/2014 17:01:22 http://markmail.org/message/wd2lgohvpc2wu6ht C So adding the loop looks like just voodoo programming, not actually fixing anything. 10/3/2014 17:11:00 http://markmail.org/message/dskkjf5jifm4e374 C Actually, the real fix would be to not be stupid, and just make the code do something like ... 10/7/2014 9:55:55 http://markmail.org/message/vnz7zwwzidpgwxra B 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. ... 10/18/2014 8:35:18 http://markmail.org/message/seoesvnzd7fa2l6c C 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. 10/18/2014 11:38:05 http://markmail.org/message/7vtzcc2akcghwfzh B 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. 10/30/2014 17:58:57 http://markmail.org/message/v5hd5syd3ckqhh7t C 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. 11/6/2014 9:53:18 http://markmail.org/message/di6bkfqzpvk6t5mb C 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. 11/10/2014 10:09:36 http://markmail.org/message/ftuigcjfihdtvaob C Improve the debugger, don't make kernel code worse because your out-of-tree debugging infrastructure is too broken to live. 11/10/2014 12:21:39 http://markmail.org/message/mo6ksjo27cjmz3la B 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? ... 11/10/2014 19:15:40 http://markmail.org/message/c3zhc7ljokzeh4xh P WHAT? NONE OF WHAT YOU SAY MAKES ANY SENSE. 11/12/2014 12:35:52 http://markmail.org/message/w6unjtiro4puk6ci B 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. 11/19/2014 15:58:49 http://markmail.org/message/nqe2ghz6pltei4i3 U Andy, you need to lay off the drugs. 11/25/2014 17:47:43 http://markmail.org/message/z7yidblfn5owu2wn P 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... 12/8/2014 10:13:50 http://markmail.org/message/s7odimvx3jqkxxyq C 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. 12/8/2014 10:23:00 http://markmail.org/message/mtrpl4wpcq7rhvhi C 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" 12/13/2014 13:32:12 http://markmail.org/message/sqcaeqoeuqv3sbyr C 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. 12/15/2014 17:03:23 http://markmail.org/message/b73s2vropwkq7slv C .. 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 12/15/2014 18:15:20 http://markmail.org/message/np2j4f62v6wgrqil C 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. 12/19/2014 17:56:41 http://markmail.org/message/36knb5ckdqi6fyhd C 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.