The Brain Fuck Scheduler v0.446 by Con Kolivas.

A single shared runqueue O(n) strict fairness earliest deadline first design.

Excellent throughput and latency for 1 to many CPUs on desktop and server
commodity hardware.
Not recommended for 4096 cpus.

Scalability is optimal when your workload is equal to the number of CPUs on
bfs. ie you should ONLY do make -j4 on quad core, -j2 on dual core and so on.

Features SCHED_IDLEPRIO and SCHED_ISO scheduling policies as well.
You do NOT need to use these policies for good performance, they are purely
optional for even better performance in extreme conditions.

To run something idleprio, use schedtool like so:

schedtool -D -e make -j4

To run something isoprio, use schedtool like so:

schedtool -I -e amarok

Includes accurate sub-tick accounting of tasks so userspace reported
cpu usage may be very different if you have very short lived tasks.

-ck
Fix BFS circle dead lock.
ck-3.12: fix BFS compiling with CONFIG_SMP=n
ck-3.12: force disabling BOOTPARAM_HOTPLUG_CPU0 with BFS enabled
Merge branch 'ck-3.14' into pf-3.14
configs-3.14: update dell-vostro-3360.config against unofficial BFS
distro-3.14: cleanup Arch-specific files
Merge branch 'configs-3.14' into pf-3.14
Merge branch 'distro-3.14' into pf-3.14
kvm: replace cond_resched() with schedule()

	This commit tries to fix qemu CPU soft-lock while using
	>=2 vCPU per guest with BFS enabled. The trick is stolen
	from here:
	https://bugzilla.redhat.com/show_bug.cgi?id=1038929#c5
Merge branch 'ck-3.14' into pf-3.14
fixes-3.14: remove useless warning

debloat script causes warning on changing qdisc for inactive
interface. I don't like that.

[  +0.843777] ------------[ cut here ]------------
[  +0.000014] WARNING: CPU: 2 PID: 1939 at net/sched/sch_api.c:279 qdisc_list_add+0x6e/0x80()
[  +0.000003] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core videodev media ath3k btusb bluetooth 6lowpan_iphc
xt_conn
track iptable_filter xt_TCPMSS xt_tcpudp iptable_mangle ipt_MASQUERADE iptable_nat bridge stp llc nf_conntrack_ipv4 nf_defrag_ipv4
nf_nat_ipv4 nf_nat
 nf_conntrack ip_tables x_tables x86_pkg_temp_thermal intel_powerclamp crct10dif_pclmul crc32_pclmul nls_cp437 vfat fat crc32c_intel dell_wmi
sparse_
keymap iTCO_wdt iTCO_vendor_support ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd dell_laptop dcdbas
wmi arc
4 evdev microcode psmouse(O) serio_raw lpc_ich mfd_core snd_hda_codec_hdmi alx mdio i2c_i801 ath9k ath9k_common ath9k_hw ath mac80211
cfg80211 rfkill
 snd_hda_codec_cirrus snd_hda_codec_generic snd_hda_intel snd_hda_codec
