aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-09-14cpu/hotplug: Include linux/types.h in linux/cpuhotplug.hPaul Burton1-0/+2
The linux/cpuhotplug.h header makes use of the bool type, but wasn't including linux/types.h to ensure that type has been defined. Fix this by including linux/types.h in preparation for including linux/cpuhotplug.h in a file that doesn't do so already. Signed-off-by: Paul Burton <[email protected]> Cc: [email protected] Cc: Richard Cochran <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Anna-Maria Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2016-09-14mmc: omap: Initialize dma_slave_config to avoid random data in it's fieldsPeter Ujfalusi1-8/+10
It is wrong to use uninitialized dma_slave_config and configure only certain fields as the DMAengine driver might look at non initialized (random data) fields and tries to interpret it. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-09-14mmc: omap_hsmmc: Initialize dma_slave_config to avoid random dataPeter Ujfalusi1-8/+8
It is wrong to use uninitialized dma_slave_config and configure only certain fields as the DMAengine driver might look at non initialized (random data) fields and tries to interpret it. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-09-14mac80211: check skb_linearize() return valueJohannes Berg1-2/+6
The A-MSDU TX code (within TXQs) didn't always check the return value of skb_linearize() properly, resulting in potentially passing a frag- list SKB down to the driver even when it said it can't handle it. Fix that. Fixes: 6e0456b545456 ("mac80211: add A-MSDU tx support") Signed-off-by: Johannes Berg <[email protected]>
2016-09-14drm/i915: Ignore OpRegion panel type except on select machinesVille Syrjälä1-0/+27
Turns out commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some specific systems. Despite trying, I was unable to find any automagic way to determine if the OpRegion panel type is respectable or not. The only glimmer of hope I had was bit 8 in the SCIC response, but that turned out to not work either (it was always 0 on both types of systems). So, to fix the regressions without breaking the machine we know to need the OpRegion panel type, let's just add a quirk for this. Only specific machines known to require the OpRegion panel type will therefore use it. Everyone else will fall bck to the VBT panel type. The only known machine so far is a "Conrac GmbH IX45GM2". The PCI subsystem ID on this machine is just a generic 8086:2a42, so of no use. Instead we'll go with a DMI match. I suspect we can now also revert commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL") but let's leave that to a separate patch. v2: Do the DMI match in the opregion code directly, as dev_priv->quirks gets populated too late Cc: Rob Kramer <[email protected]> Cc: Martin van Es <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Marco Krüger <[email protected]> Cc: Sean Greenslade <[email protected]> Cc: Trudy Tective <[email protected]> Cc: Robin Müller <[email protected]> Cc: Alexander Kobel <[email protected]> Cc: Alexey Shumitsky <[email protected]> Cc: Emil Andersen Lauridsen <[email protected]> Cc: [email protected] Cc: James Hogan <[email protected]> Cc: James Bottomley <[email protected]> Cc: [email protected] References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") Tested-by: Marco Krüger <[email protected]> Tested-by: Alexey Shumitsky <[email protected]> Tested-by: Sean Greenslade <[email protected]> Tested-by: Emil Andersen Lauridsen <[email protected]> Tested-by: Robin Müller <[email protected]> Tested-by: [email protected] Tested-by: Rob Kramer <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] References: http://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> (cherry picked from commit c8ebfad7a063fe665417fa0eeb0da7cfe987d8ed) Signed-off-by: Jani Nikula <[email protected]>
2016-09-14Revert "drm/i915/psr: Make idle_frames sensible again"Rodrigo Vivi1-7/+7
This reverts commit 1c80c25fb622973dd135878e98d172be20859049 Author: Daniel Vetter <[email protected]> Date: Wed May 18 18:47:12 2016 +0200 drm/i915/psr: Make idle_frames sensible again There are panels that needs 4 idle frames before entering PSR, but VBT is unproperly set. Also lately it was identified that idle frame count calculated at HW can be off by 1, what makes the minimum of 2, at least. Without the current vbt+1 we are with the risk of having HW calculating 0 idle frames and entering PSR when it shouldn't. Regardless the lack of link training. [Jani: there is some disagreement on the explanation, but the commit regresses so revert it is.] References: http://marc.info/[email protected] Cc: Dominik Brodowski <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Fixes: 1c80c25fb622 ("drm/i915/psr: Make idle_frames sensible again") Cc: [email protected] # v4.8-rc1+ Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 40918e0bb81be02f507a941f8b2741f0dc1771b0) Signed-off-by: Jani Nikula <[email protected]>
2016-09-14drm/i915: Restore lost "Initialized i915" welcome messageChris Wilson1-0/+5
A side effect of removing the midlayer from driver loading was the loss of a useful message announcing to userspace that i915 had successfully started, e.g.: [drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0 Reported-by: Timo Aaltonen <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Fixes: 8f460e2c78f2 ("drm/i915: Demidlayer driver loading") Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> (cherry picked from commit bc5ca47c0af4f949ba889e666b7da65569e36093) Signed-off-by: Jani Nikula <[email protected]>
2016-09-14powerpc/powernv: Fix the state of root PEGavin Shan1-1/+11
The PE for root bus (root PE) can be removed because of PCI hot remove in EEH recovery path for fenced PHB error. We need update @phb->root_pe_populated accordingly so that the root PE can be populated again in forthcoming PCI hot add path. Also, the PE shouldn't be destroyed as it's global and reserved resource. Fixes: c5f7700bbd2e ("powerpc/powernv: Dynamically release PE") Reported-by: Frederic Barrat <[email protected]> Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-09-13avr32: fix copy_from_user()Al Viro3-4/+13
really ugly, but apparently avr32 compilers turns access_ok() into something so bad that they want it in assembler. Left that way, zeroing added in inline wrapper. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13microblaze: fix __get_user()Al Viro1-1/+1
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13microblaze: fix copy_from_user()Al Viro1-3/+6
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13m32r: fix __get_user()Al Viro1-1/+1
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13blackfin: fix copy_from_user()Al Viro1-4/+5
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13sparc32: fix copy_from_user()Al Viro1-1/+3
Cc: [email protected] Acked-by: David S. Miller <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13sh: fix copy_from_user()Al Viro1-1/+4
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13sh64: failing __get_user() should zeroAl Viro1-0/+1
It could be done in exception-handling bits in __get_user_b() et.al., but the surgery involved would take more knowledge of sh64 details than I have or _want_ to have. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13score: fix copy_from_user() and friendsAl Viro1-21/+20
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13score: fix __get_user/get_userAl Viro1-1/+4
* should zero on any failure * __get_user() should use __copy_from_user(), not copy_from_user() Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13s390: get_user() should zero on failureAl Viro1-4/+4
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13ppc32: fix copy_from_user()Al Viro1-23/+2
should clear on access_ok() failures. Also remove the useless range truncation logics. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13parisc: fix copy_from_user()Al Viro1-2/+4
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13openrisc: fix copy_from_user()Al Viro1-24/+11
... that should zero on faults. Also remove the <censored> helpful logics wrt range truncation copied from ppc32. Where it had ever been needed only in case of copy_from_user() *and* had not been merged into the mainline until a month after the need had disappeared. A decade before openrisc went into mainline, I might add... Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13nios2: fix __get_user()Al Viro1-2/+2
a) should not leave crap on fault b) should _not_ require access_ok() in any cases. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13nios2: copy_from_user() should zero the tail of destinationAl Viro1-3/+6
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13mn10300: copy_from_user() should zero on access_ok() failure...Al Viro1-1/+3
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13mn10300: failing __get_user() and get_user() should zeroAl Viro1-0/+1
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13mips: copy_from_user() must zero the destination on access_ok() failureAl Viro1-0/+3
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13ARC: uaccess: get_user to zero out dest in cause of faultVineet Gupta1-2/+9
Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by: Al Viro <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13metag: copy_from_user() should zero the destination on access_ok() failureAl Viro1-1/+2
Cc: [email protected] Acked-by: James Hogan <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13ia64: copy_from_user() should zero the destination on access_ok() failureAl Viro1-14/+11
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13hexagon: fix strncpy_from_user() error returnAl Viro1-1/+2
It's -EFAULT, not -1 (and contrary to the comment in there, __strnlen_user() can return 0 - on faults). Cc: [email protected] Acked-by: Richard Kuo <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13frv: fix clear_user()Al Viro1-3/+9
It should check access_ok(). Otherwise a bunch of places turn into trivially exploitable rootholes. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13cris: buggered copy_from_user/copy_to_user/clear_userAl Viro1-39/+32
* copy_from_user() on access_ok() failure ought to zero the destination * none of those primitives should skip the access_ok() check in case of small constant size. Cc: [email protected] Acked-by: Jesper Nilsson <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13asm-generic: make get_user() clear the destination on errorsAl Viro1-3/+7
both for access_ok() failures and for faults halfway through Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13PCI: Fix bridge_d3 update on device removalLukas Wunner1-2/+1
Starting with v4.8, we allow a PCIe port to runtime suspend to D3hot if the port itself and its children satisfy a number of conditions. Once a child is removed, we recheck those conditions in case the removed device was blocking the port from suspending. The rechecking needs to happen *after* the device has been removed from the bus it resides on. Otherwise when walking the port's subordinate bus in pci_bridge_d3_update(), the device being removed would erroneously still be taken into account. However the device is removed from the bus_list in pci_destroy_dev() and we currently recheck *before* that. Fix it. Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]>
2016-09-13Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds3-7/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Three fixes: - AMD microcode loading fix with randomization - an lguest tooling fix - and an APIC enumeration boundary condition fix" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/apic: Fix num_processors value in case of failure tools/lguest: Don't bork the terminal in case of wrong args x86/microcode/AMD: Fix load of builtin microcode with randomized memory
2016-09-13Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds1-0/+22
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Ingo Molnar: "A try_to_wake_up() memory ordering race fix causing a busy-loop in ttwu()" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Fix a race between try_to_wake_up() and a woken up task
2016-09-13Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds6-55/+180
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "This contains: - a set of fixes found by directed-random perf fuzzing efforts by Vince Weaver, Alexander Shishkin and Peter Zijlstra - a cqm driver crash fix - an AMD uncore driver use after free fix" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Fix PEBSv3 record drain perf/x86/intel/bts: Kill a silly warning perf/x86/intel/bts: Fix BTS PMI detection perf/x86/intel/bts: Fix confused ordering of PMU callbacks perf/core: Fix aux_mmap_count vs aux_refcount order perf/core: Fix a race between mmap_close() and set_output() of AUX events perf/x86/amd/uncore: Prevent use after free perf/x86/intel/cqm: Check cqm/mbm enabled state in event init perf/core: Remove WARN from perf_event_read()
2016-09-13Merge branch 'locking-urgent-for-linus' of ↵Linus Torvalds1-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fix from Ingo Molnar: "Another lockless_dereference() Sparse fix" * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/barriers: Don't use sizeof(void) in lockless_dereference()
2016-09-13Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds6-120/+283
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Ingo Molnar: "This contains a Xen fix, an arm64 fix and a race condition / robustization set of fixes related to ExitBootServices() usage and boundary conditions" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Use efi_exit_boot_services() efi/libstub: Use efi_exit_boot_services() in FDT efi/libstub: Introduce ExitBootServices helper efi/libstub: Allocate headspace in efi_get_memory_map() efi: Fix handling error value in fdt_find_uefi_params efi: Make for_each_efi_memory_desc_in_map() cope with running on Xen
2016-09-13Merge tag 'md/4.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/mdLinus Torvalds3-41/+31
Pull MD fixes from Shaohua Li: "A few bug fixes for MD: - Guoqing fixed a bug compiling md-cluster in kernel - I fixed a potential deadlock in raid5-cache superblock write, a hang in raid5 reshape resume and a race condition introduced in rc4" * tag 'md/4.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md: raid5: fix a small race condition md-cluster: make md-cluster also can work when compiled into kernel raid5: guarantee enough stripes to avoid reshape hang raid5-cache: fix a deadlock in superblock write
2016-09-13nl80211: validate number of probe response CSA countersJohannes Berg1-1/+1
Due to an apparent copy/paste bug, the number of counters for the beacon configuration were checked twice, instead of checking the number of probe response counters. Fix this to check the number of probe response counters before parsing those. Cc: [email protected] Fixes: 9a774c78e211 ("cfg80211: Support multiple CSA counters") Signed-off-by: Johannes Berg <[email protected]>
2016-09-13Merge branch 'linus' of ↵Linus Torvalds1-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto bugfix from Herbert Xu: "Fix a bug in the cryptd code that may lead to crashes" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: cryptd - initialize child shash_desc on import
2016-09-13drivers: net: phy: xgene: Fix 'remove' functionChristophe Jaillet1-4/+2
If 'IS_ERR(pdata->clk)' is true, then 'clk_disable_unprepare(pdata->clk)' will do nothing. It is likely that 'if (!IS_ERR(pdata->clk))' was expected here. In fact, the test can even be removed because 'clk_disable_unprepare' already handles such cases. Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-09-13sctp: hold the transport before using it in sctp_hash_cmpXin Long1-10/+17
Since commit 4f0087812648 ("sctp: apply rhashtable api to send/recv path"), sctp uses transport rhashtable with .obj_cmpfn sctp_hash_cmp, in which it compares the members of the transport with the rhashtable args to check if it's the right transport. But sctp uses the transport without holding it in sctp_hash_cmp, it can cause a use-after-free panic. As after it gets transport from hashtable, another CPU may close the sk and free the asoc. In sctp_association_free, it frees all the transports, meanwhile, the assoc's refcnt may be reduced to 0, assoc can be destroyed by sctp_association_destroy. So after that, transport->assoc is actually an unavailable memory address in sctp_hash_cmp. Although sctp_hash_cmp is under rcu_read_lock, it still can not avoid this, as assoc is not freed by RCU. This patch is to hold the transport before checking it's members with sctp_transport_hold, in which it checks the refcnt first, holds it if it's not 0. Fixes: 4f0087812648 ("sctp: apply rhashtable api to send/recv path") Signed-off-by: Xin Long <[email protected]> Acked-by: Marcelo Ricardo Leitner <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-09-13MIPS: c-r4k: Fix size calc when avoiding IPIs for small icache flushesPaul Burton1-1/+1
Commit f70ddc07b637 ("MIPS: c-r4k: Avoid small flush_icache_range SMP calls") adds checks to force use of hit-type cache ops for small icache flushes where they are globalised & index-type cache ops aren't, in order to avoid the overhead of IPIs in those cases. However it calculated the size of the region being flushed incorrectly, subtracting the end address from the start address rather than the reverse. This would have led to an overflow with size wrapping round to some large value, and likely to the special case for avoiding IPIs not actually being hit. Signed-off-by: Paul Burton <[email protected]> Cc: James Hogan <[email protected]> Fixes: f70ddc07b637 ("MIPS: c-r4k: Avoid small flush_icache_range SMP calls") Reviewed-by: James Hogan <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Cc: Huacai Chen <[email protected]> Cc: [email protected] Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/14211/ Signed-off-by: Ralf Baechle <[email protected]>
2016-09-13cpuset: handle race between CPU hotplug and cpuset_hotplug_workJoonwoo Park1-3/+14
A discrepancy between cpu_online_mask and cpuset's effective_cpus mask is inevitable during hotplug since cpuset defers updating of effective_cpus mask using a workqueue, during which time nothing prevents the system from more hotplug operations. For that reason guarantee_online_cpus() walks up the cpuset hierarchy until it finds an intersection under the assumption that top cpuset's effective_cpus mask intersects with cpu_online_mask even with such a race occurring. However a sequence of CPU hotplugs can open a time window, during which none of the effective CPUs in the top cpuset intersect with cpu_online_mask. For example when there are 4 possible CPUs 0-3 and only CPU0 is online: ======================== =========================== cpu_online_mask top_cpuset.effective_cpus ======================== =========================== echo 1 > cpu2/online. CPU hotplug notifier woke up hotplug work but not yet scheduled. [0,2] [0] echo 0 > cpu0/online. The workqueue is still runnable. [2] [0] ======================== =========================== Now there is no intersection between cpu_online_mask and top_cpuset.effective_cpus. Thus invoking sys_sched_setaffinity() at this moment can cause following: Unable to handle kernel NULL pointer dereference at virtual address 000000d0 ------------[ cut here ]------------ Kernel BUG at ffffffc0001389b0 [verbose debug info unavailable] Internal error: Oops - BUG: 96000005 [#1] PREEMPT SMP Modules linked in: CPU: 2 PID: 1420 Comm: taskset Tainted: G W 4.4.8+ #98 task: ffffffc06a5c4880 ti: ffffffc06e124000 task.ti: ffffffc06e124000 PC is at guarantee_online_cpus+0x2c/0x58 LR is at cpuset_cpus_allowed+0x4c/0x6c <snip> Process taskset (pid: 1420, stack limit = 0xffffffc06e124020) Call trace: [<ffffffc0001389b0>] guarantee_online_cpus+0x2c/0x58 [<ffffffc00013b208>] cpuset_cpus_allowed+0x4c/0x6c [<ffffffc0000d61f0>] sched_setaffinity+0xc0/0x1ac [<ffffffc0000d6374>] SyS_sched_setaffinity+0x98/0xac [<ffffffc000085cb0>] el0_svc_naked+0x24/0x28 The top cpuset's effective_cpus are guaranteed to be identical to cpu_online_mask eventually. Hence fall back to cpu_online_mask when there is no intersection between top cpuset's effective_cpus and cpu_online_mask. Signed-off-by: Joonwoo Park <[email protected]> Acked-by: Li Zefan <[email protected]> Cc: Tejun Heo <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # 3.17+ Signed-off-by: Tejun Heo <[email protected]>
2016-09-13MIPS: Add a missing ".set pop" in an early commitHuacai Chen1-0/+1
Commit 842dfc11ea9a21 ("MIPS: Fix build with binutils 2.24.51+") missing a ".set pop" in macro fpu_restore_16even, so add it. Signed-off-by: Huacai Chen <[email protected]> Acked-by: Manuel Lauss <[email protected]> Cc: Steven J . Hill <[email protected]> Cc: Fuxin Zhang <[email protected]> Cc: Zhangjin Wu <[email protected]> Cc: [email protected] Cc: [email protected] # 3.18+ Patchwork: https://patchwork.linux-mips.org/patch/14210/ Signed-off-by: Ralf Baechle <[email protected]>
2016-09-13bnx2: Reset device during driver initializationBaoquan He1-5/+7
When system enters into kdump kernel because of kernel panic, it won't shutdown devices. On-flight DMA will continue transferring data until device driver initializes. All devices are supposed to reset during driver initialization. And this property is used to fix the kdump failure in system with intel iommu. Other systems with hardware iommu should be similar. Please check commit 091d42e ("iommu/vt-d: Copy translation tables from old kernel") and those commits around. But bnx2 driver doesn't reset device during driver initialization. The device resetting is deferred to net device up stage. This will cause hardware iommu handling failure on bnx2 device. And its resetting relies on firmware. So in this patch move the firmware requesting code to earlier bnx2_init_one(), then next call bnx2_reset_chip to reset device. Signed-off-by: Baoquan He <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2016-09-13Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nfDavid S. Miller6-13/+35
Pablo Neira Ayuso says: ==================== Netfilter fixes for net The following patchset contains Netfilter fixes for your net tree, they are: 1) Endianess fix for the new nf_tables netlink trace infrastructure, NFTA_TRACE_POLICY endianess was not correct, patch from Liping Zhang. 2) Fix broken re-route after userspace queueing in nf_tables route chain. This patch is large but it is simple since it is just getting this code in sync with iptable_mangle. Also from Liping. 3) NAT mangling via ctnetlink lies to userspace when nf_nat_setup_info() fails to setup the NAT conntrack extension. This problem has been there since the beginning, but it can now show up after rhashtable conversion. 4) Fix possible NULL pointer dereference due to failures in allocating the synproxy and seqadj conntrack extensions, from Gao feng. ==================== Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.