| Message ID | 1370764616.14883.28.camel@pasglop (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote: > > Here are a few more powerpc changes for 3.10. I've merged your > tree in at some point (which I generally avoid) in order to get > the compat network fixes as soon as possible. > > Mostly regressions, and stuff I judged could/should still go in at > this stage. Not pulled, because your hamster smells of eldeberries. This is not just bugfixes. In fact, as far as I can tell, this *introduces* bugs, with that "get_user()" in the exception path that can apparently happen with irqs disabled and will thus potentially result in new warnings that just make things unreadable. 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. Linus
[ Is Jeremy the patchwork maintainer? If not, can people forward this to the real maintainer? ] On Sun, Jun 9, 2013 at 2:33 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > This is not just bugfixes. In fact, as far as I can tell, this > *introduces* bugs, with that "get_user()" in the exception path that > can apparently happen with irqs disabled and will thus potentially > result in new warnings that just make things unreadable. Looking at that particular commit, I also notice that the commit itself is buggered in other ways too. It says: Date: Thu Jun 6 19:42:54 2013 +0000 which surprised me due to the odd timezone, and it turns out it is pure and utter crap. Google finds the patch in patchwork, and "Show headers" there shows the expected timezone Date: Fri, 7 Jun 2013 15:42:54 +1000 and it turns out that apparently 'patchwork' is just making up random times, because when you download the email as an mbox, it will turn this into that corrupt and incorrect Date: Thu, 06 Jun 2013 19:42:54 -0000 thing which is apparently how you got the wrong timestamp to begin with. That odd time doesn't even make any sense that I can see, because those two times have absolutely nothing in common afaik. Unless timezones work differently down under. It looks like some west-coast local time, but then it says "-0000" which is code for "I have no f*cking clue what I'm doing". Just to make things extra exciting, patchwork actually shows yet *another* date string when you just look at the patch in the web interface: Date June 7, 2013, 5:42 a.m. and that actually seems to be the *correct* UTC version of that original email date. I have no idea what that "Thu, 06 Jun 2013 19:42:54 -0000" date is, and where it came from. But it is utter shite. Can somebody please make sure that patchwork doesn't destroy timezone/date information? I'm assuming this has been going on forever, and I just noticed because I looked at that particular commit for other reasons, and went "Is Anton in Europe now?". Linus
On Sun, 2013-06-09 at 14:33 -0700, Linus Torvalds wrote: > On Sun, Jun 9, 2013 at 12:56 AM, Benjamin Herrenschmidt > <benh@kernel.crashing.org> wrote: > > > > Here are a few more powerpc changes for 3.10. I've merged your > > tree in at some point (which I generally avoid) in order to get > > the compat network fixes as soon as possible. > > > > Mostly regressions, and stuff I judged could/should still go in at > > this stage. > > Not pulled, because your hamster smells of eldeberries. > > This is not just bugfixes. In fact, as far as I can tell, this > *introduces* bugs, with that "get_user()" in the exception path that > can apparently happen with irqs disabled and will thus potentially > result in new warnings that just make things unreadable. Ah right, brown paper bag for Anton and I :( I shouldn't have put that one in, it was a last minute bad decision after spending time tracking another stupid sigill in userspace (this time FSL CPUs not implementing some optional instructions that Fedora compiler seems configured to generate nowadays). > 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. I've taken out that commit and the rename of the PMU interrupt (which while trivial probably wasn't important enough). Everything else is regressions/stable material. That does mean I rebased, but normally nobody bases on that merge branch so it should be fine. I'll send a new pull request. Cheers, Ben. > Linus > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
Hi Linus, > Is Jeremy the patchwork maintainer? Yep, that's me. > and it turns out that apparently 'patchwork' is just making up random > times, because when you download the email as an mbox, it will turn > this into that corrupt and incorrect > > Date: Thu, 06 Jun 2013 19:42:54 -0000 > > thing which is apparently how you got the wrong timestamp to begin with. We keep all patch dates in UTC, but were generating the Date header incorrectly. Now fixed: $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date Date: Fri, 07 Jun 2013 05:42:54 -0000 Commit is at: http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=e7353352 Cheers, Jeremy
On Sun, Jun 9, 2013 at 7:44 PM, Jeremy Kerr <jk@ozlabs.org> wrote: > > We keep all patch dates in UTC, but were generating the Date header > incorrectly. Now fixed: No, not fixed. Keeping patch dates in UTC *corrupts* the date. I'll ask people to stop using patchworks if it cannot keep track of emailed dates. The date very much is a local time WITH A TIMEZONE. And it does matter. > $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date > Date: Fri, 07 Jun 2013 05:42:54 -0000 No. The date from the email was Date: Fri, 7 Jun 2013 15:42:54 +1000 and we want *that* date. Not some random date that patchwork makes up that has no relevance. I know you have that date, because it shows up when asking for the headers in patchwork. Just use the right one, don't make up incorrect ones. Linus
On Sun, Jun 9, 2013 at 8:06 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > And it does matter. .. the rationale for this is that the work pattern of people is actually interesting information. You can do things like this: git log --pretty=%aD --author=Torvalds to see what my work pattern is, and I think that's *interesting*. Gathering statistics like whether people are generally doing 9-5 Mon-Fri is actually interesting data. You can do things like this: git log --since=6.months --pretty=%aD --author=Torvalds | cut -c1-3 | sort | uniq -c | sort -n and see (for example) that I do slow down on weekends. Same goes for things like what time of day ends up being most productive. You can do the statistics for me, and see that I tend to do the bulk of my pulls in the mornings (peak between 9-11) and that I'm not a night-owl (*big* drop-off after 8PM - that's what kids do to you). You can see a few really early-morning cases, but I suspect they were when I was jetlagged. So the date data is actually meaningful data. It's not just random noise. And to do these kinds of things, you absolutely have to have local-time with proper timezone information. Anything that screws that up is *broken*. git gets this right, unlike a lot of other broken SCM's. Git gets it right for a reason. Yeah, yeah, when people forward other peoples patches they often drop the date field, and the date of the patch ends up being the time that the last version of the patch got sent rather than anything else, so many of the statistics aren't valid. But a _tool_ that actively corrupts the date and time of a patch is just broken. Linus
On Sun, Jun 9, 2013 at 8:20 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > > .. the rationale for this is that the work pattern of people is > actually interesting information. You can do things like this: > > git log --pretty=%aD --author=Torvalds Final side note: for me, and other git users that apply other peoples patches, it's probably better to use git log --pretty=%cD --committer=Torvalds instead. Interestingly, that shows a different pattern than my "authorship" statistics, which are mainly pull requests. It turns out I commit patches much more in the afternoon. The reason is probably simple: in the mornings, I have pull requests waiting from overnight, so a fair number of pull requests where I am author at 9-11. But my biggest source of patches tends to be Andrew Morton, who sends the patches in the afternoon, so suddenly the commit counts skew towards being between 3pm-8pm when you take all my commits into accoint. Doing git log --since=6.months --pretty=%aD --grep=Signed.*Andrew.Morton backs that up: most of the commits that have sign-offs by Andrew are sent in the afternoon. I just find details like that really interesting, where you can actually mine for the workpatterns of people. Linus
Hi Linus, > No. The date from the email was > > Date: Fri, 7 Jun 2013 15:42:54 +1000 > > and we want *that* date. Ah, gotchya. So, we now use the original date header (if present) in the mbox views: $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date Date: Fri, 7 Jun 2013 15:42:54 +1000 ... for all your data-mining needs. Cheers, Jeremy
On Sun, Jun 9, 2013 at 9:20 PM, Jeremy Kerr <jk@ozlabs.org> wrote: > > So, we now use the original date header (if present) in the mbox views: > > $ wget -qO - http://patchwork.ozlabs.org/patch/249598/mbox/ | grep ^Date > Date: Fri, 7 Jun 2013 15:42:54 +1000 > > ... for all your data-mining needs. Goodie, and I see that it even works with old patches. Thanks. Linus
Hi Linus ! Here are a few more powerpc changes for 3.10. I've merged your tree in at some point (which I generally avoid) in order to get the compat network fixes as soon as possible. Mostly regressions, and stuff I judged could/should still go in at this stage. I'm still waiting on some more fixes to the signal handling vs. transactional memory (this is really ugly btw) which are hopefully coming next week. Cheers, Ben. The following changes since commit 1612e111e4e565422242727efb59499cce8738e4: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-06-06 18:09:05 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge for you to fetch changes up to 227331303afdca06e44dcda41d27b72015153827: powerpc: Print instruction when logging unhandled exceptions (2013-06-09 17:29:16 +1000) ---------------------------------------------------------------- Anton Blanchard (1): powerpc: Print instruction when logging unhandled exceptions Benjamin Herrenschmidt (1): Merge remote-tracking branch 'origin/master' into merge Gavin Shan (1): powerpc/eeh: Don't check RTAS token to get PE addr Kevin Hao (1): powerpc/pci: Check the bus address instead of resource address in pcibios_fixup_resources Michael Ellerman (3): powerpc: Rename PMU interrupts from CNT to PMI powerpc/perf: Fix deadlock caused by calling printk() in PMU exception powerpc: Partial revert of "Context switch more PMU related SPRs" Michael Neuling (4): powerpc/power8: Fix oprofile and perf powerpc/pseries: Simplify denormalization handler powerpc/power8: Update denormalization handler powerpc/hw_breakpoints: Add DABRX cpu feature to fix 32-bit regression arch/powerpc/include/asm/cputable.h | 17 +++-- arch/powerpc/kernel/cputable.c | 8 +-- arch/powerpc/kernel/entry_64.S | 28 -------- arch/powerpc/kernel/exceptions-64s.S | 90 ++++++++------------------ arch/powerpc/kernel/irq.c | 2 +- arch/powerpc/kernel/pci-common.c | 4 +- arch/powerpc/kernel/process.c | 3 +- arch/powerpc/kernel/traps.c | 11 +++- arch/powerpc/perf/core-book3s.c | 2 +- arch/powerpc/platforms/pseries/eeh_pseries.c | 12 ++-- 10 files changed, 60 insertions(+), 117 deletions(-)