Oh. THAT'S JUST INCOMPETENT. What the *fuck* is the point of having per-CPU data, and then using it for the wrong CPU? Stop doing that idiocy. Put the per-cpu data on the senders side, and stop the idiocy. You are going to get cross-CPU cacheline bouncing anyway, there's no way to avoid it, but as long as you do it on the wrong CPU's local data, you're missing the whole POINT of having per-cpu data in the first place.

Excuse me, but "some drivers" have no fucking business to mess with uid and gid assignments in the first place...

Yeah, Dan was also too lazy to explain the need, and had like 3 typoes in the inadequate changelog he had. He also fails to explain why he needs the timestamp twice, as do you for that matter. Does not inspire confidence. Now please all untwist your panties and try and submit a proper patch.

No, I don't want to know if this call site exists or not. This stupid "tracepoint_probe_register()" that activates a tracepoint by name. But if that tracepoint doesn't exist, it just returns normally as if everything is fine and dandy. WTF!

Anyway, to clarify: the printk's are harmless, since the IO past the end of the device is just error'ed out, and always has been. Which is why I was considering just removing them.

I don't know what to say about this one. -rc3 had fewer new commits than -rc4 does, and I don't like that trend. I'm not happy about the size of some of the changes (iscsi target, some other random drivers), but at the same time I have to say that absolutely nothing here makes me feel worried.

I sightly disagree with you. /dev/tty[1..64] is not directly bound to VT. You can have systems with CONFIG_VT=n and still have /dev/tty[1..64]. Linux supports this perfectly. UML does not have VT because having virtual consoles makes no sense. (Same like on s390)

[Recipient of email], Thanks so much for improving the REPORTING-BUGS file. With your changes it looks way better! - [Author of email]

That's really nasty; mntput_no_expire() (and thus mntput()) wants br_write_lock()/br_write_unlock(). Right now we *know* that mntput() is non-blocking in situations when we are holding more than one reference. With that kind of change that isn't true anymore - one needs to have long-term refs to make it safe. And that's not going to be fun to audit...

I *really* hate the timing of this. The code that is only impacted by BOOST I cannot find it in myself to care about, and I'd be willing to consider it basically EXPERIMENTAL and just pulling it.

I don't believe that it's right. Note that if you *do* race there, you are fucked regardless of sysctls - ppdev.c::register_device() racing with itself will do tons of fun things all by itself (starting with two threads allocating different pdev and both setting pp->pdev). IOW, *if* that's what we are hitting here, you've only papered over the visible symptom.

I *really* hate making br_write_lock() blocking and explicit get_online_cpus() around it isn't really any better. Too much PITA verifying correctness after the locking change.

In the last couple of days I _have_ merged 50+ trees, and while there's been some 'heated discussion' about some of them (you know who you are ;), I'm hoping that we're actually in reasonably good shape even though it's in the middle of the merge window, and that people will test out the snapshot kernels even though I'm not ready to do a -rc1 release.

So go out and test.

PS. And to get wider distribution for this message: Digg users - you're all a bunch of Wanking Walruses. And you can quote me on that.

1.5.4.2.316.gf7a7

2.34-stable review patch. If anyone has any objections, please let me know.

Congratulations!

Get your FREE* $1500 Pottery Barn Gift Card!

Please see here to claim your prize!

When he tells you "stop saying such idiocies, you're a f*cking moron", he doesn't really mean that, he means that he's very disappointed that *that person* says this or that, so he takes the time to say it to that person. The proof is that most often in the next mail he explains to the person how to do the thing right. He just tries to ensure that the person he's telling words to understands that he/she has crossed a line.

Sure it can be hard for newcomers but I don't remember having read him scold a newcomer. So that's probably not that much of a problem in the end, and helps getting the things done in time. I'm much more concerned by the "administrative" development mode that we're taking in fact and that some people seem to have expressed in this thread (what patch flow to follow, when to send/not to send, etc...).

I heard the word "benevolent dictator" in conjunction with [CC recipient], dunno, whether he said it or someone else said it or whatnot, but still: Is the kernel developer community a *military* organisation? Just wanted to raise awareness to this wording. As you pointed out repeatedly: Words make a difference. A huge one, I think.