--- /dev/null
+From f56c3196f251012de9b3ebaff55732a9074fdaae Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 22 Jan 2013 16:15:15 -0800
+Subject: async: fix __lowest_in_progress()
+
+From: Tejun Heo <tj@kernel.org>
+
+commit f56c3196f251012de9b3ebaff55732a9074fdaae upstream.
+
+Commit 083b804c4d3e ("async: use workqueue for worker pool") made it
+possible that async jobs are moved from pending to running out-of-order.
+While pending async jobs will be queued and dispatched for execution in
+the same order, nothing guarantees they'll enter "1) move self to the
+running queue" of async_run_entry_fn() in the same order.
+
+Before the conversion, async implemented its own worker pool. An async
+worker, upon being woken up, fetches the first item from the pending
+list, which kept the executing lists sorted. The conversion to
+workqueue was done by adding work_struct to each async_entry and async
+just schedules the work item. The queueing and dispatching of such work
+items are still in order but now each worker thread is associated with a
+specific async_entry and moves that specific async_entry to the
+executing list. So, depending on which worker reaches that point
+earlier, which is non-deterministic, we may end up moving an async_entry
+with larger cookie before one with smaller one.
+
+This broke __lowest_in_progress(). running->domain may not be properly
+sorted and is not guaranteed to contain lower cookies than pending list
+when not empty. Fix it by ensuring sort-inserting to the running list
+and always looking at both pending and running when trying to determine
+the lowest cookie.
+
+Over time, the async synchronization implementation became quite messy.
+We better restructure it such that each async_entry is linked to two
+lists - one global and one per domain - and not move it when execution
+starts. There's no reason to distinguish pending and running. They
+behave the same for synchronization purposes.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Cc: Arjan van de Ven <arjan@linux.intel.com>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/async.c | 27 ++++++++++++++++++++-------
+ 1 file changed, 20 insertions(+), 7 deletions(-)
+
+--- a/kernel/async.c
++++ b/kernel/async.c
+@@ -86,18 +86,27 @@ static atomic_t entry_count;
+ */
+ static async_cookie_t __lowest_in_progress(struct async_domain *running)
+ {
++ async_cookie_t first_running = next_cookie; /* infinity value */
++ async_cookie_t first_pending = next_cookie; /* ditto */
+ struct async_entry *entry;
+
++ /*
++ * Both running and pending lists are sorted but not disjoint.
++ * Take the first cookies from both and return the min.
++ */
+ if (!list_empty(&running->domain)) {
+ entry = list_first_entry(&running->domain, typeof(*entry), list);
+- return entry->cookie;
++ first_running = entry->cookie;
+ }
+
+- list_for_each_entry(entry, &async_pending, list)
+- if (entry->running == running)
+- return entry->cookie;
++ list_for_each_entry(entry, &async_pending, list) {
++ if (entry->running == running) {
++ first_pending = entry->cookie;
++ break;
++ }
++ }
+
+- return next_cookie; /* "infinity" value */
++ return min(first_running, first_pending);
+ }
+
+ static async_cookie_t lowest_in_progress(struct async_domain *running)
+@@ -118,13 +127,17 @@ static void async_run_entry_fn(struct wo
+ {
+ struct async_entry *entry =
+ container_of(work, struct async_entry, work);
++ struct async_entry *pos;
+ unsigned long flags;
+ ktime_t uninitialized_var(calltime), delta, rettime;
+ struct async_domain *running = entry->running;
+
+- /* 1) move self to the running queue */
++ /* 1) move self to the running queue, make sure it stays sorted */
+ spin_lock_irqsave(&async_lock, flags);
+- list_move_tail(&entry->list, &running->domain);
++ list_for_each_entry_reverse(pos, &running->domain, list)
++ if (entry->cookie < pos->cookie)
++ break;
++ list_move_tail(&entry->list, &pos->list);
+ spin_unlock_irqrestore(&async_lock, flags);
+
+ /* 2) run (and print duration) */
--- /dev/null
+From a67adb997419fb53540d4a4f79c6471c60bc69b6 Mon Sep 17 00:00:00 2001
+From: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
+Date: Fri, 18 Jan 2013 23:56:39 +0200
+Subject: evm: checking if removexattr is not a NULL
+
+From: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
+
+commit a67adb997419fb53540d4a4f79c6471c60bc69b6 upstream.
+
+The following lines of code produce a kernel oops.
+
+fd = socket(PF_FILE, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0);
+fchmod(fd, 0666);
+
+[ 139.922364] BUG: unable to handle kernel NULL pointer dereference at (null)
+[ 139.924982] IP: [< (null)>] (null)
+[ 139.924982] *pde = 00000000
+[ 139.924982] Oops: 0000 [#5] SMP
+[ 139.924982] Modules linked in: fuse dm_crypt dm_mod i2c_piix4 serio_raw evdev binfmt_misc button
+[ 139.924982] Pid: 3070, comm: acpid Tainted: G D 3.8.0-rc2-kds+ #465 Bochs Bochs
+[ 139.924982] EIP: 0060:[<00000000>] EFLAGS: 00010246 CPU: 0
+[ 139.924982] EIP is at 0x0
+[ 139.924982] EAX: cf5ef000 EBX: cf5ef000 ECX: c143d600 EDX: c15225f2
+[ 139.924982] ESI: cf4d2a1c EDI: cf4d2a1c EBP: cc02df10 ESP: cc02dee4
+[ 139.924982] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
+[ 139.924982] CR0: 80050033 CR2: 00000000 CR3: 0c059000 CR4: 000006d0
+[ 139.924982] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
+[ 139.924982] DR6: ffff0ff0 DR7: 00000400
+[ 139.924982] Process acpid (pid: 3070, ti=cc02c000 task=d7705340 task.ti=cc02c000)
+[ 139.924982] Stack:
+[ 139.924982] c1203c88 00000000 cc02def4 cf4d2a1c ae21eefa 471b60d5 1083c1ba c26a5940
+[ 139.924982] e891fb5e 00000041 00000004 cc02df1c c1203964 00000000 cc02df4c c10e20c3
+[ 139.924982] 00000002 00000000 00000000 22222222 c1ff2222 cf5ef000 00000000 d76efb08
+[ 139.924982] Call Trace:
+[ 139.924982] [<c1203c88>] ? evm_update_evmxattr+0x5b/0x62
+[ 139.924982] [<c1203964>] evm_inode_post_setattr+0x22/0x26
+[ 139.924982] [<c10e20c3>] notify_change+0x25f/0x281
+[ 139.924982] [<c10cbf56>] chmod_common+0x59/0x76
+[ 139.924982] [<c10e27a1>] ? put_unused_fd+0x33/0x33
+[ 139.924982] [<c10cca09>] sys_fchmod+0x39/0x5c
+[ 139.924982] [<c13f4f30>] syscall_call+0x7/0xb
+[ 139.924982] Code: Bad EIP value.
+
+This happens because sockets do not define the removexattr operation.
+Before removing the xattr, verify the removexattr function pointer is
+not NULL.
+
+Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com>
+Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
+Signed-off-by: James Morris <james.l.morris@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/integrity/evm/evm_crypto.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/security/integrity/evm/evm_crypto.c
++++ b/security/integrity/evm/evm_crypto.c
+@@ -205,9 +205,9 @@ int evm_update_evmxattr(struct dentry *d
+ rc = __vfs_setxattr_noperm(dentry, XATTR_NAME_EVM,
+ &xattr_data,
+ sizeof(xattr_data), 0);
+- }
+- else if (rc == -ENODATA)
++ } else if (rc == -ENODATA && inode->i_op->removexattr) {
+ rc = inode->i_op->removexattr(dentry, XATTR_NAME_EVM);
++ }
+ return rc;
+ }
+
--- /dev/null
+From c1bf08ac26e92122faab9f6c32ea8aba94612dae Mon Sep 17 00:00:00 2001
+From: Steven Rostedt <srostedt@redhat.com>
+Date: Fri, 14 Dec 2012 09:48:15 -0500
+Subject: ftrace: Be first to run code modification on modules
+
+From: Steven Rostedt <srostedt@redhat.com>
+
+commit c1bf08ac26e92122faab9f6c32ea8aba94612dae upstream.
+
+If some other kernel subsystem has a module notifier, and adds a kprobe
+to a ftrace mcount point (now that kprobes work on ftrace points),
+when the ftrace notifier runs it will fail and disable ftrace, as well
+as kprobes that are attached to ftrace points.
+
+Here's the error:
+
+ WARNING: at kernel/trace/ftrace.c:1618 ftrace_bug+0x239/0x280()
+ Hardware name: Bochs
+ Modules linked in: fat(+) stap_56d28a51b3fe546293ca0700b10bcb29__8059(F) nfsv4 auth_rpcgss nfs dns_resolver fscache xt_nat iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack lockd sunrpc ppdev parport_pc parport microcode virtio_net i2c_piix4 drm_kms_helper ttm drm i2c_core [last unloaded: bid_shared]
+ Pid: 8068, comm: modprobe Tainted: GF 3.7.0-0.rc8.git0.1.fc19.x86_64 #1
+ Call Trace:
+ [<ffffffff8105e70f>] warn_slowpath_common+0x7f/0xc0
+ [<ffffffff81134106>] ? __probe_kernel_read+0x46/0x70
+ [<ffffffffa0180000>] ? 0xffffffffa017ffff
+ [<ffffffffa0180000>] ? 0xffffffffa017ffff
+ [<ffffffff8105e76a>] warn_slowpath_null+0x1a/0x20
+ [<ffffffff810fd189>] ftrace_bug+0x239/0x280
+ [<ffffffff810fd626>] ftrace_process_locs+0x376/0x520
+ [<ffffffff810fefb7>] ftrace_module_notify+0x47/0x50
+ [<ffffffff8163912d>] notifier_call_chain+0x4d/0x70
+ [<ffffffff810882f8>] __blocking_notifier_call_chain+0x58/0x80
+ [<ffffffff81088336>] blocking_notifier_call_chain+0x16/0x20
+ [<ffffffff810c2a23>] sys_init_module+0x73/0x220
+ [<ffffffff8163d719>] system_call_fastpath+0x16/0x1b
+ ---[ end trace 9ef46351e53bbf80 ]---
+ ftrace failed to modify [<ffffffffa0180000>] init_once+0x0/0x20 [fat]
+ actual: cc:bb:d2:4b:e1
+
+A kprobe was added to the init_once() function in the fat module on load.
+But this happened before ftrace could have touched the code. As ftrace
+didn't run yet, the kprobe system had no idea it was a ftrace point and
+simply added a breakpoint to the code (0xcc in the cc:bb:d2:4b:e1).
+
+Then when ftrace went to modify the location from a call to mcount/fentry
+into a nop, it didn't see a call op, but instead it saw the breakpoint op
+and not knowing what to do with it, ftrace shut itself down.
+
+The solution is to simply give the ftrace module notifier the max priority.
+This should have been done regardless, as the core code ftrace modification
+also happens very early on in boot up. This makes the module modification
+closer to core modification.
+
+Link: http://lkml.kernel.org/r/20130107140333.593683061@goodmis.org
+
+Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
+Reported-by: Frank Ch. Eigler <fche@redhat.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+
+---
+ kernel/trace/ftrace.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/trace/ftrace.c
++++ b/kernel/trace/ftrace.c
+@@ -3998,7 +3998,7 @@ static int ftrace_module_notify(struct n
+
+ struct notifier_block ftrace_module_nb = {
+ .notifier_call = ftrace_module_notify,
+- .priority = 0,
++ .priority = INT_MAX, /* Run before anything that can use kprobes */
+ };
+
+ extern unsigned long __start_mcount_loc[];
--- /dev/null
+From a706d965dcfdff73bf2bad1c300f8119900714c7 Mon Sep 17 00:00:00 2001
+From: David Ahern <dsahern@gmail.com>
+Date: Fri, 28 Dec 2012 19:56:07 -0700
+Subject: perf x86: revert 20b279 - require exclude_guest to use PEBS - kernel side
+
+From: David Ahern <dsahern@gmail.com>
+
+commit a706d965dcfdff73bf2bad1c300f8119900714c7 upstream.
+
+This patch is brought to you by the letter 'H'.
+
+Commit 20b279 breaks compatiblity with older perf binaries when run with
+precise modifier (:p or :pp) by requiring the exclude_guest attribute to be
+set. Older binaries default exclude_guest to 0 (ie., wanting guest-based
+samples) unless host only profiling is requested (:H modifier). The workaround
+for older binaries is to add H to the modifier list (e.g., -e cycles:ppH -
+toggles exclude_guest to 1). This was deemed unacceptable by Linus:
+
+https://lkml.org/lkml/2012/12/12/570
+
+Between family in town and the fresh snow in Breckenridge there is no time left
+to be working on the proper fix for this over the holidays. In the New Year I
+have more pressing problems to resolve -- like some memory leaks in perf which
+are proving to be elusive -- although the aforementioned snow is probably why
+they are proving to be elusive. Either way I do not have any spare time to work
+on this and from the time I have managed to spend on it the solution is more
+difficult than just moving to a new exclude_guest flag (does not work) or
+flipping the logic to include_guest (which is not as trivial as one would
+think).
+
+So, two options: silently force exclude_guest on as suggested by Gleb which
+means no impact to older perf binaries or revert the original patch which
+caused the breakage.
+
+This patch does the latter -- reverts the original patch that introduced the
+regression. The problem can be revisited in the future as time allows.
+
+Signed-off-by: David Ahern <dsahern@gmail.com>
+Cc: Avi Kivity <avi@redhat.com>
+Cc: Gleb Natapov <gleb@redhat.com>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Robert Richter <robert.richter@amd.com>
+Link: http://lkml.kernel.org/r/1356749767-17322-1-git-send-email-dsahern@gmail.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/perf_event.c | 6 ------
+ 1 file changed, 6 deletions(-)
+
+--- a/arch/x86/kernel/cpu/perf_event.c
++++ b/arch/x86/kernel/cpu/perf_event.c
+@@ -340,9 +340,6 @@ int x86_setup_perfctr(struct perf_event
+ /* BTS is currently only allowed for user-mode. */
+ if (!attr->exclude_kernel)
+ return -EOPNOTSUPP;
+-
+- if (!attr->exclude_guest)
+- return -EOPNOTSUPP;
+ }
+
+ hwc->config |= config;
+@@ -385,9 +382,6 @@ int x86_pmu_hw_config(struct perf_event
+ if (event->attr.precise_ip) {
+ int precise = 0;
+
+- if (!event->attr.exclude_guest)
+- return -EOPNOTSUPP;
+-
+ /* Support for constant skid */
+ if (x86_pmu.pebs_active && !x86_pmu.pebs_broken) {
+ precise++;
libata-ahci-fix-lack-of-command-retry-after-a-success-error-handler.patch
libata-ahci-add-support-for-enmotus-bobcat-device.patch
libata-replace-sata_settings-with-devslp_timing.patch
+ftrace-be-first-to-run-code-modification-on-modules.patch
+evm-checking-if-removexattr-is-not-a-null.patch
+virtio-blk-don-t-free-ida-when-disk-is-in-use.patch
+async-fix-__lowest_in_progress.patch
+vfio-pci-fix-buffer-overfill.patch
+perf-x86-revert-20b279-require-exclude_guest-to-use-pebs-kernel-side.patch
--- /dev/null
+From ec1287e511320a2c9a02640b7ac02d5d79f56f08 Mon Sep 17 00:00:00 2001
+From: Alex Williamson <alex.williamson@redhat.com>
+Date: Tue, 15 Jan 2013 10:45:26 -0700
+Subject: vfio-pci: Fix buffer overfill
+
+From: Alex Williamson <alex.williamson@redhat.com>
+
+commit ec1287e511320a2c9a02640b7ac02d5d79f56f08 upstream.
+
+A read from a range hidden from the user (ex. MSI-X vector table)
+attempts to fill the user buffer up to the end of the excluded range
+instead of up to the requested count. Fix it.
+
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vfio/pci/vfio_pci_rdwr.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/vfio/pci/vfio_pci_rdwr.c
++++ b/drivers/vfio/pci/vfio_pci_rdwr.c
+@@ -240,17 +240,17 @@ ssize_t vfio_pci_mem_readwrite(struct vf
+ filled = 1;
+ } else {
+ /* Drop writes, fill reads with FF */
++ filled = min((size_t)(x_end - pos), count);
+ if (!iswrite) {
+ char val = 0xFF;
+ size_t i;
+
+- for (i = 0; i < x_end - pos; i++) {
++ for (i = 0; i < filled; i++) {
+ if (put_user(val, buf + i))
+ goto out;
+ }
+ }
+
+- filled = x_end - pos;
+ }
+
+ count -= filled;
--- /dev/null
+From f4953fe6c4aeada2d5cafd78aa97587a46d2d8f9 Mon Sep 17 00:00:00 2001
+From: Alexander Graf <agraf@suse.de>
+Date: Wed, 2 Jan 2013 15:37:17 +1030
+Subject: virtio-blk: Don't free ida when disk is in use
+
+From: Alexander Graf <agraf@suse.de>
+
+commit f4953fe6c4aeada2d5cafd78aa97587a46d2d8f9 upstream.
+
+When a file system is mounted on a virtio-blk disk, we then remove it
+and then reattach it, the reattached disk gets the same disk name and
+ids as the hot removed one.
+
+This leads to very nasty effects - mostly rendering the newly attached
+device completely unusable.
+
+Trying what happens when I do the same thing with a USB device, I saw
+that the sd node simply doesn't get free'd when a device gets forcefully
+removed.
+
+Imitate the same behavior for vd devices. This way broken vd devices
+simply are never free'd and newly attached ones keep working just fine.
+
+Signed-off-by: Alexander Graf <agraf@suse.de>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/virtio_blk.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/block/virtio_blk.c
++++ b/drivers/block/virtio_blk.c
+@@ -889,6 +889,7 @@ static void __devexit virtblk_remove(str
+ {
+ struct virtio_blk *vblk = vdev->priv;
+ int index = vblk->index;
++ int refc;
+
+ /* Prevent config work handler from accessing the device. */
+ mutex_lock(&vblk->config_lock);
+@@ -903,11 +904,15 @@ static void __devexit virtblk_remove(str
+
+ flush_work(&vblk->config_work);
+
++ refc = atomic_read(&disk_to_dev(vblk->disk)->kobj.kref.refcount);
+ put_disk(vblk->disk);
+ mempool_destroy(vblk->pool);
+ vdev->config->del_vqs(vdev);
+ kfree(vblk);
+- ida_simple_remove(&vd_index_ida, index);
++
++ /* Only free device id if we don't have any users */
++ if (refc == 1)
++ ida_simple_remove(&vd_index_ida, index);
+ }
+
+ #ifdef CONFIG_PM
projects / thirdparty / kernel / stable-queue.git / commitdiff
