- 09 Jan, 2014 26 commits
-
-
Catalin Marinas authored
commit 4ecf7ccb upstream. An exclusive store instruction may fail for reasons other than lock contention (e.g. a cache eviction during the critical section) so, in line with other architectures using similar exclusive instructions (alpha, mips, powerpc), retry the trylock operation if the lock appears to be free but the strex reported failure. Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Tony Thompson <anthony.thompson@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Cc: Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Will Deacon authored
commit cdc27c27 upstream. Commit 8f34a1da ("arm64: ptrace: use HW_BREAKPOINT_EMPTY type for disabled breakpoints") fixed an issue with GDB trying to zero breakpoint control registers. The problem there is that the arch hw_breakpoint code will attempt to create a (disabled), execute breakpoint of length 0. This will fail validation and report unexpected failure to GDB. To avoid this, we treated disabled breakpoints as HW_BREAKPOINT_EMPTY, but that seems to have broken with recent kernels, causing watchpoints to be treated as TYPE_INST in the core code and returning ENOSPC for any further breakpoints. This patch fixes the problem by prioritising the `enable' field of the breakpoint: if it is cleared, we simply update the perf_event_attr to indicate that the thing is disabled and don't bother changing either the type or the length. This reinforces the behaviour that the breakpoint control register is essentially read-only apart from the enable bit when disabling a breakpoint. Reported-by:
Aaron Liu <liucy214@gmail.com> Signed-off-by:
-
Miao Xie authored
commit c4602c1c upstream. Ftrace currently initializes only the online CPUs. This implementation has two problems: - If we online a CPU after we enable the function profile, and then run the test, we will lose the trace information on that CPU. Steps to reproduce: # echo 0 > /sys/devices/system/cpu/cpu1/online # cd <debugfs>/tracing/ # echo <some function name> >> set_ftrace_filter # echo 1 > function_profile_enabled # echo 1 > /sys/devices/system/cpu/cpu1/online # run test - If we offline a CPU before we enable the function profile, we will not clear the trace information when we enable the function profile. It will trouble the users. Steps to reproduce: # cd <debugfs>/tracing/ # echo <some function name> >> set_ftrace_filter # echo 1 > function_profile_enabled # run test # cat trace_stat/function* # echo 0 > /sys/devices/system/cpu/cpu1/online # echo 0 > function_profile_enabled # echo 1 > function_profile_enabled # cat trace_stat/function* # run test # cat trace_stat/function* So it is better that we initialize the ftrace profiler for each possible cpu every time we enable the function profile instead of just the online ones. Link: http://lkml.kernel.org/r/1387178401-10619-1-git-send-email-miaox@cn.fujitsu.comSigned-off-by:
Miao Xie <miaox@cn.fujitsu.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Nicholas Bellinger authored
commit 95cadace upstream. This patch allows FILEIO to update hw_max_sectors based on the current max_bytes_per_io. This is required because vfs_[writev,readv]() can accept a maximum of 2048 iovecs per call, so the enforced hw_max_sectors really needs to be calculated based on block_size. This addresses a >= v3.5 bug where block_size=512 was rejecting > 1M sized I/O requests, because FD_MAX_SECTORS was hardcoded to 2048 for the block_size=4096 case. (v2: Use max_bytes_per_io instead of ->update_hw_max_sectors) Reported-by:
Henrik Goldman <hg@x-formation.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Nicholas Bellinger authored
commit 4454b66c upstream. This patch changes special case handling for ISCSI_OP_SCSI_CMD where an initiator sends a zero length Expected Data Transfer Length (EDTL), but still sets the WRITE and/or READ flag bits when no payload transfer is requested. Many, many moons ago two special cases where added for an ancient version of ESX that has long since been fixed, so instead of adding a new special case for the reported bug with a Broadcom 57800 NIC, go ahead and always strip off the incorrect WRITE + READ flag bits. Also, avoid sending a reject here, as RFC-3720 does mandate this case be handled without protocol error. Reported-by:
Witold Bazakbal <865perl@wp.pl> Tested-by:
-
Wei Yongjun authored
commit 94a71110 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Oleg Nesterov authored
commit c0c14395 upstream. selinux_setprocattr() does ptrace_parent(p) under task_lock(p), but task_struct->alloc_lock doesn't pin ->parent or ->ptrace, this looks confusing and triggers the "suspicious RCU usage" warning because ptrace_parent() does rcu_dereference_check(). And in theory this is wrong, spin_lock()->preempt_disable() doesn't necessarily imply rcu_read_lock() we need to access the ->parent. Reported-by:
Evan McNabb <emcnabb@redhat.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Chad Hanson authored
commit 46d01d63 upstream. Fix a broken networking check. Return an error if peer recv fails. If secmark is active and the packet recv succeeds the peer recv error is ignored. Signed-off-by:
Chad Hanson <chanson@trustedcs.com> Signed-off-by:
-
Bjørn Mork authored
commit 4144bc86 upstream. Reported-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Acked-by:
-
Marc Kleine-Budde authored
commit 20fb4eb9 upstream. This patch fixes a memory leak in pcan_usb_pro_init(). In patch f14e2243 net: can: peak_usb: Do not do dma on the stack the struct pcan_usb_pro_fwinfo *fi and struct pcan_usb_pro_blinfo *bi were converted from stack to dynamic allocation va kmalloc(). However the corresponding kfree() was not introduced. This patch adds the missing kfree(). Reported-by:
Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Dmitry Kunilov authored
commit 52d0dc75 upstream. ZTE AC2726 EVDO modem drops ppp connection every minute when driven by zte_ev but works fine when driven by option. Move the support for AC2726 back to option driver. Signed-off-by:
Dmitry Kunilov <dmitry.kunilov@gmail.com> Signed-off-by:
-
Mika Westerberg authored
commit d24c195f upstream. Newer Intel PCHs with LPSS have the same Designware controllers than Haswell but ACPI IDs are different. Add these IDs to the driver list. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Jonathan Cameron authored
commit e39d9905 upstream. Note this also sets the endianness to big endian whereas it would previously have defaulted to the cpu endian. Hence technically this is a bug fix on LE platforms. Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Acked-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Jonathan Cameron authored
commit 3425c0f7 upstream. A single channel in this driver was using the IIO_ST macro. This does not provide a parameter for setting the endianness of the channel. Thus this channel will have been reported as whatever is the native endianness of the cpu rather than big endian. This means it would be incorrect on little endian platforms. Signed-off-by:
-
David Henningsson authored
commit 693e0cb0 upstream. While enabling these machines, we found we would sometimes lose an interrupt if we change hardware volume during playback, and that disabling msi fixed this issue. (Losing the interrupt caused underruns and crackling audio, as the one second timeout is usually bigger than the period size.) The machines were all machines from HP, running AMD Hudson controller, and Realtek ALC282 codec. BugLink: https://bugs.launchpad.net/bugs/1260225Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
JongHo Kim authored
commit ed697e1a upstream. When the process is sleeping at the SNDRV_PCM_STATE_PAUSED state from the wait_for_avail function, the sleep process will be woken by timeout(10 seconds). Even if the sleep process wake up by timeout, by this patch, the process will continue with sleep and wait for the other state. Signed-off-by:
JongHo Kim <furmuwon@gmail.com> Signed-off-by:
-
Charles Keepax authored
commit 280484e7 upstream. Reported-by:
Kyung-Kwee Ryu <kyung-kwee.ryu@wolfsonmicro.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Charles Keepax authored
commit 939fd1e8 upstream. Some devices are getting very close to the limit whilst polling the RAM start, this patch adds a small delay to this loop to give a longer startup timeout. Signed-off-by:
-
Bo Shen authored
commit f0199bc5 upstream. When wm8904 work in DSP mode B, we still need to configure it to work in DSP mode. Or else, it will work in Right Justified mode. Signed-off-by:
Bo Shen <voice.shen@atmel.com> Acked-by:
-
Stephen Warren authored
commit 241bf433 upstream. In tegra*_i2s_set_fmt(), in the (fmt == SND_SOC_DAIFMT_CBM_CFM) case, "val" is never assigned to, but left uninitialized. The other case does initialized it. Fix this by initializing val at the start of the function, and only ever ORing into it. Update the handling of "mask" so it works the same way for consistency. Update tegra20_spdif.c to use the same code-style for consistency, even though it doesn't happen to suffer from the same problem at present. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Ian Abbott authored
commit 0283f7a1 upstream. At some point, Measurement Computing / ComputerBoards redesigned the PCI-DIO48H to use a PLX PCI interface chip instead of an AMCC chip. This meant they had to put their hardware registers in the PCI BAR 2 region instead of PCI BAR 1. Unfortunately, they kept the same PCI device ID for the new design. This means the driver recognizes the newer cards, but doesn't work (and is likely to screw up the local configuration registers of the PLX chip) because it's using the wrong region. Since the PCI subvendor and subdevice IDs were both zero on the old design, but are the same as the vendor and device on the new design, we can tell the old design and new design apart easily enough. Split the existing entry for the PCI-DIO48H in `pci_8255_boards[]` into two new entries, referenced by different entries in the PCI device ID table `pci_8255_pci_table[]`. Use the same board name for both entries. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Acked-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Signed-off-by:
-
Geert Uytterhoeven authored
commit dc1dc2f8 upstream. When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" on the kernel command line, it crashes with: Unable to handle kernel NULL pointer dereference at virtual address (null) Oops: 00000000 PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 ... Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 The normal tty driver doesn't crash, because init_pmz() checks pmz_ports_count again after calling pmz_probe(). In the serial console initialization path, pmz_console_init() doesn't do this, causing the driver to crash later. Add a check for pmz_ports_count to fix this. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
pingfan liu authored
commit 91648ec0 upstream. Since kvmppc_hv_find_lock_hpte() is called from both virtmode and realmode, so it can trigger the deadlock. Suppose the following scene: Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of vcpus. If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be caught in realmode for a long time. What makes things even worse if the following happens, On cpuM, bitlockX is hold, on cpuN, Y is hold. vcpu_B_2 try to lock Y on cpuM in realmode vcpu_A_2 try to lock X on cpuN in realmode Oops! deadlock happens Signed-off-by:
Liu Ping Fan <pingfank@linux.vnet.ibm.com> Reviewed-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Yan, Zheng authored
commit fc55d2c9 upstream. We also need to wake up 'safe' waiters if error occurs or request aborted. Otherwise sync(2)/fsync(2) may hang forever. Signed-off-by:
Yan, Zheng <zheng.z.yan@intel.com> Signed-off-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Yan, Zheng authored
commit eb1b8af3 upstream. Aborted requests usually get cleared when the reply is received. If MDS crashes, no reply will be received. So we need to cleanup aborted requests when re-sending requests. Signed-off-by:
Greg Farnum <greg@inktank.com> Signed-off-by:
-
Johan Hovold authored
commit 6f648546 upstream. Fix race in generic write implementation, which could lead to temporarily degraded throughput. The current generic write implementation introduced by commit 27c7acf2 ("USB: serial: reimplement generic fifo-based writes") has always had this bug, although it's fairly hard to trigger and the consequences are not likely to be noticed. Specifically, a write() on one CPU while the completion handler is running on another could result in only one of the two write urbs being utilised to empty the remainder of the write fifo (unless there is a second write() that doesn't race during that time). Signed-off-by:
Johan Hovold <jhovold@gmail.com> Signed-off-by:
-
- 20 Dec, 2013 14 commits
-
-
Greg Kroah-Hartman authored
-
Roger Quadros authored
commit 313a76ee upstream. In _ocp_softreset(), after _set_softreset() + write_sysconfig(), the hwmod's sysc_cache will always contain SOFTRESET bit set so all further writes to sysconfig using this cache will initiate a repeated SOFTRESET e.g. enable_sysc(). This is true for OMAP3 like platforms that have RESET_DONE status in the SYSSTATUS register and so the the SOFTRESET bit in SYSCONFIG is not automatically cleared. It is not a problem for OMAP4 like platforms that indicate RESET completion by clearing the SOFTRESET bit in the SYSCONFIG register. This repeated SOFTRESET is undesired and was the root cause of USB host issues on OMAP3 platforms when hwmod was allowed to do the SOFTRESET for the USB Host module. To fix this we clear the SOFTRESET bit and update the sysconfig register + sysc_cache using write_sysconfig(). Signed-off-by:
Roger Quadros <rogerq@ti.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> # Panda, BeagleXM [paul@pwsan.com: renamed _clr_softreset() to _clear_softreset()] Signed-off-by:
Paul Walmsley <paul@pwsan.com> Signed-off-by:
-
Liu Bo authored
commit 6f519564 upstream. If something wrong happens in write endio, running snapshot-aware defragment can end up with undefined results, maybe a crash, so we should avoid it. In order to share similar code, this also adds a helper to free the struct for snapshot-aware defrag. Signed-off-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
Chris Mason <chris.mason@fusionio.com> Signed-off-by:
-
Filipe David Borba Manana authored
commit 8185554d upstream. When a directory has a default ACL and a subdirectory is created under that directory, btrfs_init_acl() is called when the subdirectory's inode is created to initialize the inode's ACL (inherited from the parent directory) but it was clearing the ACL from the inode after setting it if posix_acl_create() returned success, instead of clearing it only if it returned an error. To reproduce this issue: $ mkfs.btrfs -f /dev/loop0 $ mount /dev/loop0 /mnt $ mkdir /mnt/acl $ setfacl -d --set u::rwx,g::rwx,o::- /mnt/acl $ getfacl /mnt/acl user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:other::--- $ mkdir /mnt/acl/dir1 $ getfacl /mnt/acl/dir1 user::rwx group::rwx other::--- After unmounting and mounting again the filesystem, fgetacl returned the expected ACL: $ umount /mnt/acl $ mount /dev/loop0 /mnt $ getfacl /mnt/acl/dir1 user::rwx group::rwx other::--- default:user::rwx default:group::rwx default:other::--- Meaning that the underlying xattr was persisted. Reported-by:
Giuseppe Fierro <giuseppe@fierro.org> Signed-off-by:
Filipe David Borba Manana <fdmanana@gmail.com> Signed-off-by:
-
Josef Bacik authored
commit ed9e8af8 upstream. I added an assert to make sure we were looking up aligned offsets for csums and I tripped it when running xfstests. This is because log_one_extent was checking if block_start == 0 for a hole instead of EXTENT_MAP_HOLE. This worked out fine in practice it seems, but it adds a lot of extra work that is uneeded. With this fix I'm no longer tripping my assert. Thanks, Signed-off-by:
-
Liu Bo authored
commit 7d3d1744 upstream. As we're hold a ref on looking up the extent map, we need to drop the ref before returning to callers. Signed-off-by:
-
Greg Kroah-Hartman authored
It turns out that commit: d3f7d56a was applied to the tree twice, which didn't hurt anything, but it's good to fix this up. Reported-by:
Veaceslav Falico <veaceslav@falico.eu> Cc: David S. Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: Shawn Landden <shawnlandden@gmail.com> Cc: Tom Herbert <therbert@google.com> Signed-off-by:
-
Nicolas Dichtel authored
The upstream commit bb814094 ("ip6tnl: allow to use rtnl ops on fb tunnel") (backported into linux-3.10.y) left a bug which was fixed upstream by commit 1e9f3d6f ("ip6tnl: fix use after free of fb_tnl_dev"). The problem is a bit different in linux-3.10.y, because there is no x-netns support (upstream commit 0bd87628 ("ip6tnl: add x-netns support")). When ip6_tunnel.ko is unloaded, FB device is deleted by rtnl_link_unregister() and then we try to delete it again in ip6_tnl_destroy_tunnels(). This patch removes the second deletion. Reported-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Andy Adamson authored
commit 4a82fd7c upstream. When the state manager is processing the NFS4CLNT_DELEGRETURN flag, session draining is off, but DELEGRETURN can still get a session error. The async handler calls nfs4_schedule_session_recovery returns -EAGAIN, and the DELEGRETURN done then restarts the RPC task in the prepare state. With the state manager still processing the NFS4CLNT_DELEGRETURN flag with session draining off, these DELEGRETURNs will cycle with errors filling up the session slots. This prevents OPEN reclaims (from nfs_delegation_claim_opens) required by the NFS4CLNT_DELEGRETURN state manager processing from completing, hanging the state manager in the __rpc_wait_for_completion_task in nfs4_run_open_task as seen in this kernel thread dump: kernel: 4.12.32.53-ma D 0000000000000000 0 3393 2 0x00000000 kernel: ffff88013995fb60 0000000000000046 ffff880138cc5400 ffff88013a9df140 kernel: ffff8800000265c0 ffffffff8116eef0 ffff88013fc10080 0000000300000001 kernel: ffff88013a4ad058 ffff88013995ffd8 000000000000fbc8 ffff88013a4ad058 kernel: Call Trace: kernel: [<ffffffff8116eef0>] ? cache_alloc_refill+0x1c0/0x240 kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc] kernel: [<ffffffffa0358152>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc] kernel: [<ffffffff8152914f>] __wait_on_bit+0x5f/0x90 kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc] kernel: [<ffffffff815291f8>] out_of_line_wait_on_bit+0x78/0x90 kernel: [<ffffffff8109b520>] ? wake_bit_function+0x0/0x50 kernel: [<ffffffffa035810d>] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc] kernel: [<ffffffffa040d44c>] nfs4_run_open_task+0x11c/0x160 [nfs] kernel: [<ffffffffa04114e7>] nfs4_open_recover_helper+0x87/0x120 [nfs] kernel: [<ffffffffa0411646>] nfs4_open_recover+0xc6/0x150 [nfs] kernel: [<ffffffffa040cc6f>] ? nfs4_open_recoverdata_alloc+0x2f/0x60 [nfs] kernel: [<ffffffffa0414e1a>] nfs4_open_delegation_recall+0x6a/0xa0 [nfs] kernel: [<ffffffffa0424020>] nfs_end_delegation_return+0x120/0x2e0 [nfs] kernel: [<ffffffff8109580f>] ? queue_work+0x1f/0x30 kernel: [<ffffffffa0424347>] nfs_client_return_marked_delegations+0xd7/0x110 [nfs] kernel: [<ffffffffa04225d8>] nfs4_run_state_manager+0x548/0x620 [nfs] kernel: [<ffffffffa0422090>] ? nfs4_run_state_manager+0x0/0x620 [nfs] kernel: [<ffffffff8109b0f6>] kthread+0x96/0xa0 kernel: [<ffffffff8100c20a>] child_rip+0xa/0x20 kernel: [<ffffffff8109b060>] ? kthread+0x0/0xa0 kernel: [<ffffffff8100c200>] ? child_rip+0x0/0x20 The state manager can not therefore process the DELEGRETURN session errors. Change the async handler to wait for recovery on session errors. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Alan authored
commit dace8bbf upstream. If loaded with isapnp = 0 the driver explodes. This is catching people out now and then. What should happen in the working case is a complete mystery and the code appears terminally confused, but we can at least make the error path work properly. Signed-off-by:
Alan Cox <alan@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Partially-Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=53991Signed-off-by:
-
H Hartley Sweeten authored
commit f6b316bc upstream. Use comedi_dio_update_state() to handle the boilerplate code to update the subdevice s->state. Also, fix a bug where the state of the channels is returned in data[0]. The comedi core expects it to be returned in data[1]. Signed-off-by:
-
H Hartley Sweeten authored
commit 97f4289a upstream. [Split from original patch subject: "staging: comedi: drivers: use comedi_dio_update_state() for simple cases"] Use comedi_dio_update_state() to handle the boilerplate code to update the subdevice s->state for simple cases where the hardware is updated when any channel is modified. Also, fix a bug in the amplc_pc263 and amplc_pci263 drivers where the current state is not returned in data[1]. Signed-off-by:
-
Ian Abbott authored
commit 2fd2bdfc upstream. pcmuio_detach() is called by the comedi core even if pcmuio_attach() returned an error, so `dev->private` might be `NULL`. Check for that before dereferencing it. Also, as pointed out by Dan Carpenter, there is no need to check the pointer passed to `kfree()` is non-NULL, so remove that check. Signed-off-by:
-
Ben Segall authored
commit f9f9ffc2 upstream. throttle_cfs_rq() doesn't check to make sure that period_timer is running, and while update_curr/assign_cfs_runtime does, a concurrently running period_timer on another cpu could cancel itself between this cpu's update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running in the tg to restart the timer, this causes the cfs_rq to be stranded forever. Fix this by calling __start_cfs_bandwidth() in throttle if the timer is inactive. (Also add some sched_debug lines for cfs_bandwidth.) Tested: make a run/sleep task in a cgroup, loop switching the cgroup between 1ms/100ms quota and unlimited, checking for timer_active=0 and throttled=1 as a failure. With the throttle_cfs_rq() change commented out this fails, with the full patch it passes. Signed-off-by:
Ben Segall <bsegall@google.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: pjt@google.com Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
