Message ID | 20150323.125537.767987027704780801.davem@davemloft.net |
---|---|
State | Accepted |
Delegated to: | David Miller |
Headers | show |
On Mon, Mar 23, 2015 at 9:55 AM, David Miller <davem@davemloft.net> wrote: > > Some perf bug fixes from David Ahern, and the fix for that nasty > memmove() bug. That doesn't seem to be marked for stable? Or do you do the same thing as for networking, and just collect stable patches manually? Pulled, Linus -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Mar 23, 2015 at 10:05 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Mon, Mar 23, 2015 at 9:55 AM, David Miller <davem@davemloft.net> wrote: >> >> Some perf bug fixes from David Ahern, and the fix for that nasty >> memmove() bug. > > That doesn't seem to be marked for stable? Or do you do the same thing > as for networking, and just collect stable patches manually? Side note: the memmove commit message is a bit misleading. The old code handled zero-length calls fine, even if it wasn't explicit: it always called memmove() for that case. The condition "dst <= src || src + len <= dst" ends up being always true when len is zero (because it obviously ends up being "dst <= src || src <= dst"). So there was just one bug - the 64-byte overlap with the cacheline establish for the destination. Even that cacheline establish would have been ok if all the loads for the 64-byte block had been done up-front. Oh well. I'm actually somewhat surprised this didn't hit anything else. Doesn't networking also end up doing overlapping memmove() on the skb data occasionally? Linus -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon, 23 Mar 2015 10:05:10 -0700 > On Mon, Mar 23, 2015 at 9:55 AM, David Miller <davem@davemloft.net> wrote: >> >> Some perf bug fixes from David Ahern, and the fix for that nasty >> memmove() bug. > > That doesn't seem to be marked for stable? Or do you do the same thing > as for networking, and just collect stable patches manually? Yes, I do sparc stuff manually and queue it up at: http://patchwork.ozlabs.org/bundle/davem/stable/?state=* -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon, 23 Mar 2015 10:12:30 -0700 > Oh well. I'm actually somewhat surprised this didn't hit anything > else. Doesn't networking also end up doing overlapping memmove() on > the skb data occasionally? The only case I can think of is when {en,de}capsulating VLANs in software. But those are really small header sized copies, and would never trigger the unrolled loop which requires len >= 128. A quick grep shows something similar for wireless WEP/WPA, but not only are these small copies too but I don't have any wireless on any of my sparc boxes :-) It really is just SLAB/SLUB with large NR_CPU configurations. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html