[  +0.000082]  snd_hwdep snd_pcm snd_timer snd soundcore tcp_yeah tcp_vegas msr kvm_intel kvm autofs4 efivarfs sd_mod crc_t10dif
crct10dif_common ehc
i_pci xhci_hcd ehci_hcd ahci libahci libata scsi_mod usbcore usb_common
[  +0.000031] CPU: 2 PID: 1939 Comm: tc Tainted: G           O 3.14.0-pf1 #1
[  +0.000003] Hardware name: Dell Inc.          Vostro 3360/0F5DWF, BIOS A18 09/25/2013
[  +0.000003]  0000000000000009 ffff880422689948 ffffffff815dfd7f 0000000000000000
[  +0.000007]  ffff880422689980 ffffffff8105e72d ffff880426834a00 ffffffff81aa6e80
[  +0.000006]  ffff88042739e000 ffff880426835000 ffff88042739e000 ffff880422689990
[  +0.000005] Call Trace:
[  +0.000009]  [<ffffffff815dfd7f>] dump_stack+0x4d/0x6f
[  +0.000007]  [<ffffffff8105e72d>] warn_slowpath_common+0x7d/0xa0
[  +0.000006]  [<ffffffff8105e80a>] warn_slowpath_null+0x1a/0x20
[  +0.000005]  [<ffffffff8151e4de>] qdisc_list_add+0x6e/0x80
[  +0.000005]  [<ffffffff8151cac7>] mq_attach+0x77/0xa0
[  +0.000006]  [<ffffffff8151e1cf>] qdisc_graft+0x15f/0x2b0
[  +0.000006]  [<ffffffff8151fd34>] tc_modify_qdisc+0x4c4/0x580
[  +0.000006]  [<ffffffff8150a2a9>] rtnetlink_rcv_msg+0x99/0x260
[  +0.000006]  [<ffffffff814ea96e>] ? __alloc_skb+0x7e/0x1d0
[  +0.000004]  [<ffffffff8150a210>] ? rtnetlink_rcv+0x30/0x30
[  +0.000006]  [<ffffffff81528c39>] netlink_rcv_skb+0xa9/0xc0
[  +0.000004]  [<ffffffff8150a208>] rtnetlink_rcv+0x28/0x30
[  +0.000005]  [<ffffffff81528198>] netlink_unicast+0xe8/0x1c0
[  +0.000005]  [<ffffffff81528679>] netlink_sendmsg+0x359/0x760
[  +0.000005]  [<ffffffff81525ea4>] ? netlink_rcv_wake+0x44/0x60
[  +0.000006]  [<ffffffff8129c4b4>] ? tomoyo_socket_sendmsg_permission+0x24/0xb0
[  +0.000006]  [<ffffffff814dff40>] sock_sendmsg+0xa0/0xc0
[  +0.000007]  [<ffffffff811566e9>] ? __do_fault+0x3c9/0x500
[  +0.000005]  [<ffffffff814e1930>] ? move_addr_to_kernel+0x40/0x90
[  +0.000005]  [<ffffffff814e18e3>] ___sys_sendmsg+0x373/0x380
[  +0.000006]  [<ffffffff8104eab4>] ? __do_page_fault+0x1d4/0x4d0
[  +0.000006]  [<ffffffff814e2382>] ? SyS_sendto+0x112/0x150
[  +0.000005]  [<ffffffff814e27c2>] __sys_sendmsg+0x42/0x80
[  +0.000005]  [<ffffffff814e2812>] SyS_sendmsg+0x12/0x20
[  +0.000006]  [<ffffffff815e7669>] system_call_fastpath+0x16/0x1b
[  +0.000003] ---[ end trace 9aea4b24782a1224 ]---
Merge branch 'fixes-3.14' into pf-3.14
block, bfq: restore MODULE_LICENSE() macro

Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com>
Merge branch 'bfq-3.14' into pf-3.14
Revert "ALSA: hda - Increment default stream numbers for AMD HDMI controllers"

This reverts commit 7546abfb8e1f9933b549f05898377e9444ee4cb2.

The commit [7546abfb: ALSA: hda - Increment default stream numbers for
AMD HDMI controllers] introduced a regression where the AMD HDMI
playback streams don't work properly.  As the simplest fix, this patch
reverts that commit.

The upstream code has been changed largely and already contains
another fix (by changing the stream assignment order), this revert
should be applied only to 3.14 kernel where the regression was
introduced.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77002
Reported-by: Christian Güdel <cg@dmesg.ch>
Reported-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
selinux: correctly label /proc inodes in use before the policy is loaded

commit f64410ec665479d7b4b77b7519e814253ed0f686 upstream.

