aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-03-17Btrfs: just free dummy extent buffersJosef Bacik1-0/+6
If we fail during our sanity tests we could get NULL deref's because we unload the module before the dummy extent buffers are free'd via RCU. So check for this case and just free the things directly. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2015-03-17Btrfs: account merges/splits properlyJosef Bacik1-27/+30
My fix Btrfs: fix merge delalloc logic only fixed half of the problems, it didn't fix the case where we have two large extents on either side and then join them together with a new small extent. We need to instead keep track of how many extents we have accounted for with each side of the new extent, and then see how many extents we need for the new large extent. If they match then we know we need to keep our reservation, otherwise we need to drop our reservation. This shows up with a case like this [BTRFS_MAX_EXTENT_SIZE+4K][4K HOLE][BTRFS_MAX_EXTENT_SIZE+4K] Previously the logic would have said that the number extents required for the new size (3) is larger than the number of extents required for the largest side (2) therefore we need to keep our reservation. But this isn't the case, since both sides require a reservation of 2 which leads to 4 for the whole range currently reserved, but we only need 3, so we need to drop one of the reservations. The same problem existed for splits, we'd think we only need 3 extents when creating the hole but in reality we need 4. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2015-03-17Merge branches 'perf-urgent-for-linus' and 'timers-urgent-for-linus' of ↵Linus Torvalds4-7/+9
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf and timer fixes from Ingo Molnar: "Two small perf fixes: - kernel side context leak fix - tooling crash fix And two clocksource driver fixes" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix context leak in put_event() perf annotate: Fix fallback to unparsed disassembler line * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: clockevents: sun5i: Fix setup_irq init sequence clocksource: efm32: Fix a NULL pointer dereference
2015-03-17HID: wacom: check for wacom->shared before following the pointerBenjamin Tissoires1-3/+4
486b908 (HID: wacom: do not send pen events before touch is up/forced out) introduces a kernel oops when plugging a tablet without touch. wacom->shared is null for these devices so this leads to a null pointer exception. Change the condition to make it clear that what we need is wacom->shared not NULL. Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2015-03-17Revert "smc91x: retrieve IRQ and trigger flags in a modern way"Robert Jarzmik1-12/+8
The commit breaks the legacy platforms, ie. these not using device-tree, and setting up the interrupt resources with a flag to activate edge detection. The issue was found on the zylonite platform. The reason is that zylonite uses platform resources to pass the interrupt number and the irq flags (here IORESOURCE_IRQ_HIGHEDGE). It expects the driver to request the irq with these flags, which in turn setups the irq as high edge triggered. After the patch, this was supposed to be taken care of with : irq_resflags = irqd_get_trigger_type(irq_get_irq_data(ndev->irq)); But irq_resflags is 0 for legacy platforms, while for example in arch/arm/mach-pxa/zylonite.c, in struct resource smc91x_resources[] the irq flag is specified. This breaks zylonite because the interrupt is not setup as triggered, and hardware doesn't provide interrupts. Signed-off-by: Robert Jarzmik <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-17inet: Clean up inet_csk_wait_for_connect() vs. might_sleep()Eric Dumazet1-0/+1
I got the following trace with current net-next kernel : [14723.885290] WARNING: CPU: 26 PID: 22658 at kernel/sched/core.c:7285 __might_sleep+0x89/0xa0() [14723.885325] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810e8734>] prepare_to_wait_exclusive+0x34/0xa0 [14723.885355] CPU: 26 PID: 22658 Comm: netserver Not tainted 4.0.0-dbg-DEV #1379 [14723.885359] ffffffff81a223a8 ffff881fae9e7ca8 ffffffff81650b5d 0000000000000001 [14723.885364] ffff881fae9e7cf8 ffff881fae9e7ce8 ffffffff810a72e7 0000000000000000 [14723.885367] ffffffff81a57620 000000000000093a 0000000000000000 ffff881fae9e7e64 [14723.885371] Call Trace: [14723.885377] [<ffffffff81650b5d>] dump_stack+0x4c/0x65 [14723.885382] [<ffffffff810a72e7>] warn_slowpath_common+0x97/0xe0 [14723.885386] [<ffffffff810a73e6>] warn_slowpath_fmt+0x46/0x50 [14723.885390] [<ffffffff810f4c5d>] ? trace_hardirqs_on_caller+0x10d/0x1d0 [14723.885393] [<ffffffff810e8734>] ? prepare_to_wait_exclusive+0x34/0xa0 [14723.885396] [<ffffffff810e8734>] ? prepare_to_wait_exclusive+0x34/0xa0 [14723.885399] [<ffffffff810ccdc9>] __might_sleep+0x89/0xa0 [14723.885403] [<ffffffff81581846>] lock_sock_nested+0x36/0xb0 [14723.885406] [<ffffffff815829a3>] ? release_sock+0x173/0x1c0 [14723.885411] [<ffffffff815ea1f7>] inet_csk_accept+0x157/0x2a0 [14723.885415] [<ffffffff810e8900>] ? abort_exclusive_wait+0xc0/0xc0 [14723.885419] [<ffffffff8161b96d>] inet_accept+0x2d/0x150 [14723.885424] [<ffffffff8157db6f>] SYSC_accept4+0xff/0x210 [14723.885428] [<ffffffff8165a451>] ? retint_swapgs+0xe/0x44 [14723.885431] [<ffffffff810f4c5d>] ? trace_hardirqs_on_caller+0x10d/0x1d0 [14723.885437] [<ffffffff81369c0e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [14723.885441] [<ffffffff8157ef40>] SyS_accept+0x10/0x20 [14723.885444] [<ffffffff81659872>] system_call_fastpath+0x12/0x17 [14723.885447] ---[ end trace ff74cd83355b1873 ]--- In commit 26cabd31259ba43f68026ce3f62b78094124333f Peter added a sched_annotate_sleep() in sk_wait_event() Is the following patch needed as well ? Alternative would be to use sk_wait_event() from inet_csk_wait_for_connect() Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-17ip6_tunnel: fix error code when tunnel existsNicolas Dichtel1-16/+17
After commit 2b0bb01b6edb, the kernel returns -ENOBUFS when user tries to add an existing tunnel with ioctl API: $ ip -6 tunnel add ip6tnl1 mode ip6ip6 dev eth1 add tunnel "ip6tnl0" failed: No buffer space available It's confusing, the right error is EEXIST. This patch also change a bit the code returned: - ENOBUFS -> ENOMEM - ENOENT -> ENODEV Fixes: 2b0bb01b6edb ("ip6_tunnel: Return an error when adding an existing tunnel.") CC: Steffen Klassert <[email protected]> Reported-by: Pierre Cheynier <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-17netdevice.h: fix ndo_bridge_* commentsNicolas Dichtel1-1/+4
The argument 'flags' was missing in ndo_bridge_setlink(). ndo_bridge_dellink() was missing. Fixes: 407af3299ef1 ("bridge: Add netlink interface to configure vlans on bridge ports") Fixes: add511b38266 ("bridge: add flags argument to ndo_bridge_setlink and ndo_bridge_dellink") CC: Vlad Yasevich <[email protected]> CC: Roopa Prabhu <[email protected]> Signed-off-by: Nicolas Dichtel <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-17Merge tag 'regulator-fix-v4.0-rc4' of ↵Linus Torvalds2-17/+18
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "The two main fixes here from Javier and Doug both fix issues seen on the Exynos-based ARM Chromebooks with reference counting of GPIO regulators over system suspend. The GPIO enable code didn't properly take account of this case (a full analysis is in Doug's commit log). This is fixed by both fixing the reference counting directly and by making the resume code skip enables it doesn't need to do. We could skip the change in the resume code but it's a very simple change and adds extra robustness against problems in other drivers" * tag 'regulator-fix-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: tps65910: Add missing #include <linux/of.h> regulator: core: Fix enable GPIO reference counting regulator: Only enable disabled regulators on resume
2015-03-17Merge tag 'regmap-v4.0-rc4' of ↵Linus Torvalds3-4/+7
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fixes from Mark Brown: "A few things here: - a change from Lars to fix insertion of cache values at the start of rather than end of a rbtree block. This hadn't been noticed before since almost everything lists registers in ascending order. - a fix from Takashi for spurious warnings during cache sync with read once registers, a problem which can be very noticeable on devices that it affects. - a fix from Valentin for a tighening of the oneshot IRQ request interface which would have broken affected devices" * tag 'regmap-v4.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: regcache-rbtree: Fix present bitmap resize regmap: Skip read-only registers in regcache_sync() regmap-irq: set IRQF_ONESHOT flag to ensure IRQ request
2015-03-17Merge tag 'virtio-next-for-linus' of ↵Linus Torvalds7-23/+168
git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull virtio fixes from Rusty Russell: "Not entirely surprising: the ongoing QEMU work on virtio 1.0 has revealed more minor issues with our virtio 1.0 drivers just introduced in the kernel. (I would normally use my fixes branch for this, but there were a batch of them...)" * tag 'virtio-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: virtio_mmio: fix access width for mmio uapi/virtio_scsi: allow overriding CDB/SENSE size virtio_mmio: generation support virtio_rpmsg: set DRIVER_OK before using device 9p/trans_virtio: fix hot-unplug virtio-balloon: do not call blocking ops when !TASK_RUNNING virtio_blk: fix comment for virtio 1.0 virtio_blk: typo fix virtio_balloon: set DRIVER_OK before using device virtio_console: avoid config access from irq virtio_console: init work unconditionally
2015-03-17Merge git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds13-81/+114
Pull kvm fixes from Marcelo Tosatti: "KVM bug fixes (ARM and x86)" * git://git.kernel.org/pub/scm/virt/kvm/kvm: arm/arm64: KVM: Keep elrsr/aisr in sync with software model KVM: VMX: Set msr bitmap correctly if vcpu is in guest mode arm/arm64: KVM: fix missing unlock on error in kvm_vgic_create() kvm: x86: i8259: return initialized data on invalid-size read arm64: KVM: Fix outdated comment about VTCR_EL2.PS arm64: KVM: Do not use pgd_index to index stage-2 pgd arm64: KVM: Fix stage-2 PGD allocation to have per-page refcounting kvm: move advertising of KVM_CAP_IRQFD to common code
2015-03-17pagemap: do not leak physical addresses to non-privileged userspaceKirill A. Shutemov1-0/+3
As pointed by recent post[1] on exploiting DRAM physical imperfection, /proc/PID/pagemap exposes sensitive information which can be used to do attacks. This disallows anybody without CAP_SYS_ADMIN to read the pagemap. [1] http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html [ Eventually we might want to do anything more finegrained, but for now this is the simple model. - Linus ] Signed-off-by: Kirill A. Shutemov <[email protected]> Acked-by: Konstantin Khlebnikov <[email protected]> Acked-by: Andy Lutomirski <[email protected]> Cc: Pavel Emelyanov <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Mark Seaborn <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]>
2015-03-17Merge tag 'asoc-fix-v4.0-rc4' of ↵Takashi Iwai23-92/+118
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.0 As well as the usual collection of driver specific fixes there's a few more generic things: - Lots of fixes from Takashi for drivers using the wrong field in the control union to communicate with userspace, leading to potential errors on 64 bit systems. - A fix from Lars for locking of the lists of devices we maintain, mostly only likely to trigger during device probe and removal.
2015-03-17x86/asm/entry/64: Rename 'old_rsp' to 'rsp_scratch'Ingo Molnar3-10/+10
Make clear that the usage of PER_CPU(old_rsp) is purely temporary, by renaming it to 'rsp_scratch'. Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry/64: Update comments about stack framesIngo Molnar1-8/+11
Tweak a few outdated comments that were obsoleted by recent changes to syscall entry code: - we no longer have a "partial stack frame" on entry, ever. - explain the syscall entry usage of old_rsp. Partially based on a (split out of) patch from Denys Vlasenko. Originally-from: Denys Vlasenko <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry/64: Remove thread_struct::userspIngo Molnar2-4/+0
Nothing uses thread_struct::usersp anymore, so remove it. Originally-from: Denys Vlasenko <[email protected]> Tested-by: Borislav Petkov <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry/64: Simplify 'old_rsp' usageIngo Molnar2-7/+0
Remove all manipulations of PER_CPU(old_rsp) in C code: - it is not used on SYSRET return anymore, and system entries are atomic, so updating it from the fork and context switch paths is pointless. - Tweak a few related comments as well: we no longer have a "partial stack frame" on entry, ever. Based on (split out of) patch from Denys Vlasenko. Originally-from: Denys Vlasenko <[email protected]> Tested-by: Borislav Petkov <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry/64: Enable interrupts *after* we fetch PER_CPU_VAR(old_rsp)Denys Vlasenko1-5/+5
We want to use PER_CPU_VAR(old_rsp) as a simple temporary register, to shuffle user-space RSP into (and from) when we set up the system call stack frame. At that point we cannot shuffle values into general purpose registers, because we have not saved them yet. To be able to do this shuffling into a memory location, we must be atomic and must not be preempted while we do the shuffling, otherwise the 'temporary' register gets overwritten by some other task's temporary register contents ... Tested-by: Borislav Petkov <[email protected]> Signed-off-by: Denys Vlasenko <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17Btrfs: prepare block group cache before writingJosef Bacik3-1/+32
Writing the block group cache will modify the extent tree quite a bit because it truncates the old space cache and pre-allocates new stuff. To try and cut down on the churn lets do the setup dance first, then later on hopefully we can avoid looping with newly dirtied roots. Thanks, Signed-off-by: Josef Bacik <[email protected]>
2015-03-17livepatch: Fix subtle race with coming and going modulesPetr Mladek2-4/+30
There is a notifier that handles live patches for coming and going modules. It takes klp_mutex lock to avoid races with coming and going patches but it does not keep the lock all the time. Therefore the following races are possible: 1. The notifier is called sometime in STATE_MODULE_COMING. The module is visible by find_module() in this state all the time. It means that new patch can be registered and enabled even before the notifier is called. It might create wrong order of stacked patches, see below for an example. 2. New patch could still see the module in the GOING state even after the notifier has been called. It will try to initialize the related object structures but the module could disappear at any time. There will stay mess in the structures. It might even cause an invalid memory access. This patch solves the problem by adding a boolean variable into struct module. The value is true after the coming and before the going handler is called. New patches need to be applied when the value is true and they need to ignore the module when the value is false. Note that we need to know state of all modules on the system. The races are related to new patches. Therefore we do not know what modules will get patched. Also note that we could not simply ignore going modules. The code from the module could be called even in the GOING state until mod->exit() finishes. If we start supporting patches with semantic changes between function calls, we need to apply new patches to any still usable code. See below for an example. Finally note that the patch solves only the situation when a new patch is registered. There are no such problems when the patch is being removed. It does not matter who disable the patch first, whether the normal disable_patch() or the module notifier. There is nothing to do once the patch is disabled. Alternative solutions: ====================== + reject new patches when a patched module is coming or going; this is ugly + wait with adding new patch until the module leaves the COMING and GOING states; this might be dangerous and complicated; we would need to release kgr_lock in the middle of the patch registration to avoid a deadlock with the coming and going handlers; also we might need a waitqueue for each module which seems to be even bigger overhead than the boolean + stop modules from entering COMING and GOING states; wait until modules leave these states when they are already there; looks complicated; we would need to ignore the module that asked to stop the others to avoid a deadlock; also it is unclear what to do when two modules asked to stop others and both are in COMING state (situation when two new patches are applied) + always register/enable new patches and fix up the potential mess (registered patches order) in klp_module_init(); this is nasty and prone to regressions in the future development + add another MODULE_STATE where the kallsyms are visible but the module is not used yet; this looks too complex; the module states are checked on "many" locations Example of patch stacking breakage: =================================== The notifier could _not_ _simply_ ignore already initialized module objects. For example, let's have three patches (P1, P2, P3) for functions a() and b() where a() is from vmcore and b() is from a module M. Something like: a() b() P1 a1() b1() P2 a2() b2() P3 a3() b3(3) If you load the module M after all patches are registered and enabled. The ftrace ops for function a() and b() has listed the functions in this order: ops_a->func_stack -> list(a3,a2,a1) ops_b->func_stack -> list(b3,b2,b1) , so the pointer to b3() is the first and will be used. Then you might have the following scenario. Let's start with state when patches P1 and P2 are registered and enabled but the module M is not loaded. Then ftrace ops for b() does not exist. Then we get into the following race: CPU0 CPU1 load_module(M) complete_formation() mod->state = MODULE_STATE_COMING; mutex_unlock(&module_mutex); klp_register_patch(P3); klp_enable_patch(P3); # STATE 1 klp_module_notify(M) klp_module_notify_coming(P1); klp_module_notify_coming(P2); klp_module_notify_coming(P3); # STATE 2 The ftrace ops for a() and b() then looks: STATE1: ops_a->func_stack -> list(a3,a2,a1); ops_b->func_stack -> list(b3); STATE2: ops_a->func_stack -> list(a3,a2,a1); ops_b->func_stack -> list(b2,b1,b3); therefore, b2() is used for the module but a3() is used for vmcore because they were the last added. Example of the race with going modules: ======================================= CPU0 CPU1 delete_module() #SYSCALL try_stop_module() mod->state = MODULE_STATE_GOING; mutex_unlock(&module_mutex); klp_register_patch() klp_enable_patch() #save place to switch universe b() # from module that is going a() # from core (patched) mod->exit(); Note that the function b() can be called until we call mod->exit(). If we do not apply patch against b() because it is in MODULE_STATE_GOING, it will call patched a() with modified semantic and things might get wrong. [[email protected]: use one boolean instead of two] Signed-off-by: Petr Mladek <[email protected]> Acked-by: Josh Poimboeuf <[email protected]> Acked-by: Rusty Russell <[email protected]> Signed-off-by: Jiri Kosina <[email protected]>
2015-03-17x86/asm/entry: Document and clean up the enable_sep_cpu() and ↵Ingo Molnar1-13/+29
syscall32_cpu_init() functions Clean up the flow and document the functions a bit better. Cc: Denys Vlasenko <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry/32: Document the 32-bit SYSENTER "emergency stack" betterDenys Vlasenko3-4/+4
Before the patch, the 'tss_struct::stack' field was not referenced anywhere. It was used only to set SYSENTER's stack to point after the last byte of tss_struct, thus the trailing field, stack[64], was used. But grep would not know it. You can comment it out, compile, and kernel will even run until an unlucky NMI corrupts io_bitmap[] (which is also not easily detectable). This patch changes code so that the purpose and usage of this field is not mysterious anymore, and can be easily grepped for. This does change generated code, for a subtle reason: since tss_struct is ____cacheline_aligned, there happens to be 5 longs of padding at the end. Old code was using the padding too; new code will strictly use it only for SYSENTER_stack[]. Signed-off-by: Denys Vlasenko <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17include/stddef.h: Move offsetofend() from vfio.h to a generic kernel headerDenys Vlasenko2-13/+9
Suggested by Andy. Suggested-by: Andy Lutomirski <[email protected]> Signed-off-by: Denys Vlasenko <[email protected]> Acked-by: Linus Torvalds <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Will Drewry <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry: Simplify task_pt_regs() macro definitionDenys Vlasenko1-14/+6
Before this change, task_pt_regs() was using KSTK_TOP(), and it was the only use of that macro. In turn, KSTK_TOP used THREAD_SIZE_LONGS, and it was the only use of that macro too. Fold these macros into task_pt_regs(). Tweak comment about "- 8" - we now use a symbolic constant, not literal 8. Signed-off-by: Denys Vlasenko <[email protected]> Reviewed-by: Steven Rostedt <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Frederic Weisbecker <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Will Drewry <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry/32: Document our abuse of x86_hw_tss::ss1 and x86_hw_tss::sp1Andy Lutomirski1-3/+18
This has confused me for a while. Now that I figured it out, document it. Signed-off-by: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/b7efc1b7364039824776f68e9ddee9ec1500e894.1426009661.git.luto@amacapital.net Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry: Unify and fix initial thread_struct::sp0 valuesAndy Lutomirski2-3/+6
x86_32 and x86_64 need slightly different thread_struct::sp0 values, and x86_32's was incorrect for init. This never mattered -- the init thread never runs user code, so we never used thread_struct::sp0 for anything. Fix it and mostly unify them. Signed-off-by: Andy Lutomirski <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Denys Vlasenko <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/1b810c1d2e797e27bb4a7708c426101161edd1f6.1426009661.git.luto@amacapital.net Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/asm/entry: Create and use a 'TOP_OF_KERNEL_STACK_PADDING' macroAndy Lutomirski3-2/+30
x86_32, unlike x86_64, pads the top of the kernel stack, because the hardware stack frame formats are variable in size. Document this padding and give it a name. This should make no change whatsoever to the compiled kernel image. It also doesn't fix any of the current bugs in this area. Signed-off-by: Andy Lutomirski <[email protected]> Acked-by: Denys Vlasenko <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/02bf2f54b8dcb76a62a142b6dfe07d4ef7fc582e.1426009661.git.luto@amacapital.net [ Fixed small details, such as a missed magic constant in entry_32.S pointed out by Denys Vlasenko. ] Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/signal/64: Remove 'fs' and 'gs' from sigcontextAndy Lutomirski3-6/+21
As far as I can tell, these fields have been set to zero on save and ignored on restore since Linux was imported into git. Rename them '__pad1' and '__pad2' to avoid confusion. This may also allow us to recycle them some day. This also adds a comment clarifying the history of those fields. I'm intentionally avoiding calling either of them '__pad0': the field formerly known as '__pad0' is now 'ss'. Signed-off-by: Andy Lutomirski <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Cc: Al Viro <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/844f8490e938780c03355be4c9b69eb4c494bf4e.1426193719.git.luto@kernel.org Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17x86/signal/64: Fix SS handling for signals delivered to 64-bit programsAndy Lutomirski3-11/+15
The comment in the signal code says that apps can save/restore other segments on their own. It's true that apps can *save* SS on their own, but there's no way for apps to restore it: SYSCALL effectively resets SS to __USER_DS, so any value that user code tries to load into SS gets lost on entry to sigreturn. This recycles two padding bytes in the segment selector area for SS. While we're at it, we need a second change to make this useful. If the signal we're delivering is caused by a bad SS value, saving that value isn't enough. We need to remove that bad value from the regs before we try to deliver the signal. Oddly, the i386 code already got this right. I suspect that 64-bit programs that try to run 16-bit code and use signals will have a lot of trouble without this. Signed-off-by: Andy Lutomirski <[email protected]> Reviewed-by: Oleg Nesterov <[email protected]> Acked-by: Borislav Petkov <[email protected]> Cc: Al Viro <[email protected]> Cc: H. Peter Anvin <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.luto@kernel.org Signed-off-by: Ingo Molnar <[email protected]>
2015-03-17virtio_mmio: fix access width for mmioMichael S. Tsirkin1-8/+71
Going over the virtio mmio code, I noticed that it doesn't correctly access modern device config values using "natural" accessors: it uses readb to get/set them byte by byte, while the virtio 1.0 spec explicitly states: 4.2.2.2 Driver Requirements: MMIO Device Register Layout ... The driver MUST only use 32 bit wide and aligned reads and writes to access the control registers described in table 4.1. For the device-specific configuration space, the driver MUST use 8 bit wide accesses for 8 bit wide fields, 16 bit wide and aligned accesses for 16 bit wide fields and 32 bit wide and aligned accesses for 32 and 64 bit wide fields. Borrow code from virtio_pci_modern to do this correctly. Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Rusty Russell <[email protected]>
2015-03-17Merge branch 'linux-4.0' of ↵Dave Airlie7-59/+93
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes nouveau fixes, and gm206 modesetting enables. * 'linux-4.0' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: drm/nouveau/bios: fix i2c table parsing for dcb 4.1 drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204) drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switch drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addresses drm/nouveau/fifo/nv04: remove the loop from the interrupt handler
2015-03-17drm/nouveau/bios: fix i2c table parsing for dcb 4.1Stefan Huehner1-1/+5
Code before looked only at bit 31 to decide if a port is unused. However dcb 4.1 spec says 0x1F in bits 31-27 and 26-22 means unused. This fixed hdmi monitor detection on GM206. Signed-off-by: Ben Skeggs <[email protected]>
2015-03-17drm/nouveau/device/gm100: Basic GM206 bring up (as copy of GM204)Stefan Huehner1-0/+43
Enough to get VGA monitor on DVI-I output have output. HDMI output not yet working Signed-off-by: Ben Skeggs <[email protected]>
2015-03-17drm/nouveau/device: post write to NV_PMC_BOOT_1 when flipping endian switchBen Skeggs1-2/+4
fdo#88868 Signed-off-by: Ben Skeggs <[email protected]>
2015-03-17drm/nouveau/gr/gf100: fix some accidental or'ing of buffer addressesBen Skeggs3-6/+6
fdo#83992 Signed-off-by: Ben Skeggs <[email protected]>
2015-03-17drm/nouveau/fifo/nv04: remove the loop from the interrupt handlerBen Skeggs1-50/+35
Complete bong hit (and not the last...), the hardware will reassert the interrupt to PMC if it's necessary. Also potentially harmful in the face of interrupts such as the non-stall interrupt, which remain active in NV_PFIFO_INTR even when we don't care about servicing it. It appears (hopefully, fdo#87244), that under certain loads, the methods may pass quickly enough to hit the "100 spins and kill PFIFO" thing that we had going on. Not ideal ;) Signed-off-by: Ben Skeggs <[email protected]>
2015-03-16Merge tag 'kvm-arm-fixes-4.0-rc5' of ↵Marcelo Tosatti8-75/+105
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm Fixes for KVM/ARM for 4.0-rc5. Fixes page refcounting issues in our Stage-2 page table management code, fixes a missing unlock in a gicv3 error path, and fixes a race that can cause lost interrupts if signals are pending just prior to entering the guest.
2015-03-16drm/radeon: Changing number of compute pipe linesBen Goz1-1/+1
The current CP firmware can handle Usermode Queues only on MEC1. To reflect this firmware change, this commit reduces number of compute pipelines to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd). Signed-off-by: Ben Goz <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Cc: [email protected]
2015-03-16drm/amdkfd: Fix SDMA queue init. in non-HWS modeBen Goz1-1/+9
This patch fixes the SDMA queue initialization, when running in non-HWS mode. The first fix is to move the initialization of SDMA VM parameters before the initialization of the SDMA MQD. The second fix is to load the MQD to an HQD after the initialization of the MQD. Signed-off-by: Ben Goz <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Reviewed-by: Alex Deucher <[email protected]>
2015-03-16drm/amdkfd: destroy mqd when destroying kernel queueBen Goz1-9/+13
This patch adds a missing destruction of mqd, when destroying a kernel queue. Without the destruction, there is a memory leakage when repeatedly creating and destroying kernel queues. Signed-off-by: Ben Goz <[email protected]> Signed-off-by: Oded Gabbay <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-03-16bnx2x: fix encapsulation features on 57710/57711Michal Schmidt1-1/+1
E1x chips (57710, 57711(E)) have no support for encapsulation offload. bnx2x incorrectly advertises the support as available. Setting of those features is conditional on "!CHIP_IS_E1x(bp)", but the bp struct is not initialized yet at this point and consequently any chip passes the check. The check must use the "chip_is_e1x" local variable instead to work correctly. Signed-off-by: Michal Schmidt <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-03-16LZ4 : fix the data abort issueJeHyeon Yeon1-0/+3
If the part of the compression data are corrupted, or the compression data is totally fake, the memory access over the limit is possible. This is the log from my system usning lz4 decompression. [6502]data abort, halting [6503]r0 0x00000000 r1 0x00000000 r2 0xdcea0ffc r3 0xdcea0ffc [6509]r4 0xb9ab0bfd r5 0xdcea0ffc r6 0xdcea0ff8 r7 0xdce80000 [6515]r8 0x00000000 r9 0x00000000 r10 0x00000000 r11 0xb9a98000 [6522]r12 0xdcea1000 usp 0x00000000 ulr 0x00000000 pc 0x820149bc [6528]spsr 0x400001f3 and the memory addresses of some variables at the moment are ref:0xdcea0ffc, op:0xdcea0ffc, oend:0xdcea1000 As you can see, COPYLENGH is 8bytes, so @ref and @op can access the momory over @oend. Signed-off-by: JeHyeon Yeon <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-03-16kernfs: handle poll correctly on 'direct_read' files.NeilBrown1-0/+1
Kernfs supports two styles of read: direct_read and seqfile_read. The latter supports 'poll' correctly thanks to the update of '->event' in kernfs_seq_show. The former does not as '->event' is never updated on a read. So add an appropriate update in kernfs_file_direct_read(). This was noticed because some 'md' sysfs attributes were recently changed to use direct reads. Reported-by: Prakash Punnoor <[email protected]> Reported-by: Torsten Kaiser <[email protected]> Fixes: 750f199ee8b578062341e6ddfe36c59ac8ff2dcb Signed-off-by: NeilBrown <[email protected]> Acked-by: Tejun Heo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-03-16Merge tag 'mac80211-for-davem-2015-03-16' of ↵David S. Miller5-8/+47
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== Here are a few fixes that I'd like to still get in: * disable U-APSD for better interoperability, from Michal Kazior * drop unencrypted frames in mesh forwarding, from Bob Copeland * treat non-QoS/WMM HT stations as non-HT, to fix confusion when they connect and then get QoS packets anyway due to HT * fix counting interfaces for combination checks, otherwise the interface combinations aren't properly enforced (from Andrei) * fix pure ECSA by reacting to the IE change * ignore erroneous (E)CSA to the current channel which sometimes happens due to AP/GO bugs ==================== Signed-off-by: David S. Miller <[email protected]>
2015-03-16Merge branch 'master' of ↵David S. Miller5-8/+10
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2015-03-16 1) Fix the network header offset in _decode_session6 when multiple IPv6 extension headers are present. From Hajime Tazaki. 2) Fix an interfamily tunnel crash. We set outer mode protocol too early and may dispatch to the wrong address family. Move the setting of the outer mode protocol behind the last accessing of the inner mode to fix the crash. 3) Most callers of xfrm_lookup() expect that dst_orig is released on error. But xfrm_lookup_route() may need dst_orig to handle certain error cases. So introduce a flag that tells what should be done in case of error. From Huaibin Wang. Please pull or let me know if there are problems. ==================== Signed-off-by: David S. Miller <[email protected]>
2015-03-16dmaengine: dw: append MODULE_ALIAS for platform driverAndy Shevchenko1-1/+4
The commit 9cade1a46c77 (dma: dw: split driver to library part and platform code) introduced a separate platform driver but missed to add a MODULE_ALIAS("platform:dw_dmac"); to that module. The patch adds this to get driver loaded automatically if platform device is registered. Reported-by: "Blin, Jerome" <[email protected]> Fixes: 9cade1a46c77 (dma: dw: split driver to library part and platform code) Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Vinod Koul <[email protected]>
2015-03-16Revert "Input: synaptics - use dmax in input_mt_assign_slots"Dmitry Torokhov1-4/+1
This reverts commit 6ab17a8484f03c188a93713369912f1545eb26e9 since it, according to Benjamin, causes issues with slot assignment: E: 15.669119 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 15.954242 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 15.954242 0003 0039 0505 # EV_ABS / ABS_MT_TRACKING_ID 505 E: 15.954242 0003 0035 3851 # EV_ABS / ABS_MT_POSITION_X 3851 E: 15.954242 0003 0036 4076 # EV_ABS / ABS_MT_POSITION_Y 4076 E: 15.954242 0003 003a 0034 # EV_ABS / ABS_MT_PRESSURE 34 E: 15.954242 0001 014a 0001 # EV_KEY / BTN_TOUCH 1 E: 15.954242 0003 0000 3851 # EV_ABS / ABS_X 3851 E: 15.954242 0003 0001 4076 # EV_ABS / ABS_Y 4076 E: 15.954242 0003 0018 0034 # EV_ABS / ABS_PRESSURE 34 E: 15.954242 0001 0145 0001 # EV_KEY / BTN_TOOL_FINGER 1 E: 15.954242 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- ... (bunch of regular events)... E: 16.020614 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 16.043601 0003 0035 3873 # EV_ABS / ABS_MT_POSITION_X 3873 E: 16.043601 0003 0036 3903 # EV_ABS / ABS_MT_POSITION_Y 3903 E: 16.043601 0003 003a 0050 # EV_ABS / ABS_MT_PRESSURE 50 E: 16.043601 0003 0035 3032 # EV_ABS / ABS_MT_POSITION_X 3032 E: 16.043601 0003 0036 3832 # EV_ABS / ABS_MT_POSITION_Y 3832 E: 16.043601 0003 003a 0044 # EV_ABS / ABS_MT_PRESSURE 44 E: 16.043601 0003 0000 3032 # EV_ABS / ABS_X 3032 E: 16.043601 0003 0001 3832 # EV_ABS / ABS_Y 3832 E: 16.043601 0003 0018 0044 # EV_ABS / ABS_PRESSURE 44 E: 16.043601 0001 0145 0000 # EV_KEY / BTN_TOOL_FINGER 0 E: 16.043601 0001 014d 0001 # EV_KEY / BTN_TOOL_DOUBLETAP 1 E: 16.043601 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- E: 16.068837 0003 002f 0001 # EV_ABS / ABS_MT_SLOT 1 E: 16.068837 0003 0039 0506 # EV_ABS / ABS_MT_TRACKING_ID 506 E: 16.068837 0003 0035 3912 # EV_ABS / ABS_MT_POSITION_X 3912 E: 16.068837 0003 0036 3743 # EV_ABS / ABS_MT_POSITION_Y 3743 E: 16.068837 0003 003a 0056 # EV_ABS / ABS_MT_PRESSURE 56 E: 16.068837 0003 002f 0000 # EV_ABS / ABS_MT_SLOT 0 E: 16.068837 0003 0035 3026 # EV_ABS / ABS_MT_POSITION_X 3026 E: 16.068837 0003 0036 3708 # EV_ABS / ABS_MT_POSITION_Y 3708 E: 16.068837 0003 003a 0052 # EV_ABS / ABS_MT_PRESSURE 52 E: 16.068837 0003 0000 3026 # EV_ABS / ABS_X 3026 E: 16.068837 0003 0001 3708 # EV_ABS / ABS_Y 3708 E: 16.068837 0003 0018 0052 # EV_ABS / ABS_PRESSURE 52 E: 16.068837 0000 0000 0000 # ------------ SYN_REPORT (0) ---------- Slot 0 and 1 gets inverted in the second report above, which introduces a cursor jump. The problem is that this cursor jump is often enough to leave the current widget, and X sends the scrolling events to whoever is now under the cursor. Reported-by: Benjamin Tissoires <[email protected]> Reported-by: Hans de Goede <[email protected]>
2015-03-16Merge branch 'synaptics' into for-linusDmitry Torokhov2-51/+184
Bring in changes needed to properly handle Lenovo 2015 lineup.
2015-03-16ALSA: hda - Treat stereo-to-mono mix properlyTakashi Iwai2-10/+49
The commit [ef403edb7558: ALSA: hda - Don't access stereo amps for mono channel widgets] fixed the handling of mono widgets in general, but it still misses an exceptional case: namely, a mono mixer widget taking a single stereo input. In this case, it has stereo volumes although it's a mono widget, and thus we have to take care of both left and right input channels, as stated in HD-audio spec ("7.1.3 Widget Interconnection Rules"). This patch covers this missing piece by adding proper checks of stereo amps in both the generic parser and the proc output codes. Reported-by: Raymond Yau <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.