GitHub PushEvent at 2014-11-10 02:12:15
Repository: android_kernel_htc_ruby
Actor: JoseGalRe
Payload: {"shas":[["7cc835745183631e6fd0ec173e4942942a508191","4596b3305151c7ee743192a95d394341e3d3b644@suse.de","ASoC: sta32x: Fix wrong enum for limiter2 release rate\n\ncommit b3619b288b621e63f66908045f48495869a996a6 upstream.\n\nThere is a typo in the Limiter2 Release Rate control, a wrong enum for\nLimiter1 is assigned.  It must point to Limiter2.\nSpotted by a compile warning:\n\nIn file included from sound/soc/codecs/sta32x.c:34:0:\nsound/soc/codecs/sta32x.c:223:29: warning: ‘sta32x_limiter2_release_rate_enum’ defined but not used [-Wunused-variable]\n static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,\n                             ^\ninclude/sound/soc.h:275:18: note: in definition of macro ‘SOC_ENUM_DOUBLE_DECL’\n  struct soc_enum name = SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, \\\n                  ^\nsound/soc/codecs/sta32x.c:223:8: note: in expansion of macro ‘SOC_ENUM_SINGLE_DECL’\n static SOC_ENUM_SINGLE_DECL(sta32x_limiter2_release_rate_enum,\n        ^\n\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Mark Brown <broonie@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Takashi Iwai",false],["71a3a9e7d1b783ab7a61a82361f3849d4592ece1","4596b3305151c7ee743192a95d394341e3d3b644@suse.de","ASoC: sta32x: Fix array access overflow\n\ncommit 025c3fa9256d4c54506b7a29dc3befac54f5c68d upstream.\n\nPreset EQ enum of sta32x codec driver declares too many number of\nitems and it may lead to the access over the actual array size.\n\nUse SOC_ENUM_SINGLE_DECL() helper and it's automatically fixed.\n\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nAcked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>\nAcked-by: Lars-Peter Clausen <lars@metafoo.de>\nSigned-off-by: Mark Brown <broonie@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Takashi Iwai",false],["52b418e832d133f5fa657efae0ca0fa87242fe2c","3318dc5ce3e4fb7c28a0b841b6801c884e1d0896@metafoo.de","ASoC: wm8958-dsp: Fix firmware block loading\n\ncommit 548da08fc1e245faf9b0d7c41ecd8e07984fc332 upstream.\n\nThe codec->control_data contains a pointer to the device's regmap struct. But\nwm8994_bulk_write() expects a pointer to the parent wm8998 device.\n\nThe issue was introduced in commit d9a7666f (\"ASoC: Remove ASoC-specific\nWM8994 I/O code\").\n\nFixes: d9a7666f (\"ASoC: Remove ASoC-specific WM8994 I/O code\")\nSigned-off-by: Lars-Peter Clausen <lars@metafoo.de>\nSigned-off-by: Mark Brown <broonie@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Lars-Peter Clausen",false],["5dd00a93ea27897deb79e23797f7ced6910e7979","cc958843532c615cbd4920e868f78c7985331a5a@primarydata.com","SUNRPC: Fix races in xs_nospace()\n\ncommit 06ea0bfe6e6043cb56a78935a19f6f8ebc636226 upstream.\n\nWhen a send failure occurs due to the socket being out of buffer space,\nwe call xs_nospace() in order to have the RPC task wait until the\nsocket has drained enough to make it worth while trying again.\nThe current patch fixes a race in which the socket is drained before\nwe get round to setting up the machinery in xs_nospace(), and which\nis reported to cause hangs.\n\nLink: http://lkml.kernel.org/r/20140210170315.33dfc621@notabene.brown\nFixes: a9a6b52ee1ba (SUNRPC: Don't start the retransmission timer...)\nReported-by: Neil Brown <neilb@suse.com>\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Trond Myklebust",false],["8dd74be4a175ff8f5818a14a9c13aa027b667cf6","a59ffce977ae3d39bdc87f81ff88b229ad58db88@linux.vnet.ibm.com","powerpc/crashdump : Fix page frame number check in copy_oldmem_page\n\ncommit f5295bd8ea8a65dc5eac608b151386314cb978f1 upstream.\n\nIn copy_oldmem_page, the current check using max_pfn and min_low_pfn to\ndecide if the page is backed or not, is not valid when the memory layout is\nnot continuous.\n\nThis happens when running as a QEMU/KVM guest, where RTAS is mapped higher\nin the memory. In that case max_pfn points to the end of RTAS, and a hole\nbetween the end of the kdump kernel and RTAS is not backed by PTEs. As a\nconsequence, the kdump kernel is crashing in copy_oldmem_page when accessing\nin a direct way the pages in that hole.\n\nThis fix relies on the memblock's service memblock_is_region_memory to\ncheck if the read page is part or not of the directly accessible memory.\n\nSigned-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>\nTested-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>\nSigned-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Laurent Dufour",false],["494dac8e333e873cb5266ede3be957680d6194ad","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","perf/x86: Fix event scheduling\n\ncommit 26e61e8939b1fe8729572dabe9a9e97d930dd4f6 upstream.\n\nVince \"Super Tester\" Weaver reported a new round of syscall fuzzing (Trinity) failures,\nwith perf WARN_ON()s triggering. He also provided traces of the failures.\n\nThis is I think the relevant bit:\n\n\t>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_disable: x86_pmu_disable\n\t>    pec_1076_warn-2804  [000] d...   147.926153: x86_pmu_state: Events: {\n\t>    pec_1076_warn-2804  [000] d...   147.926156: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))\n\t>    pec_1076_warn-2804  [000] d...   147.926158: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)\n\t>    pec_1076_warn-2804  [000] d...   147.926159: x86_pmu_state: }\n\t>    pec_1076_warn-2804  [000] d...   147.926160: x86_pmu_state: n_events: 1, n_added: 0, n_txn: 1\n\t>    pec_1076_warn-2804  [000] d...   147.926161: x86_pmu_state: Assignment: {\n\t>    pec_1076_warn-2804  [000] d...   147.926162: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)\n\t>    pec_1076_warn-2804  [000] d...   147.926163: x86_pmu_state: }\n\t>    pec_1076_warn-2804  [000] d...   147.926166: collect_events: Adding event: 1 (ffff880119ec8800)\n\nSo we add the insn:p event (fd[23]).\n\nAt this point we should have:\n\n  n_events = 2, n_added = 1, n_txn = 1\n\n\t>    pec_1076_warn-2804  [000] d...   147.926170: collect_events: Adding event: 0 (ffff8800c9e01800)\n\t>    pec_1076_warn-2804  [000] d...   147.926172: collect_events: Adding event: 4 (ffff8800cbab2c00)\n\nWe try and add the {BP,cycles,br_insn} group (fd[3], fd[4], fd[15]).\nThese events are 0:cycles and 4:br_insn, the BP event isn't x86_pmu so\nthat's not visible.\n\n\tgroup_sched_in()\n\t  pmu->start_txn() /* nop - BP pmu */\n\t  event_sched_in()\n\t     event->pmu->add()\n\nSo here we should end up with:\n\n  0: n_events = 3, n_added = 2, n_txn = 2\n  4: n_events = 4, n_added = 3, n_txn = 3\n\nBut seeing the below state on x86_pmu_enable(), the must have failed,\nbecause the 0 and 4 events aren't there anymore.\n\nLooking at group_sched_in(), since the BP is the leader, its\nevent_sched_in() must have succeeded, for otherwise we would not have\nseen the sibling adds.\n\nBut since neither 0 or 4 are in the below state; their event_sched_in()\nmust have failed; but I don't see why, the complete state: 0,0,1:p,4\nfits perfectly fine on a core2.\n\nHowever, since we try and schedule 4 it means the 0 event must have\nsucceeded!  Therefore the 4 event must have failed, its failure will\nhave put group_sched_in() into the fail path, which will call:\n\n\tevent_sched_out()\n\t  event->pmu->del()\n\non 0 and the BP event.\n\nNow x86_pmu_del() will reduce n_events; but it will not reduce n_added;\ngiving what we see below:\n\n n_event = 2, n_added = 2, n_txn = 2\n\n\t>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_enable: x86_pmu_enable\n\t>    pec_1076_warn-2804  [000] d...   147.926177: x86_pmu_state: Events: {\n\t>    pec_1076_warn-2804  [000] d...   147.926179: x86_pmu_state:   0: state: .R config: ffffffffffffffff (          (null))\n\t>    pec_1076_warn-2804  [000] d...   147.926181: x86_pmu_state:   33: state: AR config: 0 (ffff88011ac99800)\n\t>    pec_1076_warn-2804  [000] d...   147.926182: x86_pmu_state: }\n\t>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: n_events: 2, n_added: 2, n_txn: 2\n\t>    pec_1076_warn-2804  [000] d...   147.926184: x86_pmu_state: Assignment: {\n\t>    pec_1076_warn-2804  [000] d...   147.926186: x86_pmu_state:   0->33 tag: 1 config: 0 (ffff88011ac99800)\n\t>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state:   1->0 tag: 1 config: 1 (ffff880119ec8800)\n\t>    pec_1076_warn-2804  [000] d...   147.926188: x86_pmu_state: }\n\t>    pec_1076_warn-2804  [000] d...   147.926190: x86_pmu_enable: S0: hwc->idx: 33, hwc->last_cpu: 0, hwc->last_tag: 1 hwc->state: 0\n\nSo the problem is that x86_pmu_del(), when called from a\ngroup_sched_in() that fails (for whatever reason), and without x86_pmu\nTXN support (because the leader is !x86_pmu), will corrupt the n_added\nstate.\n\nReported-and-Tested-by: Vince Weaver <vincent.weaver@maine.edu>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nCc: Paul Mackerras <paulus@samba.org>\nCc: Steven Rostedt <rostedt@goodmis.org>\nCc: Stephane Eranian <eranian@google.com>\nCc: Dave Jones <davej@redhat.com>\nLink: http://lkml.kernel.org/r/20140221150312.GF3104@twins.programming.kicks-ass.net\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Peter Zijlstra",false],["13e60b225fc1f8394447363dc3ce02899badc99e","0e1ddfe761f44f291037b4efb98a5f5f36ee23b3@openvz.org","ata: enable quirk from jmicron JMB350 for JMB394\n\ncommit efb9e0f4f43780f0ae0c6428d66bd03e805c7539 upstream.\n\nWithout the patch the kernel generates the following error.\n\n ata11.15: SATA link up 1.5 Gbps (SStatus 113 SControl 310)\n ata11.15: Port Multiplier vendor mismatch '0x197b' != '0x123'\n ata11.15: PMP revalidation failed (errno=-19)\n ata11.15: failed to recover PMP after 5 tries, giving up\n\nThis patch helps to bypass this error and the device becomes\nfunctional.\n\nSigned-off-by: Denis V. Lunev <den@openvz.org>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nCc: <linux-ide@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Denis V. Lunev",false],["31d183aa91d4220afc6429e8b9578aa436a3597d","546b05909706652891a87f7bfe385ae147f61f91@kernel.org","sata_sil: apply MOD15WRITE quirk to TOSHIBA MK2561GSYN\n\ncommit 9f9c47f00ce99329b1a82e2ac4f70f0fe3db549c upstream.\n\nIt's a bit odd to see a newer device showing mod15write; however, the\nreported behavior is highly consistent and other factors which could\ncontribute seem to have been verified well enough.  Also, both\nsata_sil itself and the drive are fairly outdated at this point making\nthe risk of this change fairly low.  It is possible, probably likely,\nthat other drive models in the same family have the same problem;\nhowever, for now, let's just add the specific model which was tested.\n\nSigned-off-by: Tejun Heo <tj@kernel.org>\nReported-by: matson <lists-matsonpa@luxsci.me>\nReferences: http://lkml.kernel.org/g/201401211912.s0LJCk7F015058@rs103.luxsci.com\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Tejun Heo",false],["9f84cff07159c0b21b3725a216c3f3d615f93b7c","efca98801f3398ebd7eeff805a2c18e6c49e84d4@suse.de","i7core_edac: Fix PCI device reference count\n\ncommit c0f5eeed0f4cef4f05b74883a7160e7edde58b6a upstream.\n\nThe reference count changes done by pci_get_device can be a little\nmisleading when the usage diverges from the most common scheme. The\nreference count of the device passed as the last parameter is always\ndecreased, even if the function returns no new device. So if we are\ngoing to try alternative device IDs, we must manually increment the\ndevice reference count before each retry. If we don't, we end up\ndecreasing the reference count, and after a few modprobe/rmmod cycles\nthe PCI devices will vanish.\n\nIn other words and as Alan put it: without this fix the EDAC code\ncorrupts the PCI device list.\n\nThis fixes kernel bug #50491:\nhttps://bugzilla.kernel.org/show_bug.cgi?id=50491\n\nSigned-off-by: Jean Delvare <jdelvare@suse.de>\nLink: http://lkml.kernel.org/r/20140224093927.7659dd9d@endymion.delvare\nReviewed-by: Alan Cox <alan@linux.intel.com>\nCc: Mauro Carvalho Chehab <m.chehab@samsung.com>\nCc: Doug Thompson <dougthompson@xmission.com>\nSigned-off-by: Borislav Petkov <bp@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jean Delvare",false],["b0b0c264549a424a453bf21ba41941db83f0899b","9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com","ACPI / video: Filter the _BCL table for duplicate brightness values\n\ncommit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 upstream.\n\nSome devices have duplicate entries in there brightness levels table, ie\non my Dell Latitude E6430 the table looks like this:\n\n[    3.686060] acpi backlight index   0, val 80\n[    3.686095] acpi backlight index   1, val 50\n[    3.686122] acpi backlight index   2, val 5\n[    3.686147] acpi backlight index   3, val 5\n[    3.686172] acpi backlight index   4, val 5\n[    3.686197] acpi backlight index   5, val 5\n[    3.686223] acpi backlight index   6, val 5\n[    3.686248] acpi backlight index   7, val 5\n[    3.686273] acpi backlight index   8, val 6\n[    3.686332] acpi backlight index   9, val 7\n[    3.686356] acpi backlight index  10, val 8\n[    3.686380] acpi backlight index  11, val 9\netc.\n\nNotice that brightness values 0-5 are all mapped to 5. This means that\nif userspace writes any value between 0 and 5 to the brightness sysfs attribute\nand then reads it, it will always return 0, which is somewhat unexpected.\n\nThis is a problem for ie gnome-settings-daemon, which uses read-modify-write\nlogic when the users presses the brightness up or down keys. This is done\nthis way to take brightness changes from other sources into account.\n\nOn this specific laptop what happens once the brightness has been set to 0,\nis that gsd reads 0, adds 5, writes 5, and on the next brightness up key press\nagain reads 0, so things get stuck at the lowest brightness setting.\n\nFiltering out the duplicate table entries, makes any write to brightness\nread back as the written value as one would expect, fixing this.\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\nReviewed-by: Aaron Lu <aaron.lu@intel.com>\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Hans de Goede",false],["1d0230273dea6597819c4fe9f64f5bb891241578","4221d0916eb5c472a0ab46f0107445bbb3e8a589@intel.com","ACPI / processor: Rework processor throttling with work_on_cpu()\n\ncommit f3ca4164529b875374c410193bbbac0ee960895f upstream.\n\nacpi_processor_set_throttling() uses set_cpus_allowed_ptr() to make\nsure that the (struct acpi_processor)->acpi_processor_set_throttling()\ncallback will run on the right CPU.  However, the function may be\ncalled from a worker thread already bound to a different CPU in which\ncase that won't work.\n\nMake acpi_processor_set_throttling() use work_on_cpu() as appropriate\ninstead of abusing set_cpus_allowed_ptr().\n\nReported-and-tested-by: Jiri Olsa <jolsa@redhat.com>\nSigned-off-by: Lan Tianyu <tianyu.lan@intel.com>\n[rjw: Changelog]\nSigned-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Lan Tianyu",false],["f922754e32d72b890ad471b5efd76b38c25f7d17","c78ce1f14afe451e7304fa93729985d7f1c1cc8c@aleksander.es","USB: serial: option: blacklist interface 4 for Cinterion PHS8 and PXS8\n\ncommit 12df84d4a80278a5b1abfec3206795291da52fc9 upstream.\n\nThis interface is to be handled by the qmi_wwan driver.\n\nCC: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>\nCC: Christian Schmiedl <christian.schmiedl@gemalto.com>\nCC: Nicolaus Colberg <nicolaus.colberg@gemalto.com>\nCC: David McCullough <david.mccullough@accelecon.com>\nSigned-off-by: Aleksander Morgado <aleksander@aleksander.es>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Aleksander Morgado",false],["564a4d6c3205fc001579c00a0ce19b665f860487","f49f2a5e660787beb1d0033eaaa9f0d533955c60@dorchain.net","USB: ftdi_sio: add Cressi Leonardo PID\n\ncommit 6dbd46c849e071e6afc1e0cad489b0175bca9318 upstream.\n\nHello,\n\nthe following patch adds an entry for the PID of a Cressi Leonardo\ndiving computer interface to kernel 3.13.0.\nIt is detected as FT232RL.\nWorks with subsurface.\n\nSigned-off-by: Joerg Dorchain <joerg@dorchain.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Joerg Dorchain",false],["8d36299431351e5c3a893d9c1eae7579ebc57ad5","ba324ca7b1c77fc20bb970d5aff6eea9377918a5@roeck-us.net","hwmon: (max1668) Fix writing the minimum temperature\n\ncommit 500a91571f0a5d0d3242d83802ea2fd1faccc66e upstream.\n\nWhen trying to set the minimum temperature, the driver was erroneously\nwriting the maximum temperature into the chip.\n\nSigned-off-by: Guenter Roeck <linux@roeck-us.net>\nReviewed-by: Jean Delvare <jdelvare@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Guenter Roeck",false],["23f0913c2b3816b11f32dcf774758b3f63b81f60","4c9eb49378914b743bdd32292c04df29b820d73e@cn.fujitsu.com","workqueue: ensure @task is valid across kthread_stop()\n\ncommit 5bdfff96c69a4d5ab9c49e60abf9e070ecd2acbb upstream.\n\nWhen a kworker should die, the kworkre is notified through WORKER_DIE\nflag instead of kthread_should_stop().  This, IIRC, is primarily to\nkeep the test synchronized inside worker_pool lock.  WORKER_DIE is\nfirst set while holding pool->lock, the lock is dropped and\nkthread_stop() is called.\n\nUnfortunately, this means that there's a slight chance that the target\nkworker may see WORKER_DIE before kthread_stop() finishes and exits\nand frees the target task before or during kthread_stop().\n\nFix it by pinning the target task before setting WORKER_DIE and\nputting it after kthread_stop() is done.\n\ntj: Improved patch description and comment.  Moved pinning above\n    WORKER_DIE for better signify what it's protecting.\n\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Lai Jiangshan",false],["f80747a43fc2613b9f5e1ded16f50ef28815652e","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","perf: Fix hotplug splat\n\ncommit e3703f8cdfcf39c25c4338c3ad8e68891cca3731 upstream.\n\nDrew Richardson reported that he could make the kernel go *boom* when hotplugging\nwhile having perf events active.\n\nIt turned out that when you have a group event, the code in\n__perf_event_exit_context() fails to remove the group siblings from\nthe context.\n\nWe then proceed with destroying and freeing the event, and when you\nre-plug the CPU and try and add another event to that CPU, things go\n*boom* because you've still got dead entries there.\n\nReported-by: Drew Richardson <drew.richardson@arm.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nCc: Will Deacon <will.deacon@arm.com>\nLink: http://lkml.kernel.org/n/tip-k6v5wundvusvcseqj1si0oz0@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Peter Zijlstra",false],["186ef2385c50ee6b2232f2ab8edb354ca71332bf","b0b36e3cd9ea4e5739ff430a3056fabf2fdb0376@redhat.com","SELinux: bigendian problems with filename trans rules\n\ncommit 9085a6422900092886da8c404e1c5340c4ff1cbf upstream.\n\nWhen writing policy via /sys/fs/selinux/policy I wrote the type and class\nof filename trans rules in CPU endian instead of little endian.  On\nx86_64 this works just fine, but it means that on big endian arch's like\nppc64 and s390 userspace reads the policy and converts it from\nle32_to_cpu.  So the values are all screwed up.  Write the values in le\nformat like it should have been to start.\n\nSigned-off-by: Eric Paris <eparis@redhat.com>\nAcked-by:  Stephen Smalley <sds@tycho.nsa.gov>\nSigned-off-by: Paul Moore <pmoore@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Eric Paris",false],["54499e71eccdeab9295af9150e3ffb99223447a8","596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","quota: Fix race between dqput() and dquot_scan_active()\n\ncommit 1362f4ea20fa63688ba6026e586d9746ff13a846 upstream.\n\nCurrently last dqput() can race with dquot_scan_active() causing it to\ncall callback for an already deactivated dquot. The race is as follows:\n\nCPU1\t\t\t\t\tCPU2\n  dqput()\n    spin_lock(&dq_list_lock);\n    if (atomic_read(&dquot->dq_count) > 1) {\n     - not taken\n    if (test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) {\n      spin_unlock(&dq_list_lock);\n      ->release_dquot(dquot);\n        if (atomic_read(&dquot->dq_count) > 1)\n         - not taken\n\t\t\t\t\t  dquot_scan_active()\n\t\t\t\t\t    spin_lock(&dq_list_lock);\n\t\t\t\t\t    if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))\n\t\t\t\t\t     - not taken\n\t\t\t\t\t    atomic_inc(&dquot->dq_count);\n\t\t\t\t\t    spin_unlock(&dq_list_lock);\n        - proceeds to release dquot\n\t\t\t\t\t    ret = fn(dquot, priv);\n\t\t\t\t\t     - called for inactive dquot\n\nFix the problem by making sure possible ->release_dquot() is finished by\nthe time we call the callback and new calls to it will notice reference\ndquot_scan_active() has taken and bail out.\n\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jan Kara",false],["8d8e4839b5457e20e371a5f7485ce7855c7870c9","9cd9d802d23c0ed5e224beabf4ae4a5c478746ef@linaro.org","dma: ste_dma40: don't dereference free:d descriptor\n\ncommit e9baa9d9d520fb0e24cca671e430689de2d4a4b2 upstream.\n\nIt appears that in the DMA40 driver the DMA tasklet will very\noften dereference memory for a descriptor just free:d from the\nDMA40 slab. Nothing happens because no other part of the driver\nhas yet had a chance to claim this memory, but it's really\nnasty to dereference free:d memory, so let's check the flag\nbefore the descriptor is free and store it in a bool variable.\n\nReported-by: Dan Carpenter <dan.carpenter@oracle.com>\nSigned-off-by: Linus Walleij <linus.walleij@linaro.org>\nSigned-off-by: Vinod Koul <vinod.koul@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Linus Walleij",false],["8371cffe8a9c704e3d240d5cb73142b6bd62245b","b0d1e9e4a4e27620745ff49be9000da3174a4cc6@suse.de","dm mpath: fix stalls when handling invalid ioctls\n\ncommit a1989b330093578ea5470bea0a00f940c444c466 upstream.\n\nAn invalid ioctl will never be valid, irrespective of whether multipath\nhas active paths or not.  So for invalid ioctls we do not have to wait\nfor multipath to activate any paths, but can rather return an error\ncode immediately.  This fix resolves numerous instances of:\n\n udevd[]: worker [] unexpectedly returned with status 0x0100\n\nthat have been seen during testing.\n\nSigned-off-by: Hannes Reinecke <hare@suse.de>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Hannes Reinecke",false]],"size":1000,"ref":"refs/heads/cm-11.0-3.4B","head":"4dea39a390914ffa36f3c6394e62039df6282cda"}