- 26 Jan, 2012 3 commits
-
-
Ingo Molnar authored
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull in the latest perf/core improvements and fixes. Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
git://github.com/utrace/linuxIngo Molnar authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6Linus Torvalds authored
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: sha512 - reduce stack usage to safe number crypto: sha512 - make it work, undo percpu message schedule
-
- 25 Jan, 2012 26 commits
-
-
git://oss.sgi.com/xfs/xfsLinus Torvalds authored
Quoth Ben Myers: "Please pull in the following bugfix for xfs. We forgot to drop a lock on error in xfs_readlink. It hasn't been through -next yet, but there is no -next tree tomorrow. The fix is clear so I'm sending this request today." * 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: Fix missing xfs_iunlock() on error recovery path in xfs_readlink()
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/ttm: fix two regressions since move_notify changes drm/radeon: avoid deadlock if GPU lockup is detected in ib_pool_get drm/radeon: silence out possible lock dependency warning drm: Fix authentication kernel crash gma500: Fix shmem mapping drm/radeon/kms: refine TMDS dual link checks drm/radeon/kms: use drm_detect_hdmi_monitor for picking encoder mode drm/radeon/kms: rework modeset sequence for DCE41 and DCE5 drm/radeon/kms: move panel mode setup into encoder mode set drm/radeon/kms: move disp eng pll setup to init path drm/radeon: finish getting bios earlier drm/radeon: fix invalid memory access in radeon_atrm_get_bios() drm/radeon/kms: add some missing semaphore init drm/radeon/kms: Add an MSI quirk for Dell RS690 gpu, drm, sis: Don't return uninitialized variable from sis_driver_load()
-
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/soundLinus Torvalds authored
* 'fix/asoc' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ASoC: wm2000: Fix use-after-free - don't release_firmware() twice on error ASoC: wm8958: Use correct format string in dev_err() call ASoC: wm8996: Call _POST_PMU callback for CPVDD ASoC: mxs: Fix mxs-saif timeout ASoC: Disable register synchronisation for low frequency WM8996 SYSCLK ASoC: Don't go through cache when applying WM5100 rev A updates ASoC: Mark WM5100 register map cache only when going into BIAS_OFF ASoC: tlv320aic32x4: always enable analouge block ASoC: tlv320aic32x4: always enable dividers ASoC: sgtl5000: Fix wrong register name in restore
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmapLinus Torvalds authored
A fairly simple bugfix for a WARN_ON() which was triggered in the cache reset support as a result of some subsequent work. There's only one mainline user for the code path that's updated right now (wm8994) so should be low risk. * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: Reset cache status when reinitialsing the cache
-
Li Wang authored
The data encryption was moved from ecryptfs_write_end into ecryptfs_writepage, this patch moves the corresponding function comments to be consistent with the modification. Signed-off-by: Li Wang <liwang@nudt.edu.cn> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfsLinus Torvalds authored
Says Tyler: "Tim's logging message update will be really helpful to users when they're trying to locate a problematic file in the lower filesystem with filename encryption enabled. You'll recognize the fix from Li, as you commented on that. You should also be familiar with my setattr/truncate improvements, since you were the one that pointed them out to us (thanks again!). Andrew noted the /dev/ecryptfs write count sanitization needed to be improved, so I've got a fix in there for that along with some other less important cleanups of the /dev/ecryptfs read/write code." * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tyhicks/ecryptfs: eCryptfs: Fix oops when printing debug info in extent crypto functions eCryptfs: Remove unused ecryptfs_read() eCryptfs: Check inode changes in setattr eCryptfs: Make truncate path killable eCryptfs: Infinite loop due to overflow in ecryptfs_write() eCryptfs: Replace miscdev read/write magic numbers eCryptfs: Report errors in writes to /dev/ecryptfs eCryptfs: Sanitize write counts of /dev/ecryptfs ecryptfs: Remove unnecessary variable initialization ecryptfs: Improve metadata read failure logging MAINTAINERS: Update eCryptfs maintainer address
-
Tyler Hicks authored
If pages passed to the eCryptfs extent-based crypto functions are not mapped and the module parameter ecryptfs_verbosity=1 was specified at loading time, a NULL pointer dereference will occur. Note that this wouldn't happen on a production system, as you wouldn't pass ecryptfs_verbosity=1 on a production system. It leaks private information to the system logs and is for debugging only. The debugging info printed in these messages is no longer very useful and rather than doing a kmap() in these debugging paths, it will be better to simply remove the debugging paths completely. https://launchpad.net/bugs/913651Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Daniel DeFreez Cc: <stable@vger.kernel.org>
-
Tyler Hicks authored
ecryptfs_read() has been ifdef'ed out for years now and it was apparently unused before then. It is time to get rid of it for good. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Tyler Hicks authored
Most filesystems call inode_change_ok() very early in ->setattr(), but eCryptfs didn't call it at all. It allowed the lower filesystem to make the call in its ->setattr() function. Then, eCryptfs would copy the appropriate inode attributes from the lower inode to the eCryptfs inode. This patch changes that and actually calls inode_change_ok() on the eCryptfs inode, fairly early in ecryptfs_setattr(). Ideally, the call would happen earlier in ecryptfs_setattr(), but there are some possible inode initialization steps that must happen first. Since the call was already being made on the lower inode, the change in functionality should be minimal, except for the case of a file extending truncate call. In that case, inode_newsize_ok() was never being called on the eCryptfs inode. Rather than inode_newsize_ok() catching maximum file size errors early on, eCryptfs would encrypt zeroed pages and write them to the lower filesystem until the lower filesystem's write path caught the error in generic_write_checks(). This patch introduces a new function, called ecryptfs_inode_newsize_ok(), which checks if the new lower file size is within the appropriate limits when the truncate operation will be growing the lower file. In summary this change prevents eCryptfs truncate operations (and the resulting page encryptions), which would exceed the lower filesystem limits or FSIZE rlimits, from ever starting. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reviewed-by: Li Wang <liwang@nudt.edu.cn> Cc: <stable@vger.kernel.org>
-
Tyler Hicks authored
ecryptfs_write() handles the truncation of eCryptfs inodes. It grabs a page, zeroes out the appropriate portions, and then encrypts the page before writing it to the lower filesystem. It was unkillable and due to the lack of sparse file support could result in tying up a large portion of system resources, while encrypting pages of zeros, with no way for the truncate operation to be stopped from userspace. This patch adds the ability for ecryptfs_write() to detect a pending fatal signal and return as gracefully as possible. The intent is to leave the lower file in a useable state, while still allowing a user to break out of the encryption loop. If a pending fatal signal is detected, the eCryptfs inode size is updated to reflect the modified inode size and then -EINTR is returned. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Cc: <stable@vger.kernel.org>
-
Li Wang authored
ecryptfs_write() can enter an infinite loop when truncating a file to a size larger than 4G. This only happens on architectures where size_t is represented by 32 bits. This was caused by a size_t overflow due to it incorrectly being used to store the result of a calculation which uses potentially large values of type loff_t. [tyhicks@canonical.com: rewrite subject and commit message] Signed-off-by: Li Wang <liwang@nudt.edu.cn> Signed-off-by: Yunchuan Wen <wenyunchuan@kylinos.com.cn> Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Tyler Hicks authored
ecryptfs_miscdev_read() and ecryptfs_miscdev_write() contained many magic numbers for specifying packet header field sizes and offsets. This patch defines those values and replaces the magic values. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Tyler Hicks authored
Errors in writes to /dev/ecryptfs were being incorrectly reported by returning 0 or the value of the original write count. This patch clears up the return code assignment in error paths. Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Tyler Hicks authored
A malicious count value specified when writing to /dev/ecryptfs may result in a a very large kernel memory allocation. This patch peeks at the specified packet payload size, adds that to the size of the packet headers and compares the result with the write count value. The resulting maximum memory allocation size is approximately 532 bytes. Signed-off-by: Tyler Hicks <tyhicks@canonical.com> Reported-by: Sasha Levin <levinsasha928@gmail.com> Cc: <stable@vger.kernel.org>
-
Tim Gardner authored
Removes unneeded variable initialization in ecryptfs_read_metadata(). Also adds a small comment to help explain metadata reading logic. [tyhicks@canonical.com: Pulled out of for-stable patch and wrote commit msg] Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Tim Gardner authored
Print inode on metadata read failure. The only real way of dealing with metadata read failures is to delete the underlying file system file. Having the inode allows one to 'find . -inum INODE`. [tyhicks@canonical.com: Removed some minor not-for-stable parts] Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Dustin Kirkland authored
Update my email address in MAINTAINERS. Signed-off-by: Dustin Kirkland <dustin.kirkland@gazzang.com> Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
-
Ben Skeggs authored
Both changes in dc97b340 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo->mem is the old node, and new_mem is the new node. The above commit moves the call to move_notify() to after move() has been done, which means that now, sometimes, new_mem isn't the new node at all, bo->mem is, and new_mem points at a stale, possibly-just-been-killed-by-move node. This is clearly not a good situation. This patch reverts this change, and replaces it with a cleanup in the move() failure path instead. The second issue is that the call to move_notify() from cleanup_memtype_use() causes the TTM ghost objects to get passed into the driver. This is clearly bad as the driver knows nothing about these "fake" TTM BOs, and ends up accessing uninitialised memory. I worked around this in nouveau's move_notify() hook by ensuring the BO destructor was nouveau's. I don't particularly like this solution, and would rather TTM never pass the driver these objects. However, I don't clearly understand the reason why we're calling move_notify() here anyway and am happy to work around the problem in nouveau instead of breaking the behaviour expected by other drivers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Cc: Jerome Glisse <j.glisse@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jan Kara authored
Commit b52a360b forgot to call xfs_iunlock() when it detected corrupted symplink and bailed out. Fix it by jumping to 'out' instead of doing return. CC: stable@kernel.org CC: Carlos Maiolino <cmaiolino@redhat.com> Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Alex Elder <elder@kernel.org> Reviewed-by: Dave Chinner <dchinner@redhat.com> Signed-off-by: Ben Myers <bpm@sgi.com>
-
Jerome Glisse authored
If GPU lockup is detected in ib_pool get we are holding the ib_pool mutex that will be needed by the GPU reset code. As ib_pool code is safe to be reentrant from GPU reset code we should not block if we are trying to get the ib pool lock on the behalf of the same userspace caller, thus use the radeon_mutex_lock helper. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Jerome Glisse authored
Silence out the lock dependency warning by moving bo allocation out of ib mutex protected section. Might lead to useless temporary allocation but it's not harmful as such things only happen at initialization. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
-
Thomas Hellstrom authored
If the master tries to authenticate a client using drm_authmagic and that client has already closed its drm file descriptor, either wilfully or because it was terminated, the call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory and corrupt it. Typically this results in a hard system hang. This patch fixes that problem by removing any authentication tokens (struct drm_magic_entry) open for a file descriptor when that file descriptor is closed. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linuxLinus Torvalds authored
Quoth Len: "This fixes a merge-window regression due to a conflict between error injection and preparation to remove atomicio.c Here we fix that regression and complete the removal of atomicio.c. This also re-orders some idle initialization code to complete the merge window series that allows cpuidle to cope with bringing processors on-line after boot." * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux: Use acpi_os_map_memory() instead of ioremap() in einj driver ACPI, APEI, EINJ, cleanup 0 vs NULL confusion ACPI, APEI, EINJ Allow empty Trigger Error Action Table thermal: Rename generate_netlink_event ACPI / PM: Add Sony Vaio VPCCW29FX to nonvs blacklist. ACPI: Remove ./drivers/acpi/atomicio.[ch] ACPI, APEI: Add RAM mapping support to ACPI ACPI, APEI: Add 64-bit read/write support for APEI on i386 ACPI processor hotplug: Delay acpi_processor_start() call for hotplugged cores ACPI processor hotplug: Split up acpi_processor_add
-
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds authored
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: powerpc: Fix build on some non-freescale platforms powerpc/powernv: Fix PCI resource handling powerpc/crash: Fix build error without SMP powerpc/cpuidle: Make it a bool, not a tristate powerpc/85xx: Add dr_mode property in USB nodes powerpc/85xx: Enable USB2 controller node for P1020RDB powerpc/85xx: Fix cmd12 bug and add the chip compatible for eSDHC arch/powerpc/sysdev/fsl_pci.c: add missing iounmap powerpc: fix compile error with 85xx/p1022_ds.c
-
Benjamin Herrenschmidt authored
Commit 9deaa53a broke build on platforms that use legacy_serial.c without also having CONFIG_SERIAL_8250_FSL enabled due to an unconditional code to a routine in that module. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
Recent changes to the handling of PCI resources for host bridges are breaking the PowerNV code for assigning resources on IODA. The root of the problem is that the pci_bus attached to a host bridge no longer has its "legacy" resource pointers populated but only uses the newer list instead. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
- 24 Jan, 2012 11 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/netLinus Torvalds authored
Davem says: 1) Fix JIT code generation on x86-64 for divide by zero, from Eric Dumazet. 2) tg3 header length computation correction from Eric Dumazet. 3) More build and reference counting fixes for socket memory cgroup code from Glauber Costa. 4) module.h snuck back into a core header after all the hard work we did to remove that, from Paul Gortmaker and Jesper Dangaard Brouer. 5) Fix PHY naming regression and add some new PCI IDs in stmmac, from Alessandro Rubini. 6) Netlink message generation fix in new team driver, should only advertise the entries that changed during events, from Jiri Pirko. 7) SRIOV VF registration and unregistration fixes, and also add a missing PCI ID, from Roopa Prabhu. 8) Fix infinite loop in tx queue flush code of brcmsmac, from Stanislaw Gruszka. 9) ftgmac100/ftmac100 build fix, missing interrupt.h include. 10) Memory leak fix in net/hyperv do_set_mutlicast() handling, from Wei Yongjun. 11) Off by one fix in netem packet scheduler, from Vijay Subramanian. 12) TCP loss detection fix from Yuchung Cheng. 13) TCP reset packet MD5 calculation uses wrong address, fix from Shawn Lu. 14) skge carrier assertion and DMA mapping fixes from Stephen Hemminger. 15) Congestion recovery undo performed at the wrong spot in BIC and CUBIC congestion control modules, fix from Neal Cardwell. 16) Ethtool ETHTOOL_GSSET_INFO is unnecessarily restrictive, from Michał Mirosław. 17) Fix triggerable race in ipv6 sysctl handling, from Francesco Ruggeri. 18) Statistics bug fixes in mlx4 from Eugenia Emantayev. 19) rds locking bug fix during info dumps, from your's truly. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (67 commits) rds: Make rds_sock_lock BH rather than IRQ safe. netprio_cgroup.h: dont include module.h from other includes net: flow_dissector.c missing include linux/export.h team: send only changed options/ports via netlink net/hyperv: fix possible memory leak in do_set_multicast() drivers/net: dsa/mv88e6xxx.c files need linux/module.h stmmac: added PCI identifiers llc: Fix race condition in llc_ui_recvmsg stmmac: fix phy naming inconsistency dsa: Add reporting of silicon revision for Marvell 88E6123/88E6161/88E6165 switches. tg3: fix ipv6 header length computation skge: add byte queue limit support mv643xx_eth: Add Rx Discard and Rx Overrun statistics bnx2x: fix compilation error with SOE in fw_dump bnx2x: handle CHIP_REVISION during init_one bnx2x: allow user to change ring size in ISCSI SD mode bnx2x: fix Big-Endianess in ethtool -t bnx2x: fixed ethtool statistics for MF modes bnx2x: credit-leakage fixup on vlan_mac_del_all macvlan: fix a possible use after free ...
-
Christian Kujau authored
I could not find cpus_in_crash anywhere in the sourcetree, except for arch/powerpc/kernel/crash.c. Moving the definition into the CONFIG_SMP fixes it. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Deepthi Dharwar authored
As pointed out, asm/system.h has empty inline implementations for update_smt_snooze_delay and pseries_notify_cpuidle_add_cpu, which are used when CONFIG_PSERIES_IDLE is undefined. Since those two functions are used in core power architecture functions (store_smt_snooze_delay at kernel/sysfs.c and smp_xics_setup_cpu at platforms/pseries/smp.c), Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Benjamin Herrenschmidt authored
-
Stephane Eranian authored
The event_type record has a max length for the event name. It's called MAX_EVENT_NAME. The name may be truncated to fit the max length. But the header.size still reflects the original name length. If that length is > MAX_EVENT_NAME, then the header.size field is bogus. Fix this by using the length of the name after the potential truncation. Cc: David Ahern <dsahern@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20120120094912.GA4882@quadSigned-off-by: Stephane Eranian <eranian@google.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Srikar Dronamraju authored
Ingo pointed out few perf probe usability related errors during his review of uprobes. Since these issues are independent of uprobes, fixing them in a separate patch. Suggested-by: Ingo Molnar <mingo@elte.hu> Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com Cc: Ingo Molnar <mingo@elte.hu> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Link: http://lkml.kernel.org/r/20120120121354.GL15447@linux.vnet.ibm.comSigned-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
David Daney authored
When building on my Debian/mips system, util/util.c fails to build because commit 1aed2671 (perf kvm: Do guest-only counting by default) indirectly includes stdio.h before the feature selection in util.h is done. This prevents _GNU_SOURCE in util.h from enabling the declaration of getline(), from now second inclusion of stdio.h, and the build is broken. There is another breakage in util/evsel.c caused by include ordering, but I didn't fully track down the commit that caused it. The root cause of all this is an inconsistent definition of _GNU_SOURCE, so I move the definition into the Makefile so that it is passed to all invocations of the compiler and used uniformly for all system header files. All other #define and #undef of _GNU_SOURCE are removed as they cause conflicts with the definition passed to the compiler. All the features.h definitions (_LARGEFILE64_SOURCE _FILE_OFFSET_BITS=64 and _GNU_SOURCE) are needed by the python glue code too, so they are moved to BASIC_CFLAGS, and the misleading comments about BASIC_CFLAGS are removed. This gives me a clean build on x86_64 (fc12) and mips (Debian). Cc: David Daney <david.daney@cavium.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Joerg Roedel <joerg.roedel@amd.com> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1326836461-11952-1-git-send-email-ddaney.cavm@gmail.comSigned-off-by: David Daney <david.daney@cavium.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jan Beulich authored
"perf stat ... perf bench mem mem..." is pretty meaningless when using small block sizes (as the overhead of the invocation of each test run basically hides the actual test result in the noise). Repeating the actually interesting function's invocation a number of times allows the results to become meaningful. Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/4F16D767020000780006D738@nat28.tlf.novell.comSigned-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
Jan Beulich authored
This simply clones the respective memcpy() implementation. Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Link: http://lkml.kernel.org/r/4F16D743020000780006D735@nat28.tlf.novell.comSigned-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-
David S. Miller authored
rds_sock_info() triggers locking warnings because we try to perform a local_bh_enable() (via sock_i_ino()) while hardware interrupts are disabled (via taking rds_sock_lock). There is no reason for rds_sock_lock to be a hardware IRQ disabling lock, none of these access paths run in hardware interrupt context. Therefore making it a BH disabling lock is safe and sufficient to fix this bug. Reported-by: Kumar Sanghvi <kumaras@chelsio.com> Reported-by: Josh Boyer <jwboyer@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jan Beulich authored
Intended to be able to support the current selection of the preferred memcpy() implementation, this patch adds the ability to also measure the two alternative implementations, again by way of using some pre-processsor replacement. While on my Westmere system this proves that the movsb based variant is worse than the movsq based one (since the ERMS feature isn't there), it also shows that here for the default as well as small sizes the unrolled variant outperforms the movsq one. Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/4F16D728020000780006D732@nat28.tlf.novell.comSigned-off-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-