This patch is based on an earlier patch by Eric Paris, he describes
the problem below:

  "If an inode is accessed before policy load it will get placed on a
   list of inodes to be initialized after policy load.  After policy
   load we call inode_doinit() which calls inode_doinit_with_dentry()
   on all inodes accessed before policy load.  In the case of inodes
   in procfs that means we'll end up at the bottom where it does:

     /* Default to the fs superblock SID. */
     isec->sid = sbsec->sid;

     if ((sbsec->flags & SE_SBPROC) && !S_ISLNK(inode->i_mode)) {
             if (opt_dentry) {
                     isec->sclass = inode_mode_to_security_class(...)
                     rc = selinux_proc_get_sid(opt_dentry,
                                               isec->sclass,
                                               &sid);
                     if (rc)
                             goto out_unlock;
                     isec->sid = sid;
             }
     }

   Since opt_dentry is null, we'll never call selinux_proc_get_sid()
   and will leave the inode labeled with the label on the superblock.
   I believe a fix would be to mimic the behavior of xattrs.  Look
   for an alias of the inode.  If it can't be found, just leave the
   inode uninitialized (and pick it up later) if it can be found, we
   should be able to call selinux_proc_get_sid() ..."

On a system exhibiting this problem, you will notice a lot of files in
/proc with the generic "proc_t" type (at least the ones that were
accessed early in the boot), for example:

   # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
   system_u:object_r:proc_t:s0 /proc/sys/kernel/shmmax

However, with this patch in place we see the expected result:

   # ls -Z /proc/sys/kernel/shmmax | awk '{ print $4 " " $5 }'
   system_u:object_r:sysctl_kernel_t:s0 /proc/sys/kernel/shmmax

Cc: Eric Paris <eparis@redhat.com>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86, pageattr: Export page unmapping interface

commit 42a5477251f0e0f33ad5f6a95c48d685ec03191e upstream.

We will use it in efi so expose it.

Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
x86/efi: Make efi virtual runtime map passing more robust

commit b7b898ae0c0a82489511a1ce1b35f26215e6beb5 upstream.

Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of resizing
the memmap we're doing did allocate from such physical addresses which
were not mapped anymore and boom:

http://lkml.kernel.org/r/1386806463.1791.295.camel@misato.fc.hp.com

One way to take care of that issue is to reimplement the krealloc thing
but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
and when we deplete that memory (shouldn't happen all that often but you
know firmware) we realloc the next power-of-two pages.

Having the pages, it is much more handy and easy to map them into the
EFI page table with the already existing mapping code which we're using
for building the virtual mappings.

Thanks to Toshi Kani and Matt for the great debugging help.

Reported-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
futex: avoid race between requeue and wake

commit 69cd9eba38867a493a043bb13eb9b33cad5f1a9a upstream.

Jan Stancek reported:
 "pthread_cond_broadcast/4-1.c testcase from openposix testsuite (LTP)
  occasionally fails, because some threads fail to wake up.

  Testcase creates 5 threads, which are all waiting on same condition.
  Main thread then calls pthread_cond_broadcast() without holding mutex,
  which calls:

      futex(uaddr1, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, uaddr2, ..)

  This immediately wakes up single thread A, which unlocks mutex and
  tries to wake up another thread:

      futex(uaddr2, FUTEX_WAKE_PRIVATE, 1)

  If thread A manages to call futex_wake() before any waiters are
  requeued for uaddr2, no other thread is woken up"

The ordering constraints for the hash bucket waiter counting are that
the waiter counts have to be incremented _before_ getting the spinlock
(because the spinlock acts as part of the memory barrier), but the
"requeue" operation didn't honor those rules, and nobody had even
thought about that case.

This fairly simple patch just increments the waiter count for the target
hash bucket (hb2) when requeing a futex before taking the locks.  It
then decrements them again after releasing the lock - the code that
actually moves the futex(es) between hash buckets will do the additional
required waiter count housekeeping.

Reported-and-tested-by: Jan Stancek <jstancek@redhat.com>
Acked-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>