aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-01-06batman-adv: fix lock class for decoding hash in network-coding.cMartin Hundebøll1-1/+1
batadv_has_set_lock_class() is called with the wrong hash table as first argument (probably due to a copy-paste error), which leads to false positives when running with lockdep. Introduced-by: 612d2b4fe0a1ff2f8389462a6f8be34e54124c05 ("batman-adv: network coding - save overheard and tx packets for decoding") Signed-off-by: Martin Hundebøll <[email protected]> Signed-off-by: Marek Lindner <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]>
2015-01-06batman-adv: fix delayed foreign originator recognitionLinus Lüssing1-0/+1
Currently it can happen that the reception of an OGM from a new originator is not being accepted. More precisely it can happen that an originator struct gets allocated and initialized (batadv_orig_node_new()), even the TQ gets calculated and set correctly (batadv_iv_ogm_calc_tq()) but still the periodic orig_node purging thread will decide to delete it if it has a chance to jump between these two function calls. This is because batadv_orig_node_new() initializes the last_seen value to zero and its caller (batadv_iv_ogm_orig_get()) makes it visible to other threads by adding it to the hash table already. batadv_iv_ogm_calc_tq() will set the last_seen variable to the correct, current time a few lines later but if the purging thread jumps in between that it will think that the orig_node timed out and will wrongly schedule it for deletion already. If the purging interval is the same as the originator interval (which is the default: 1 second), then this game can continue for several rounds until the random OGM jitter added enough difference between these two (in tests, two to about four rounds seemed common). Fixing this by initializing the last_seen variable of an orig_node to the current time before adding it to the hash table. Signed-off-by: Linus Lüssing <[email protected]> Signed-off-by: Marek Lindner <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]>
2015-01-06batman-adv: fix and simplify condition when bonding should be usedSimon Wunderlich1-2/+4
The current condition actually does NOT consider bonding when the interface the packet came in from is the soft interface, which is the opposite of what it should do (and the comment describes). Fix that and slightly simplify the condition. Reported-by: Ray Gibson <[email protected]> Signed-off-by: Simon Wunderlich <[email protected]> Signed-off-by: Marek Lindner <[email protected]> Signed-off-by: Antonio Quartulli <[email protected]>
2015-01-05Linux 3.19-rc3Linus Torvalds1-1/+1
2015-01-06int340x_thermal/processor_thermal_device: return failure whenZhang Rui1-0/+2
there is no ACPI device object processor_thermal_device driver needs ACPI support to work. Thus, the driver probing should fail when there is no ACPI device object asscociated. This fixes a NULL pointer dereference when the driver is loaded with INT340X feature disabled in BIOS. Reported-by: Chen Yu <[email protected]> Signed-off-by: Zhang Rui <[email protected]> Tested-by: Chen Yu <[email protected]>
2015-01-06ACPI/int340x_thermal: enumerate INT3401 for Intel SoC DTS thermal driverZhang Rui1-1/+6
Intel SoC DTS thermal driver on Baytrail platform uses IRQ 86 for critical overheating notification. But this IRQ 86 is described in the _CRS control method of INT3401 device, thus we should enumerate INT3401 to set the IRQ descriptor when Intel SoC DTS thermal driver is built. Signed-off-by: Zhang Rui <[email protected]> Tested-by: Srinivas Pandruvada <[email protected]>
2015-01-06ACPI/int340x_thermal: enumerate INT340X devices even if they're not in _ART/_TRTZhang Rui2-16/+6
For some INT340X thermal devices, even if they are not referred in _TRT/_ART table, they still can be used by userspace for thermal control. Thus change the code to enumerated all the INT340X devices, no matter if they're referred in _TRT/_ART or not. Signed-off-by: Zhang Rui <[email protected]> Tested-by: Srinivas Pandruvada <[email protected]>
2015-01-05Merge tag 'powerpc-3.19-3' of ↵Linus Torvalds7-11/+22
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux Pull powerpc fixes from Michael Ellerman: - Wire up sys_execveat(). Tested on 32 & 64 bit. - Fix for kdump on LE systems with cpus hot unplugged. - Revert Anton's fix for "kernel BUG at kernel/smpboot.c:134!", this broke other platforms, we'll do a proper fix for 3.20. * tag 'powerpc-3.19-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux: Revert "powerpc: Secondary CPUs must set cpu_callin_map after setting active and online" powerpc/kdump: Ignore failure in enabling big endian exception during crash powerpc: Wire up sys_execveat() syscall
2015-01-05ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu()Hanjun Guo4-15/+13
acpi_map_lsapic() will allocate a logical CPU number and map it to physical CPU id (such as APIC id) for the hot-added CPU, it will also do some mapping for NUMA node id and etc, acpi_unmap_lsapic() will do the reverse. We can see that the name of the function is a little bit confusing and arch (IA64) dependent so rename them as acpi_(un)map_cpu() to make arch agnostic and explicit. Signed-off-by: Hanjun Guo <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-01-05ACPI / processor: Convert apic_id to phys_id to make it arch agnosticHanjun Guo3-41/+44
apic_id in MADT table is the CPU hardware id which identify it self in the system for x86 and ia64, OSPM will use it for SMP init to map APIC ID to logical cpu number in the early boot, when the DSDT/SSDT (ACPI namespace) is scanned later, the ACPI processor driver is probed and the driver will use acpi_id in DSDT to get the apic_id, then map to the logical cpu number which is needed by the processor driver. Before ACPI 5.0, only x86 and ia64 were supported in ACPI spec, so apic_id is used both in arch code and ACPI core which is pretty fine. Since ACPI 5.0, ARM is supported by ACPI and APIC is not available on ARM, this will confuse people when apic_id is both used by x86 and ARM in one function. So convert apic_id to phys_id (which is the original meaning) in ACPI processor dirver to make it arch agnostic, but leave the arch dependent code unchanged, no functional change. Signed-off-by: Hanjun Guo <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2015-01-05Merge tag 'please-pull-syscall' of ↵Linus Torvalds3-1/+3
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux Pull ia64 fixlet from Tony Luck: "Add execveat syscall" * tag 'please-pull-syscall' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux: [IA64] Enable execveat syscall for ia64
2015-01-05ACPI / PM: Fix PM initialization for devices that are not presentRafael J. Wysocki2-6/+9
If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by: Rafael J. Wysocki <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Cc: 3.10+ <[email protected]> # 3.10+
2015-01-05[IA64] Enable execveat syscall for ia64Tony Luck3-1/+3
See commit 51f39a1f0cea1cacf8c787f652f26dfee9611874 syscalls: implement execveat() system call Signed-off-by: Tony Luck <[email protected]>
2015-01-05qla2xxx: fix busy wait regressionBruno Prémont1-1/+3
Commit e05fe29248 (qla2xxx: Honor FCP_RSP retry delay timer field.) causes systems to busy-wait for about 3 minutes after boot prior to detecting SAN disks. During this wait period one kworker is running full-time (though /proc/<pid>/stack has no useful data). Another kworker is waiting for IO to complete during that whole time period. Looking at drivers/scsi/qla2xxx/qla_os.c, fcport->retry_delay_timestamp has a special value of 0 though that 0 value forces system to wait when jiffies is very large value (e.g. 4294952605 - "negative" value when signed on 32bit systems). Signed-off-by: Bruno Prémont <[email protected]> Acked-by: Chad Dupuis <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]>
2015-01-05drm/radeon: integer underflow in radeon_cp_dispatch_texture()Dan Carpenter1-1/+1
The test: if (size > RADEON_MAX_TEXTURE_SIZE) { "size" is an integer and it's controled by the user so it can be negative and the test can underflow. Later we use "size" in: dwords = size / 4; ... RADEON_COPY_MT(buffer, data, (int)(dwords * sizeof(u32))); It causes memory corruption to copy a negative size buffer. Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-01-05drm/radeon: adjust default bapm settings for KVAlex Deucher1-6/+4
Enabling bapm seems to cause clocking problems on some KV configurations. Disable it by default for now. Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-01-05drm/radeon: properly filter DP1.2 4k modes on non-DP1.2 hwAlex Deucher1-0/+4
The check was already in place in the dp mode_valid check, but radeon_dp_get_dp_link_clock() never returned the high clock mode_valid was checking for because that function clipped the clock based on the hw capabilities. Add an explicit check in the mode_valid function. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87172 Signed-off-by: Alex Deucher <[email protected]> Cc:[email protected]
2015-01-05drm/radeon: fix sad_count check for dce3Alex Deucher1-1/+1
Make it consistent with the sad code for other asics to deal with monitors that don't report sads. bug: https://bugzilla.kernel.org/show_bug.cgi?id=89461 Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-01-05drm/radeon: KV has three PPLLs (v2)Alex Deucher1-4/+4
Enable all three in the driver. Early documentation indicated the 3rd one was used for something else, but that is not the case. v2: handle disable as well Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-01-05KEYS: close race between key lookup and freeingSasha Levin1-2/+2
When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Signed-off-by: Sasha Levin <[email protected]> Signed-off-by: David Howells <[email protected]>
2015-01-05drm/amdkfd: unmap VMID<-->PASID when relesing VMID (non-HWS)Ben Goz1-0/+3
This patch fixes a bug where deallocate_vmid() didn't actually unmap the VMID<-->PASID mapping (in the registers). That can cause undefined behavior. This bug only occurs in non-HWS mode. Signed-off-by: Ben Goz <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Acked-by: Alex Deucher <[email protected]>
2015-01-05ALSA: hda - Fix wrong gpio_dir & gpio_mask hint setups for IDT/STAC codecsTakashi Iwai1-2/+2
stac_store_hints() does utterly wrong for masking the values for gpio_dir and gpio_data, likely due to copy&paste errors. Fortunately, this feature is used very rarely, so the impact must be really small. Reported-by: Rasmus Villemoes <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-01-05iommu/rockchip: Drop owner assignment from platform_driversWolfram Sang1-1/+0
This platform_driver does not need to set an owner, it will be populated by the driver core. Signed-off-by: Wolfram Sang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2015-01-05iommu/vt-d: Remove dead code in device_notifierJoerg Roedel1-8/+0
This code only runs when action == BUS_NOTIFY_REMOVED_DEVICE, so it can't be BUS_NOTIFY_DEL_DEVICE. Signed-off-by: Joerg Roedel <[email protected]>
2015-01-05iommu/vt-d: Fix dmar_domain leak in iommu_attach_deviceJoerg Roedel1-0/+4
Since commit 1196c2f a domain is only destroyed in the notifier path if it is hot-unplugged. This caused a domain leakage in iommu_attach_device when a driver was unbound from the device and bound to VFIO. In this case the device is attached to a new domain and unlinked from the old domain. At this point nothing points to the old domain anymore and its memory is leaked. Fix this by explicitly freeing the old domain in iommu_attach_domain. Fixes: 1196c2f (iommu/vt-d: Fix dmar_domain leak in iommu_attach_device) Cc: [email protected] # v3.18 Tested-by: Jerry Hoemann <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2015-01-05iommu/ipmmu-vmsa: Change IOMMU_EXEC to IOMMU_NOEXECLaurent Pinchart1-3/+3
Commit a720b41c41f5a7e4 ("iommu/arm-smmu: change IOMMU_EXEC to IOMMU_NOEXEC") has inverted and replaced the IOMMU_EXEC flag with IOMMU_NOEXEC. Update the driver accordingly. Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Joerg Roedel <[email protected]>
2015-01-05crypto: sha-mb - Add avx2_supported check.Vinson Lee1-1/+1
This patch fixes this allyesconfig target build error with older binutils. LD arch/x86/crypto/built-in.o ld: arch/x86/crypto/sha-mb/built-in.o: No such file: No such file or directory Cc: [email protected] # 3.18+ Signed-off-by: Vinson Lee <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2015-01-05crypto: aesni - fix "by8" variant for 128 bit keysMathias Krause1-11/+35
The "by8" counter mode optimization is broken for 128 bit keys with input data longer than 128 bytes. It uses the wrong key material for en- and decryption. The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved in case we're handling more than 128 bytes of input data -- they won't get reloaded after the initial load. They must therefore be (a) loaded on the first iteration and (b) be preserved for the latter ones. The implementation for 128 bit keys does not comply with (a) nor (b). Fix this by bringing the implementation back to its original source and correctly load the key registers and preserve their values by *not* re-using the registers for other purposes. Kudos to James for reporting the issue and providing a test case showing the discrepancies. Reported-by: James Yonan <[email protected]> Cc: Chandramouli Narayanan <[email protected]> Cc: <[email protected]> # v3.18 Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2015-01-05Merge tag 'iwlwifi-for-kalle-2015-01-05' of ↵Kalle Valo8-13/+34
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes * fix for 7265D NVM check * fixes for scan: fix long scanning times and network discovery * new firmware API for iwlmvm supported devices * fixes in rate control
2015-01-05Revert "mac80211: Fix accounting of the tailroom-needed counter"Johannes Berg2-8/+11
This reverts commit ca34e3b5c808385b175650605faa29e71e91991b. It turns out that the p54 and cw2100 drivers assume that there's tailroom even when they don't say they really need it. However, there's currently no way for them to explicitly say they do need it, so for now revert this. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=90331. Cc: [email protected] Fixes: ca34e3b5c808 ("mac80211: Fix accounting of the tailroom-needed counter") Reported-by: Christopher Chavez <[email protected]> Bisected-by: Larry Finger <[email protected]> Debugged-by: Christian Lamparter <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2015-01-05iwlwifi: bump firmware API for mvm devices to 12Emmanuel Grumbach2-3/+3
This allows 3160 / 7260 / 7265 / 7265D / 8000 devices to use the latest version of the firmware. Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05iwlwifi: mvm: scan dwell time correctionsDavid Spinadel2-5/+16
Use only basic dwell time (10 ms for active scan and 110 for passive), regardless of the number of the probes and the band, if it is supported by the FW. The FW will add 3 ms for each probe sent and 10 ms for low band channels. Add a TLV flag to indicate such support in FW. This fix is needed to fix few bugs regarding scans that take too much time. Signed-off-by: David Spinadel <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05iwlwifi: mvm: add a flag to enable match found notificationDavid Spinadel2-0/+4
Add a flag that enables match found notification to align with FW API change. Cc: <[email protected]> [3.17+] Signed-off-by: David Spinadel <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05iwlwifi: mvm: fix out of bounds access to tid_to_mac80211_acEyal Shapira1-2/+6
When tid_tspec was set to IWL_TID_NON_QOS (8) this led to an out of bounds access to the tid_to_mac80211_ac array whose size is 7. Fix this. Signed-off-by: Eyal Shapira <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05iwlwifi: mvm: fix Rx with both chainsEyal Shapira1-1/+1
commit 5c90422439d6 "iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it" broke Rx with 2 chains for diversity. This had an impact on throughput where we're using only a single stream (11a/b/g APs, single stream APs, static SMPS). Fixes: 5c90422439d6 ("iwlwifi: mvm: don't allow diversity if BT Coex / TT forbid it") Cc: Stable <[email protected]> [3.16+] Signed-off-by: Eyal Shapira <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05iwlwifi: 7000: fix reported firmware name for 7265DEmmanuel Grumbach1-1/+1
We were advertising iwlwifi-7265-X.ucode instead of iwlwifi-7265D-X.ucode. Fix this. Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05iwlwifi: pcie: correctly define 7265-D cfgArik Nemtsov1-1/+3
The trans cfg was not replaced for 7265-D cards. This led to a check of the min-NVM version against a 7265-C card, causing very-old 7265-D cards to operate incorrectly with the driver. Fixes: 3fd0d3c170ad ("iwlwifi: pcie: support 7265-D devices") Signed-off-by: Arik Nemtsov <[email protected]> Signed-off-by: Emmanuel Grumbach <[email protected]>
2015-01-05rtlwifi: Fix error when accessing unmapped memory in skbLarry Finger1-8/+24
These drivers use 9100-byte receive buffers, thus allocating an skb requires an O(3) memory allocation. Under heavy memory loads and fragmentation, such a request can fail. Previous versions of the driver have dropped the packet and reused the old buffer; however, the new version introduced a bug in that it released the old buffer before trying to allocate a new one. The previous method is implemented here. The skb is unmapped before any attempt is made to allocate another. Signed-off-by: Larry Finger <[email protected]> Cc: Stable <[email protected]> [v3.18] Reported-by: Eric Biggers <[email protected]> Cc: Eric Biggers <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2015-01-05ALSA: snd-usb-caiaq: fix stream count checkDaniel Mack1-1/+1
Commit 897c329bc ("ALSA: usb: caiaq: check for cdev->n_streams > 1") introduced a safety check to protect against bogus data provided by devices. However, the n_streams variable is already divided by CHANNELS_PER_STREAM, so the correct check is 'n_streams > 0'. Fix this to un-break support for stereo devices. Signed-off-by: Daniel Mack <[email protected]> Cc: [email protected] [v3.18+] Signed-off-by: Takashi Iwai <[email protected]>
2015-01-04net: ethernet: cpsw: fix hangs with interruptsFelipe Balbi1-11/+8
The CPSW IP implements pulse-signaled interrupts. Due to that we must write a correct, pre-defined value to the CPDMA_MACEOIVECTOR register so the controller generates a pulse on the correct IRQ line to signal the End Of Interrupt. The way the driver is written today, all four IRQ lines are requested using the same IRQ handler and, because of that, we could fall into situations where a TX IRQ fires but we tell the controller that we ended an RX IRQ (or vice-versa). This situation triggers an IRQ storm on the reserved IRQ 127 of INTC which will in turn call ack_bad_irq() which will, then, print a ton of: unexpected IRQ trap at vector 00 In order to fix the problem, we are moving all calls to cpdma_ctlr_eoi() inside the IRQ handler and making sure we *always* write the correct value to the CPDMA_MACEOIVECTOR register. Note that the algorithm assumes that IRQ numbers and value-to-be-written-to-EOI are proportional, meaning that a write of value 0 would trigger an EOI pulse for the RX_THRESHOLD Interrupt and that's the IRQ number sitting in the 0-th index of our irqs_table array. This, however, is safe at least for current implementations of CPSW so we will refrain from making the check smarter (and, as a side-effect, slower) until we actually have a platform where IRQ lines are swapped. This patch has been tested for several days with AM335x- and AM437x-based platforms. AM57x was left out because there are still pending patches to enable ethernet in mainline for that platform. A read of the TRM confirms the statement on previous paragraph. Reported-by: Yegor Yefremov <[email protected]> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly) Cc: <[email protected]> # v3.9+ Signed-off-by: Felipe Balbi <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-04Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/umlLinus Torvalds3-2/+3
Pull UML fixes from Richard Weinberger: "Two fixes for UML regressions. Nothing exciting" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml: x86, um: actually mark system call tables readonly um: Skip futex_atomic_cmpxchg_inatomic() test
2015-01-04Revert "ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo"Pavel Machek2-0/+21
Commit 9fc2105aeaaf ("ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo") breaks audio in python, and probably elsewhere, with message FATAL: cannot locate cpu MHz in /proc/cpuinfo I'm not the first one to hit it, see for example https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/ https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1 Reading original changelog, I have to say "Stop breaking working setups. You know who you are!". Signed-off-by: Pavel Machek <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2015-01-04x86, um: actually mark system call tables readonlyDaniel Borkmann2-2/+2
Commit a074335a370e ("x86, um: Mark system call tables readonly") was supposed to mark the sys_call_table in UML as RO by adding the const, but it doesn't have the desired effect as it's nevertheless being placed into the data section since __cacheline_aligned enforces sys_call_table being placed into .data..cacheline_aligned instead. We need to use the ____cacheline_aligned version instead to fix this issue. Before: $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table" U sys_writev 0000000000000000 D sys_call_table 0000000000000000 D syscall_table_size After: $ nm -v arch/x86/um/sys_call_table_64.o | grep -1 "sys_call_table" U sys_writev 0000000000000000 R sys_call_table 0000000000000000 D syscall_table_size Fixes: a074335a370e ("x86, um: Mark system call tables readonly") Cc: H. Peter Anvin <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Signed-off-by: Richard Weinberger <[email protected]>
2015-01-04um: Skip futex_atomic_cmpxchg_inatomic() testRichard Weinberger1-0/+1
futex_atomic_cmpxchg_inatomic() does not work on UML because it triggers a copy_from_user() in kernel context. On UML copy_from_user() can only be used if the kernel was called by a real user space process such that UML can use ptrace() to fetch the value. Reported-by: Miklos Szeredi <[email protected]> Suggested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Tested-by: Daniel Walter <[email protected]>
2015-01-04Merge tag 'amdkfd-fixes-2014-12-30' of ↵Dave Airlie7-8/+30
git://people.freedesktop.org/~gabbayo/linux into linus Highlights: - Link order changes in drm/Makefile and drivers/Makefile to fix issue when amdkfd, radeon and amd_iommu_v2 are compiled inside the kernel image. - Consider kernel configuration (using #IFDEFs) when radeon initializes amdkfd, due to a specific configuration that makes symbol_request() return a non-NULL value when a symbol doesn't exists. Rusty Russel is helping me to find the root cause, but it may take a while because of year-end so I'm sending this as a band-aid solution. * tag 'amdkfd-fixes-2014-12-30' of git://people.freedesktop.org/~gabbayo/linux: drm/radeon: Init amdkfd only if it was compiled amdkfd: actually allocate longs for the pasid bitmask drm: Put amdkfd before radeon in drm Makefile drivers: Move iommu/ before gpu/ in Makefile amdkfd: Remove duplicate include amdkfd: Fixing topology bug in building sysfs nodes amdkfd: Fix accounting of device queues
2015-01-04Merge tag 'drm-intel-next-fixes-2014-12-30' of ↵Dave Airlie5-41/+10
git://anongit.freedesktop.org/drm-intel into linus I've had these since before -rc1, but they missed my last pull request. Real bug fixes and mostly cc: stable material. * tag 'drm-intel-next-fixes-2014-12-30' of git://anongit.freedesktop.org/drm-intel: drm/i915: add missing rpm ref to i915_gem_pwrite_ioctl Revert "drm/i915: Preserve VGACNTR bits from the BIOS" drm/i915: Don't call intel_prepare_page_flip() multiple times on gen2-4 drm/i915: Kill check_power_well() calls
2015-01-02perf diff: Fix to sort by baseline field by defaultNamhyung Kim1-0/+44
The currently perf diff didn't add the baseline and delta (or other compute) fields to the sort list so output will be sorted by other fields like alphabetical order of DSO or symbol as below example. Fix it by adding hpp formats for the fields and provides default compare functions. Before: $ perf diff # Event 'cycles' # # Baseline Delta Shared Object Symbol # ........ ....... .................. ............................... # [bridge] [k] ip_sabotage_in [btrfs] [k] __etree_search.constprop.47 0.01% [btrfs] [k] btrfs_file_mmap 0.01% -0.01% [btrfs] [k] btrfs_getattr [e1000e] [k] e1000_watchdog 0.00% [kernel.vmlinux] [k] PageHuge 0.00% [kernel.vmlinux] [k] __acct_update_integrals 0.00% [kernel.vmlinux] [k] __activate_page [kernel.vmlinux] [k] __alloc_fd 0.02% +0.02% [kernel.vmlinux] [k] __alloc_pages_nodemask ... After: # Baseline Delta Shared Object Symbol # ........ ....... .................. ................................ # 24.73% -4.62% perf [.] append_chain_children 7.96% -1.29% perf [.] dso__find_symbol 6.97% -2.07% libc-2.20.so [.] vfprintf 4.61% +0.88% libc-2.20.so [.] __fprintf_chk 4.41% +2.43% perf [.] sort__comm_cmp 4.10% -0.16% perf [.] comm__str 4.03% -0.93% perf [.] machine__findnew_thread_time 3.82% +3.09% perf [.] __hists__add_entry 2.95% -0.18% perf [.] sort__dso_cmp ... Signed-off-by: Namhyung Kim <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-01-02perf list: Fix --raw-dump optionTaesoo Kim1-3/+10
Currently, 'perf list --raw-dump' requires extra arguments (e.g., hw) to invoke, which breaks bash/zsh completion (perf-completion.sh). $ perf list --raw-dump Error: unknown option `raw-dump' usage: perf list [hw|sw|cache|tracepoint|pmu|event_glob] After, $ perf list --raw-dump cpu-cycles instructions cache-references cache-misses ... Signed-off-by: Taesoo Kim <[email protected]> Acked-by: Namhyung Kim <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Taesoo kim <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2015-01-02enic: free all rq buffs when allocation failsGovindarajulu Varadarajan1-2/+4
When allocation of all RQs fail, we do not free previously allocated buffers, before returning error. This causes memory leak. This patch fixes this by calling vnic_rq_clean(), which frees all the rq buffers. Signed-off-by: Govindarajulu Varadarajan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-01-02qmi_wwan: Set random MAC on devices with buggy fwKristian Evensen1-3/+7
Some buggy firmwares export an incorrect MAC address (00:a0:c6:00:00:00). This makes for example checking devices for random MAC addresses tricky, and you might end up with multiple network interfaces with the same address. This patch tries to fix, or at least improve, the situation by setting the MAC address of devices with this firmware bug to a random address. I tested the patch with two devices that has this firmware bug (Huawei E398 and E392), and network traffic worked fine after changing the address. Signed-off-by: Kristian Evensen <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.