- 04 Feb, 2015 10 commits
-
-
Sharon Dvir authored
The second 'mutex' shouldn't be there, it can't be about the mutex, as the mutex can't be freed, but unlocked, the memory where the mutex resides however, can be freed. Signed-off-by:
Sharon Dvir <sharon.dvir1@mail.huji.ac.il> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1422827252-31363-1-git-send-email-sharon.dvir1@mail.huji.ac.ilSigned-off-by:
Ingo Molnar <mingo@kernel.org>
-
Johan Hedberg authored
Add a new wait_on_bit_timeout() helper, basically the same as wait_on_bit() except that it also takes a 'timeout' parameter. All the building blocks like bit_wait_timeout() and out_of_line_wait_on_bit_timeout() are already in place so the addition is rather simple. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Frederic Weisbecker authored
__schedule() disables preemption during its job and re-enables it afterward without doing a preemption check to avoid recursion. But if an event happens after the context switch which requires rescheduling, we need to check again if a task of a higher priority needs the CPU. A preempt irq can raise such a situation. To handle that, __schedule() loops on need_resched(). But preempt_schedule_*() functions, which call __schedule(), also loop on need_resched() to handle missed preempt irqs. Hence we end up with the same loop happening twice. Lets simplify that by attributing the need_resched() loop responsibility to all __schedule() callers. There is a risk that the outer loop now handles reschedules that used to be handled by the inner loop with the added overhead of caller details (inc/dec of PREEMPT_ACTIVE, irq save/restore) but assuming those inner rescheduling loop weren't too frequent, this shouldn't matter. Especially since the whole preemption path is now losing one loop in any case. Suggested-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
-
Xunlei Pang authored
cpu_active_mask is rarely changed (only on hotplug), so remove this operation to gain a little performance. If there is a change in cpu_active_mask, rq_online_dl() and rq_offline_dl() should take care of it normally, so cpudl::free_cpus carries enough information for us. For the rare case when a task is put onto a dying cpu (which rq_offline_dl() can't handle in a timely fashion), it will be handled through _cpu_down()->...->multi_cpu_stop()->migration_call() ->migrate_tasks(), preventing the task from hanging on the dead cpu. Cc: Juri Lelli <juri.lelli@gmail.com> Signed-off-by:
Xunlei Pang <pang.xunlei@linaro.org> [peterz: changelog] Signed-off-by:
-
Wanpeng Li authored
The commit 177ef2a6 ("sched/deadline: Fix a precision problem in the microseconds range") forgot to change the UP version of hrtick_start(), do so now. Signed-off-by:
Wanpeng Li <wanpeng.li@linux.intel.com> Fixes: 177ef2a6 ("sched/deadline: Fix a precision problem in the microseconds range") [ Fixed the changelog. ] Signed-off-by:
-
Wanpeng Li authored
There is no need to dequeue/enqueue and push/pull if there are no scheduling parameters changed for the DL class. Both fair and RT classes already check if parameters changed for them to avoid unnecessary overhead. This patch add the parameters changed test for the DL class in order to reduce overhead. Signed-off-by:
-
Peter Zijlstra authored
When we fail to start the deadline timer in update_curr_dl(), we forget to clear ->dl_yielded, resulting in wrecked time keeping. Since the natural place to clear both ->dl_yielded and ->dl_throttled is in replenish_dl_entity(); both are after all waiting for that event; make it so. Luckily since 67dfa1b7 ("sched/deadline: Implement cancel_dl_timer() to use in switched_from_dl()") the task_on_rq_queued() condition in dl_task_timer() must be true, and can therefore call enqueue_task_dl() unconditionally. Reported-by:
-
Wanpeng Li authored
After update_curr_dl() the current task might not be the leftmost task anymore. In that case do not start a new hrtick for it. In this case NEED_RESCHED will be set and the next schedule will start the hrtick for the new task if and when appropriate. Signed-off-by:
Juri Lelli <juri.lelli@arm.com> [ Rewrote the changelog and comment. ] Signed-off-by:
-
Ingo Molnar authored
Signed-off-by: -
Peter Zijlstra authored
Commit 67dfa1b7 ("sched/deadline: Implement cancel_dl_timer() to use in switched_from_dl()") removed the hrtimer_try_cancel() function call out from init_dl_task_timer(), which gets called from __setparam_dl(). The result is that we can now re-init the timer while its active -- this is bad and corrupts timer state. Furthermore; changing the parameters of an active deadline task is tricky in that you want to maintain guarantees, while immediately effective change would allow one to circumvent the CBS guarantees -- this too is bad, as one (bad) task should not be able to affect the others. Rework things to avoid both problems. We only need to initialize the timer once, so move that to __sched_fork() for new tasks. Then make sure __setparam_dl() doesn't affect the current running state but only updates the parameters used to calculate the next scheduling period -- this guarantees the CBS functions as expected (albeit slightly pessimistic). This however means we need to make sure __dl_clear_params() needs to reset the active state otherwise new (and tasks flipping between classes) will not properly (re)compute their first instance. Todo: close class flipping CBS hole. Todo: implement delayed BW release. Reported-by:
Luca Abeni <luca.abeni@unitn.it> Acked-by:
-
- 03 Feb, 2015 1 commit
-
-
Mikulas Patocka authored
The patch e22b886a ("sched/wait: Add might_sleep() checks") introduced a bug in the raid5 subsystem. The function raid5_quiesce() (and resize_stripes()) uses the 'cmd' part to release and acquire a spinlock (so we call the sleep primitives in atomic context), and therefore we cannot do the might_sleep() check. Remove it. Fixes: e22b886a ("sched/wait: Add might_sleep() checks") Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
- 30 Jan, 2015 5 commits
-
-
Xunlei Pang authored
Currently, cpudl::free_cpus contains all CPUs during init, see cpudl_init(). When calling cpudl_find(), we have to add rd->span to avoid selecting the cpu outside the current root domain, because cpus_allowed cannot be depended on when performing clustered scheduling using the cpuset, see find_later_rq(). This patch adds cpudl_set_freecpu() and cpudl_clear_freecpu() for changing cpudl::free_cpus when doing rq_online_dl()/rq_offline_dl(), so we can avoid the rd->span operation when calling cpudl_find() in find_later_rq(). Signed-off-by:
-
Preeti U Murthy authored
cpu_idle_poll() is entered into when either the cpu_idle_force_poll is set or tick_check_broadcast_expired() returns true. The exit condition from cpu_idle_poll() is tif_need_resched(). However this does not take into account scenarios where cpu_idle_force_poll changes or tick_check_broadcast_expired() returns false, without setting the resched flag. So a cpu will be caught in cpu_idle_poll() needlessly, thereby wasting power. Add an explicit check on cpu_idle_force_poll and tick_check_broadcast_expired() to the exit condition of cpu_idle_poll() to avoid this. Signed-off-by:
Preeti U Murthy <preeti@linux.vnet.ibm.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Frederic Weisbecker authored
If an interrupt fires in cond_resched(), between the call to __schedule() and the PREEMPT_ACTIVE count decrementation, and that interrupt sets TIF_NEED_RESCHED, the call to preempt_schedule_irq() will be ignored due to the PREEMPT_ACTIVE count. This kind of scenario, with irq preemption being delayed because it's interrupting a preempt-disabled area, is usually fixed up after preemption is re-enabled back with an explicit call to preempt_schedule(). This is what preempt_enable() does but a raw preempt count decrement as performed by __preempt_count_sub(PREEMPT_ACTIVE) doesn't handle delayed preemption check. Therefore when such a race happens, the rescheduling is going to be delayed until the next scheduler or preemption entrypoint. This can be a problem for scheduler latency sensitive workloads. Lets fix that by consolidating cond_resched() with preempt_schedule() internals. Reported-by:
-
Tim Chen authored
This patch adds checks that prevens futile attempts to move rt tasks to a CPU with active tasks of equal or higher priority. This reduces run queue lock contention and improves the performance of a well known OLTP benchmark by 0.7%. Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by:
-
Ingo Molnar authored
Merge all pending fixes and refresh the tree, before applying new changes. Signed-off-by:
-
- 28 Jan, 2015 2 commits
-
-
Mike Galbraith authored
While creating an exclusive cpuset, we passed cpuset_cpumask_can_shrink() an empty cpumask (cur), and dl_bw_of(cpumask_any(cur)) made boom with it: CPU: 0 PID: 6942 Comm: shield.sh Not tainted 3.19.0-master #19 Hardware name: MEDIONPC MS-7502/MS-7502, BIOS 6.00 PG 12/26/2007 task: ffff880224552450 ti: ffff8800caab8000 task.ti: ffff8800caab8000 RIP: 0010:[<ffffffff81073846>] [<ffffffff81073846>] cpuset_cpumask_can_shrink+0x56/0xb0 [...] Call Trace: [<ffffffff810cb82a>] validate_change+0x18a/0x200 [<ffffffff810cc877>] cpuset_write_resmask+0x3b7/0x720 [<ffffffff810c4d58>] cgroup_file_write+0x38/0x100 [<ffffffff811d953a>] kernfs_fop_write+0x12a/0x180 [<ffffffff8116e1a3>] vfs_write+0xb3/0x1d0 [<ffffffff8116ed06>] SyS_write+0x46/0xb0 [<ffffffff8159ced6>] system_call_fastpath+0x16/0x1b Signed-off-by:
Mike Galbraith <umgwanakikbuti@gmail.com> Acked-by:
Zefan Li <lizefan@huawei.com> Fixes: f82f8042 ("sched/deadline: Ensure that updates to exclusive cpusets don't break AC") Signed-off-by:
-
Jan Beulich authored
At least some gcc versions - validly afaict - warn about potentially using max_group uninitialized: There's no way the compiler can prove that the body of the conditional where it and max_faults get set/ updated gets executed; in fact, without knowing all the details of other scheduler code, I can't prove this either. Generally the necessary change would appear to be to clear max_group prior to entering the inner loop, and break out of the outer loop when it ends up being all clear after the inner one. This, however, seems inefficient, and afaict the same effect can be achieved by exiting the outer loop when max_faults is still zero after the inner loop. [ mingo: changed the solution to zero initialization: uninitialized_var() needs to die, as it's an actively dangerous construct: if in the future a known-proven-good piece of code is changed to have a true, buggy uninitialized variable, the compiler warning is then supressed... The better long term solution is to clean up the code flow, so that even simple minded compilers (and humans!) are able to read it without getting a headache. ] Signed-off-by:
Jan Beulich <jbeulich@suse.com> Signed-off-by:
-
- 27 Jan, 2015 1 commit
-
-
Linus Torvalds authored
Merge misc fixes from Andrew Morton: "Six fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: drivers/rtc/rtc-s5m.c: terminate s5m_rtc_id array with empty element printk: add dummy routine for when CONFIG_PRINTK=n mm/vmscan: fix highidx argument type memcg: remove extra newlines from memcg oom kill log x86, build: replace Perl script with Shell script mm: page_alloc: embed OOM killing naturally into allocation slowpath
-
- 26 Jan, 2015 18 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroupLinus Torvalds authored
Pull cgroup fix from Tejun Heo: "The lifetime rules of cgroup hierarchies always have been somewhat counter-intuitive and cgroup core tried to enforce that hierarchies w/o userland-visible usages must die in finite amount of time so that the controllers can be reused for other hierarchies; unfortunately, this can't be implemented reasonably for the memory controller - the kmemcg part doesn't have any way to forcefully drain the existing usages, leading to an interruptible hang if a following mount attempts to use the controller in any way. So, it seems like we're stuck with "hierarchies live on till they die whenever that may be" at least for now. This pretty much confines attaching controllers to hierarchies to before the hierarchies are actively used by making dynamic configurations post active usages unreliable. This has never been reliable and should be fine in practice given how cgroups are used. After the patch, hierarchies aren't killed if it isn't already drained. A following mount attempt of the same mount options will reuse the existing hierarchy. Mount attempts with differing options will fail w/ -EBUSY" * 'for-3.19-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup: cgroup: prevent mount hang due to memory controller lifetime
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulatorLinus Torvalds authored
Pull regulator fixes from Mark Brown: "One correctness fix here for the s2mps11 driver which would have resulted in some of the regulators being completely broken together with a fix for locking in regualtor_put() (which is fortunately rarely called at all in practical systems)" * tag 'regulator-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: s2mps11: Fix wrong calculation of register offset regulator: core: fix race condition in regulator_put()
-
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spiLinus Torvalds authored
Pull spi fixes from Mark Brown: "A few driver specific fixes here, some fixes for issues introduced and discovered during recent work on the DesignWare driver (which has been getting a lot of attention recently) and a couple of other drivers. All serious things for people who run into them" * tag 'spi-v3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: dw: amend warning message spi: sh-msiof: fix MDR1_FLD_MASK value spi: dw-mid: fix FIFO size spi: dw: Fix detecting FIFO depth spi/pxa2xx: Clear cur_chip pointer before starting next message
-
Andrey Ryabinin authored
Array of platform_device_id elements should be terminated with empty element. Fixes: 5bccae6e ("rtc: s5m-rtc: add real-time clock driver for s5m8767") Signed-off-by:
Andrey Ryabinin <a.ryabinin@samsung.com> Reviewed-by:
Krzysztof Kozlowski <k.kozlowski@samsung.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Pranith Kumar authored
There are missing dummy routines for log_buf_addr_get() and log_buf_len_get() for when CONFIG_PRINTK is not set causing build failures. This patch adds these dummy routines at the appropriate location. Signed-off-by:
Pranith Kumar <bobby.prani@gmail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Reviewed-by:
Petr Mladek <pmladek@suse.cz> Acked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Michael S. Tsirkin authored
for_each_zone_zonelist_nodemask wants an enum zone_type argument, but is passed gfp_t: mm/vmscan.c:2658:9: expected int enum zone_type [signed] highest_zoneidx mm/vmscan.c:2658:9: got restricted gfp_t [usertype] gfp_mask mm/vmscan.c:2658:9: warning: incorrect type in argument 2 (different base types) mm/vmscan.c:2658:9: expected int enum zone_type [signed] highest_zoneidx mm/vmscan.c:2658:9: got restricted gfp_t [usertype] gfp_mask convert argument to the correct type. Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Vladimir Davydov <vdavydov@parallels.com> Cc: Rik van Riel <riel@redhat.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Mel Gorman <mgorman@suse.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Suleiman Souhlal <suleiman@google.com> Signed-off-by:
-
Greg Thelen authored
Commit e61734c5 ("cgroup: remove cgroup->name") added two extra newlines to memcg oom kill log messages. This makes dmesg hard to read and parse. The issue affects 3.15+. Example: Task in /t <<< extra #1 killed as a result of limit of /t <<< extra #2 memory: usage 102400kB, limit 102400kB, failcnt 274712 Remove the extra newlines from memcg oom kill messages, so the messages look like: Task in /t killed as a result of limit of /t memory: usage 102400kB, limit 102400kB, failcnt 240649 Fixes: e61734c5 ("cgroup: remove cgroup->name") Signed-off-by:
Greg Thelen <gthelen@google.com> Acked-by:
Michal Hocko <mhocko@suse.cz> Acked-by:
Johannes Weiner <hannes@cmpxchg.org> Signed-off-by:
-
Kees Cook authored
Commit e6023367 ("x86, kaslr: Prevent .bss from overlaping initrd") added Perl to the required build environment. This reimplements in shell the Perl script used to find the size of the kernel with bss and brk added. Signed-off-by:
Kees Cook <keescook@chromium.org> Reported-by:
Rob Landley <rob@landley.net> Acked-by:
-
Johannes Weiner authored
The OOM killing invocation does a lot of duplicative checks against the task's allocation context. Rework it to take advantage of the existing checks in the allocator slowpath. The OOM killer is invoked when the allocator is unable to reclaim any pages but the allocation has to keep looping. Instead of having a check for __GFP_NORETRY hidden in oom_gfp_allowed(), just move the OOM invocation to the true branch of should_alloc_retry(). The __GFP_FS check from oom_gfp_allowed() can then be moved into the OOM avoidance branch in __alloc_pages_may_oom(), along with the PF_DUMPCORE test. __alloc_pages_may_oom() can then signal to the caller whether the OOM killer was invoked, instead of requiring it to duplicate the order and high_zoneidx checks to guess this when deciding whether to continue. Signed-off-by:
-
Mark Brown authored
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "Hopefully the last round of fixes for 3.19 - regression fix for the LDT changes - regression fix for XEN interrupt handling caused by the APIC changes - regression fixes for the PAT changes - last minute fixes for new the MPX support - regression fix for 32bit UP - fix for a long standing relocation issue on 64bit tagged for stable - functional fix for the Hyper-V clocksource tagged for stable - downgrade of a pr_err which tends to confuse users Looks a bit on the large side, but almost half of it are valuable comments" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tsc: Change Fast TSC calibration failed from error to info x86/apic: Re-enable PCI_MSI support for non-SMP X86_32 x86, mm: Change cachemode exports to non-gpl x86, tls: Interpret an all-zero struct user_desc as "no segment" x86, tls, ldt: Stop checking lm in LDT_empty x86, mpx: Strictly enforce empty prctl() args x86, mpx: Fix potential performance issue on unmaps x86, mpx: Explicitly disable 32-bit MPX support on 64-bit kernels x86, hyperv: Mark the Hyper-V clocksource as being continuous x86: Don't rely on VMWare emulating PAT MSR correctly x86, irq: Properly tag virtualization entry in /proc/interrupts x86, boot: Skip relocs when load address unchanged x86/xen: Override ACPI IRQ management callback __acpi_unregister_gsi ACPI: pci: Do not clear pci_dev->irq in acpi_pci_irq_disable() x86/xen: Treat SCI interrupt as normal GSI interrupt -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Gleixner: "From the irqchip departement you get: - regression fix for omap-intc - regression fix for atmel-aic-common - functional correctness fix for hip04 - type mismatch fix for gic-v3-its - proper error pointer check for mtd-sysirq Mostly one and two liners except for the omap regression fix which is slightly larger than desired" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip: atmel-aic-common: Prevent clobbering of priority when changing IRQ type irqchip: omap-intc: Fix legacy DMA regression irqchip: gic-v3-its: Fix use of max with decimal constant irqchip: hip04: Initialize hip04_cpu_map to 0xffff irqchip: mtk-sysirq: Use IS_ERR() instead of NULL pointer check
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "A set of small fixes: - regression fix for exynos_mct clocksource - trivial build fix for kona clocksource - functional one liner fix for the sh_tmu clocksource - two validation fixes to prevent (root only) data corruption in the kernel via settimeofday and adjtimex. Tagged for stable" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: time: adjtimex: Validate the ADJ_FREQUENCY values time: settimeofday: Validate the values of tv from user clocksource: sh_tmu: Set cpu_possible_mask to fix SMP broadcast clocksource: kona: fix __iomem annotation clocksource: exynos_mct: Fix bitmask regression for exynos4_mct_write -
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds authored
Pull ARM SoC fixes from Olof Johansson: "A week's worth of fixes for various ARM platforms. Diff wise, the largest fix is for OMAP to deal with how GIC now registers interrupts (irq_domain_add_legacy() -> irq_domain_add_linear() changes). Besides this, a few more renesas platforms needed the GIC instatiation done for legacy boards. There's also a fix that disables coherency of mvebu due to issues, and a few other smaller fixes" * tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: arm64: dts: add baud rate to Juno stdout-path ARM: dts: imx25: Fix PWM "per" clocks bus: mvebu-mbus: fix support of MBus window 13 Merge tag 'mvebu-fixes-3.19-3' of git://git.infradead.org/linux-mvebu into fixes ARM: mvebu: completely disable hardware I/O coherency ARM: OMAP: Work around hardcoded interrupts ARM: shmobile: r8a7779: Instantiate GIC from C board code in legacy builds ARM: shmobile: r8a7778: Instantiate GIC from C board code in legacy builds arm: boot: dts: dra7: enable dwc3 suspend PHY quirk
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs fixes from Al Viro: "A couple of fixes - deadlock in CIFS and build breakage in cris serial driver (resurfaced f_dentry in there)" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: VFS: Convert file->f_dentry->d_inode to file_inode() fix deadlock in cifs_ioctl_clone()
-
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dmLinus Torvalds authored
Pull device mapper fixes from Mike Snitzer: "Two stable fixes for dm-cache and one 3.19 DM core fix: - fix potential for dm-cache metadata corruption via stale metadata buffers being used when switching an inactive cache table to active; this could occur due to each table having it's own bufio client rather than sharing the client between tables. - fix dm-cache target to properly account for discard IO while suspending otherwise IO quiescing could complete prematurely. - fix DM core's handling of multiple internal suspends by maintaining an 'internal_suspend_count' and only resuming the device when this count drops to zero" * tag 'dm-3.19-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm: dm: fix handling of multiple internal suspends dm cache: fix problematic dual use of a single migration count variable dm cache: share cache-metadata object across inactive and active DM tables -
git://git.kernel.dk/linux-blockLinus Torvalds authored
Pull two block layer fixes from Jens Axboe: "Two small patches that should make it into 3.19: - a fixup from me for NVMe, making the cq_vector a signed variable. Otherwise our -1 comparison fails, and commit 2b25d981 doesn't do what it was supposed to. - a fixup for the hotplug handling for blk-mq from Ming Lei, using the proper kobject referencing to ensure we release resources at the right time" * 'for-linus' of git://git.kernel.dk/linux-block: blk-mq: fix hctx/ctx kobject use-after-free NVMe: cq_vector should be signed
-
- 24 Jan, 2015 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
pULL SCSI fixes from James Bottomley: "This consists of four real fixes and three MAINTAINER updates. Three of the fixes are obvious (the DIX and atomic allocation are bug on and warn on fixes and the other is just trivial) and the ipr one is a bit more involved but is required because without it, the card double completes aborted commands and causes a kernel oops" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: MAINTAINERS: ibmvscsi driver maintainer change MAINTAINERS: ibmvfc driver maintainer change MAINTAINERS: Remove self as isci maintainer scsi_debug: test always evaluates to false, || should be used instead scsi: Avoid crashing if device uses DIX but adapter does not support it scsi_debug: use atomic allocation in resp_rsup_opcodes ipr: wait for aborted command responses
-
git://www.linux-watchdog.org/linux-watchdogLinus Torvalds authored
Pull watchdog fixes from Wim Van Sebroeck: "This will fix reboot issues with the imx2_wdt driver and it also drops some forgotten owner assignments from platform_drivers" * git://www.linux-watchdog.org/linux-watchdog: watchdog: drop owner assignment from platform_drivers watchdog: imx2_wdt: Disable power down counter on boot watchdog: imx2_wdt: Improve power management support.
-
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/stagingLinus Torvalds authored
Pull hwmon update from Jean Delvare: "This contains a single thing: a new driver for the temperature sensor embedded in the Intel 5500/5520/X58 chipsets. Sorry for the late request, it's been so long since I last sent a pull request and I've been so busy with other tasks meanwhile that I simply forgot about these patches. But given that this is a new driver, it can't introduce any regression so I thought it could still be OK. This has been in linux-next for months now" * 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: hwmon: (i5500_temp) Convert to use ATTRIBUTE_GROUPS macro hwmon: (i5500_temp) Convert to module_pci_driver hwmon: (i5500_temp) Don't bind to disabled sensors hwmon: (i5500_temp) Convert to devm_hwmon_device_register_with_groups hwmon: (i5500_temp) New driver for the Intel 5500/5520/X58 chipsets
-
