AppSprout/Linus-Emails huggingface dataset:
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!
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.
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.
.. 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.
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?
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.
Sorry, you're wrong. And Rafael *told* you why you are wrong, and you ignored him and talked about "exec" some more. So go back and read Rafael's email. ... So please, read the emails. People actually *agree* that the name may be a bit misleading, but instead of harping on bogus issues, just read the emails from people like Rafael about it. So STOP with this idiocy already. ... Seriously. Get that through your head already.
So I have to say, I hate this entire series. ... So quite frankly, I think the whole series is total and utter garbage. And there isn't even any *explanation" for the garbage. You say that you are unifying things, but dammit, in order to unify them you end up *adding*new*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.
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.
... 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?
Your original email used "torv...@osdl.org", which goes into a kind-of-black hole. Please fix whatever crazy-old address book you have - that address is old, old, old. Oh, and your *new* email had totally broken email headers too. WTF? That ... is just pure and utter garbage. What the hell is wrong with your email setup? When I reply to that email, I sure as hell want to reply to *you*, not to *me*. So fix your email, right now it's terminally broken. Will look at the pull requests now that I actually see them, and when I'm over being upset by your idiotic email issues.
Finally, people - your merge messages suck. Leaving the list of conflicting files without talking about what the conflict actually was is *not* a good merge message. Len, you're not the only one that does this, but it is yet another reason why I absolutely detest some of the merges I see: they are just very uninformative, and don't add anything useful to the tree - quite the reverse. They hide a problem, without actually talking about what the problem was. ...And yes, sometimes my merge messages suck too (although I've tried very hard to become better at them).
Grr. Most of these patches have the same stupid problem: why the *hell* do you repeat the single-line top-level description in both the Subject line and the body of the email? It only results in stupid duplicate lines in the commit logs. This is a disease. I don't know who the heck started doing it, but it's WRONG. It's stupid. What broken piece-of-shit tool is it that does this braindamage? Fix it. Stop sending these broken commit messages to people. I'm grumpy, yes, because this is a common problem. I see it all over the place, and it makes our commit logs look f*cking retarded. ...
... Why has this been explicitly designed to be as ugly as humanly possible, and to be so inconvenient to parse too? ... So here's a serious suggestion: aim for "line oriented". ... ...That's stupid. Don't do it. ...Because this is just pure and utter *shit*: ...This part gets a big NAK from me. I don't see the point of this. It's pure crap. There's no advantage. And the "use an uint64_t" is a classic case of just being a 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*.
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.
Please don't continue to spread this total bogosity. ...That's a total idiotic lie by C++ apologists, and I hate hearing it repeated over and over again. And it really *is* a lie. ... Which is clearly insane, but is also technically simply *wrong*. ... Which is utter and complete bullshit, and any amount of brains would have realized that ... It has always been just nothing but a moronic hang-up, and it has always been *wrong*. So don't spread that lie. It was wrong. ... which is pure and utter garbage. And then they lie, and claim that their *weaker* type system NULL is "stronger". Pure idiocy.
...And a C++ person who says that "(vodi *)0" is just any "void *" is a *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.
...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.
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. ...
*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?
Absolutely. Anybody who does that is just terminally confused. "return()" is in no way a function. ... Here's an example of a really bad use of "sizeof" that doesn't have the parenthesis around the argument: sizeof(*p)->member. Quite frankly, if you do this, you should be shot. ... And let's face it: if you write your code so that it's easy to parse for a machine, and ignore how easy it is to parse for a human, I don't want you writing kernel code. ...
... However, please don't use the *INSANE* ARM "v8" naming. There must be something in the water in Cambridge, but the ARM "version" naming is just totally broken. ...maybe it all makes sense if you have drunk the ARM cool-aid and have joined the ARM cult, but to sane people and outsiders, it is just a 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.
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.
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.
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.
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.
Ingo, stop doing this kind of crap. ... You seem to be in total denial. ... Stop it. That kind of "head-in-the-sand" behavior is not conducive to good code, ... Seriously. If you can't make the non-THP case go faster, don't even bother sending out the patches. Similarly, if you cannot take performance results from others, don't even bother sending out the patches. ... So stop ignoring the feedback, and stop shooting the messenger. Look at the numbers, and admit that there is something that needs to be fixed.
Ingo, stop it already! This is *exactly* the kind of "blame everybody else than yourself" behavior that I was talking about earlier. ... Ingo, look your code in the mirror some day, and ask yourself: why do you think this fixes a "regression"? ...So by trying to make up for vsyscalls only in your numbers, you are basically trying to lie about regressions, and try to cover up the schednuma regression by fixing something else. ... See? That's bogus. When you now compare numbers, YOU ARE LYING. You have introduced a performance regression, and then trying to hide it by making something else go faster. ...The same is true of all your arguments about Mel's numbers wrt THP etc. Your arguments are misleading - either intentionally, of because you yourself didn't think things through. ...
Christ 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?
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....
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?
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...
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
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.
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.
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.
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 ...
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. ...
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.
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.
... 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.
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?
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.
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.
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ää just to express my disgust and frustration with this crap.
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.
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.
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.
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.
Dammit, this is pure shit, and after having to deal with yet another pointless merge conflict due to stupid "cleanups" in Makefiles, IT DOES NOT EVEN COMPILE. And no, that's not due to a merge error of mine. It was that way in your tree. Hulk angry. Hulk smash. I fixed it up in the merge, but I shouldn't need to. This should have been caught in -next, and even if you compile for ARM as your primary target, I know *damn* well that no sane ARM developer actually compiles *on* ARM (because there are no machines where it's worth the pain), so you should make sure that the x86-64 build works too. If I can find compile errors within a couple of minutes of pulling and it's not a merge error of mine, the tree I'm pulling from is clearly crap. So I'm more than a bit grumpy. Get your act together, and don't send me any more shit. In fact, I would suggest you send nothing but obvious fixes from now on in this release. Because I won't be taking anything else.
I don't think that works. That completely breaks randomize_stack_top(). So I'm not going to pull the parisc tree, this needs to be resolved sanely. In fact, I think that change to fs/exec.c is just completely broken:... and that "+1" just doesn't make sense, and fundamentally breaks STACK_RND_MASK. It also seems to be entirely pointless, ...So NAK on that whole fs/exec.c change. Afaik it's just wrong, and it's stupid.
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...
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.
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. ...
But your (and the current C standards) attempt to define this with some kind of syntactic dependency carrying chain will _inevitably_ get this wrong, and/or be too horribly complex to actually be useful. Seriously, don't do it. ... So just give it up. It's a fundamentally broken model. It's *wrong*, but even more importantly, it's not even *useful*, ...I really really really think you need to do this at a higher conceptual level, get away from all these idiotic "these operations maintain the chain" crap.
But that's *BS*. You didn't actually listen to the main issue. Paul, why do you insist on this carries-a-dependency crap? It's broken. ... The "carries a dependency" model is broken. Get over it.... I gave an alternate model (the "restrict"), and you didn't seem to understand the really fundamental difference. ... So please stop arguing against that. Whenever you argue against that simple fact, you are arguing against sane compilers....
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. ...
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!
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.
Why the heck are you making up ew and stupid event types? Now you make the generic VM code do stupid things like this:... which makes no sense at all. The names are some horrible abortion too ("RANDW"? That sounds like "random write" to me, not "read-and-write", which is commonly shortened RW or perhaps RDWR. Same foes for RONLY/WONLY - what kind of crazy names are those? But more importantly, afaik none of that is needed. Instead, tell us why you need particular flags, and don't make up crazy names like this. ...., so all those badly named states you've made up seem to be totally pointless. They add no actual information, but they *do* add crazy code like the above to generic code that doesn't even WANT any of this crap. ... So things like this need to be tightened up and made sane before any chance of merging it.
I'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.
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 ...
.. 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.
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.
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.
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)
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.
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? ...
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.
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.
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.
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*.  ...
... 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.
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.
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.
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_.
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.
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.