- 15 Oct, 2014 20 commits
-
-
Andreas Bomholtz authored
commit dee80ad1 upstream. Added the Seluxit ApS USB Serial Dongle to cp210x driver. Signed-off-by:
Andreas Bomholtz <andreas@seluxit.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joe Savage authored
commit bfc2d7df upstream. Added support for Ketra N1 wireless interface, which uses the Silicon Labs' CP2104 USB to UART bridge with customized PID 8946. Signed-off-by:
Joe Savage <joe.savage@goketra.com> Signed-off-by:
-
Felipe Balbi authored
commit bf17eba7 upstream. This reverts commit f2267089. That commit causes more problem than fixes. Firstly, kfree() should be called after usb_ep_dequeue() and secondly, the way things are, we will try to dequeue a request that has already completed much more frequently than one which is pending. Cc: Li Jun <b47624@freescale.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Dan Carpenter authored
commit 85b06f5e upstream. We need "idx" to be signed for the error handling to work. Fixes: 6d5c1c77 ('usb: gadget: f_fs: fix the redundant ep files problem') Acked-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Hans de Goede authored
commit 710f1bf1 upstream. As most ASM1051 based devices, this one has unfixable issues with uas too. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit f9554a6b upstream. https://bbs.archlinux.org/viewtopic.php?pid=1457492Signed-off-by:
-
Hans de Goede authored
commit 734016b0 upstream. Besides the ASM1051 (*) needing sdev->no_report_opcodes = 1, it turns out that the JMicron JMS567 also needs it to work properly with uas (usb-storage always sets it). Since some of the scsi devs were not to keen on the idea to outrightly set sdev->no_report_opcodes = 1 for all uas devices, so add a quirk for this, and set it for the JMS567. *) Which has become a non-issue since we've completely blacklisted uas on the ASM1051 for other reasons Reported-and-tested-by:
Claudio Bizzarri <claudio.bizzarri@gmail.com> Signed-off-by:
-
Hans de Goede authored
commit 59307852 upstream. And set this quirk for the Seagate Expansion Desk (0bc2:2312), as that one seems to hang upon receiving an ATA_12 or ATA_16 command. https://bugzilla.kernel.org/show_bug.cgi?id=79511 https://bbs.archlinux.org/viewtopic.php?id=183190 While at it also add missing documentation for the u value for usb-storage quirks. Signed-off-by:
-
Yinghai Lu authored
commit d433889c upstream. When we warned about a timeout on a hotplug command, we previously printed the time between calls to pcie_write_cmd(), without accounting for any time spent actually waiting. Consider this sequence: pcie_write_cmd write SLTCTL cmd_started = jiffies # T1 pcie_write_cmd pcie_wait_cmd now = jiffies # T2 wait_event_timeout # we may wait here if (timeout) ctrl_info("Timeout on command issued %u msec ago", jiffies_to_msecs(now - cmd_started)) We previously printed (T2 - T1), but that doesn't include the time spent in wait_event_timeout(). Fix this by using the current jiffies value, not the one cached before calling wait_event_timeout(). [bhelgaas: changelog, use current jiffies instead of adding timeout] Fixes: 40b96083 ("PCI: pciehp: Compute timeout from hotplug command start time") Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Frederic Weisbecker authored
commit 09f6edd4 upstream. ARM irq work IPI support depends on SMP support. That information is partly known at early boottime. Lets implement arch_irq_work_has_interrupt() accordingly. Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Russell King <linux@arm.linux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Frederic Weisbecker <fweisbec@gmail.com> Signed-off-by:
-
Frederic Weisbecker authored
commit 3010279f upstream. x86 supports irq work self-IPIs when local apic is available. This is partly known on runtime so lets implement arch_irq_work_has_interrupt() accordingly. This should be safely called after setup_arch(). Acked-by:
-
Frederic Weisbecker authored
commit 76a33061 upstream. The nohz full kick, which restarts the tick when any resource depend on it, can't be executed anywhere given the operation it does on timers. If it is called from the scheduler or timers code, chances are that we run into a deadlock. This is why we run the nohz full kick from an irq work. That way we make sure that the kick runs on a virgin context. However if that's the case when irq work runs in its own dedicated self-ipi, things are different for the big bunch of archs that don't support the self triggered way. In order to support them, irq works are also handled by the timer interrupt as fallback. Now when irq works run on the timer interrupt, the context isn't blank. More precisely, they can run in the context of the hrtimer that runs the tick. But the nohz kick cancels and restarts this hrtimer and cancelling an hrtimer from itself isn't allowed. This is why we run in an endless loop: Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2 CPU: 2 PID: 7538 Comm: kworker/u8:8 Not tainted 3.16.0+ #34 Workqueue: btrfs-endio-write normal_work_helper [btrfs] ffff880244c06c88 000000001b486fe1 ffff880244c06bf0 ffffffff8a7f1e37 ffffffff8ac52a18 ffff880244c06c78 ffffffff8a7ef928 0000000000000010 ffff880244c06c88 ffff880244c06c20 000000001b486fe1 0000000000000000 Call Trace: <NMI[<ffffffff8a7f1e37>] dump_stack+0x4e/0x7a [<ffffffff8a7ef928>] panic+0xd4/0x207 [<ffffffff8a1450e8>] watchdog_overflow_callback+0x118/0x120 [<ffffffff8a186b0e>] __perf_event_overflow+0xae/0x350 [<ffffffff8a184f80>] ? perf_event_task_disable+0xa0/0xa0 [<ffffffff8a01a4cf>] ? x86_perf_event_set_period+0xbf/0x150 [<ffffffff8a187934>] perf_event_overflow+0x14/0x20 [<ffffffff8a020386>] intel_pmu_handle_irq+0x206/0x410 [<ffffffff8a01937b>] perf_event_nmi_handler+0x2b/0x50 [<ffffffff8a007b72>] nmi_handle+0xd2/0x390 [<ffffffff8a007aa5>] ? nmi_handle+0x5/0x390 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0 [<ffffffff8a008062>] default_do_nmi+0x72/0x1c0 [<ffffffff8a008268>] do_nmi+0xb8/0x100 [<ffffffff8a7ff66a>] end_repeat_nmi+0x1e/0x2e [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0 <<EOE><IRQ[<ffffffff8a0ccd2f>] lock_acquired+0xaf/0x450 [<ffffffff8a0f74c5>] ? lock_hrtimer_base.isra.20+0x25/0x50 [<ffffffff8a7fc678>] _raw_spin_lock_irqsave+0x78/0x90 [<ffffffff8a0f74c5>] ? lock_hrtimer_base.isra.20+0x25/0x50 [<ffffffff8a0f74c5>] lock_hrtimer_base.isra.20+0x25/0x50 [<ffffffff8a0f7723>] hrtimer_try_to_cancel+0x33/0x1e0 [<ffffffff8a0f78ea>] hrtimer_cancel+0x1a/0x30 [<ffffffff8a109237>] tick_nohz_restart+0x17/0x90 [<ffffffff8a10a213>] __tick_nohz_full_check+0xc3/0x100 [<ffffffff8a10a25e>] nohz_full_kick_work_func+0xe/0x10 [<ffffffff8a17c884>] irq_work_run_list+0x44/0x70 [<ffffffff8a17c8da>] irq_work_run+0x2a/0x50 [<ffffffff8a0f700b>] update_process_times+0x5b/0x70 [<ffffffff8a109005>] tick_sched_handle.isra.21+0x25/0x60 [<ffffffff8a109b81>] tick_sched_timer+0x41/0x60 [<ffffffff8a0f7aa2>] __run_hrtimer+0x72/0x470 [<ffffffff8a109b40>] ? tick_sched_do_timer+0xb0/0xb0 [<ffffffff8a0f8707>] hrtimer_interrupt+0x117/0x270 [<ffffffff8a034357>] local_apic_timer_interrupt+0x37/0x60 [<ffffffff8a80010f>] smp_apic_timer_interrupt+0x3f/0x50 [<ffffffff8a7fe52f>] apic_timer_interrupt+0x6f/0x80 To fix this we force non-lazy irq works to run on irq work self-IPIs when available. That ability of the arch to trigger irq work self IPIs is available with arch_irq_work_has_interrupt(). Reported-by:
Catalin Iacob <iacobcatalin@gmail.com> Reported-by:
Dave Jones <davej@redhat.com> Acked-by:
-
Peter Zijlstra authored
commit c5c38ef3 upstream. The nohz full code needs irq work to trigger its own interrupt so that the subsystem can work even when the tick is stopped. Lets introduce arch_irq_work_has_interrupt() that archs can override to tell about their support for this ability. Signed-off-by:
-
WANG Cong authored
[ Upstream commit 5301e3e1 ] We need to copy exts->type when committing the change, otherwise it would be always 0. This is a quick fix for -net and -stable, for net-next tcf_exts will be removed. Fixes: commit 33be6271 ("net_sched: act: use standard struct list_head") Reported-by:
Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Sylvain \\\"ythier\\\" Hitier authored
[ Upstream commit 88b09a6d ] In commit 6f2b6a30, # 3c59x: Add dma error checking and recovery the intent is to split out the mapping from the byte-swapping in order to insert a dma_mapping_error() check. Kinda this semantic patch: // See http://coccinelle.lip6.fr/ // // Beware, grouik-and-dirty! @@ expression DEV, X, Y, Z; @@ - cpu_to_le32(pci_map_single(DEV, X, Y, Z)) + dma_addr_t addr = pci_map_single(DEV, X, Y, Z); + if (dma_mapping_error(&DEV->dev, addr)) + /* snip */; + cpu_to_le32(addr) However, the #else part (of the #if DO_ZEROCOPY test) is changed this way: - cpu_to_le32(pci_map_single(DEV, X, Y, Z)) + dma_addr_t addr = cpu_to_le32(pci_map_single(DEV, X, Y, Z)); // ^^^^^^^^^^^ // That mismatches the 3 other changes! + if (dma_mapping_error(&DEV->dev, addr)) + /* snip */; + cpu_to_le32(addr) Let's remove the leftover cpu_to_le32() for coherency. v2: Better changelog. v3: Add Acked-by Fixes: 6f2b6a30 # 3c59x: Add dma error checking and recovery Acked-by:
Neil Horman <nhorman@tuxdriver.com> Signed-off-by:
Sylvain "ythier" Hitier <sylvain.hitier@gmail.com> Signed-off-by:
-
Vlad Yasevich authored
[ Upstream commit bdf6fa52 ] Currently association restarts do not take into consideration the state of the socket. When a restart happens, the current assocation simply transitions into established state. This creates a condition where a remote system, through a the restart procedure, may create a local association that is no way reachable by user. The conditions to trigger this are as follows: 1) Remote does not acknoledge some data causing data to remain outstanding. 2) Local application calls close() on the socket. Since data is still outstanding, the association is placed in SHUTDOWN_PENDING state. However, the socket is closed. 3) The remote tries to create a new association, triggering a restart on the local system. The association moves from SHUTDOWN_PENDING to ESTABLISHED. At this point, it is no longer reachable by any socket on the local system. This patch addresses the above situation by moving the newly ESTABLISHED association into SHUTDOWN-SENT state and bundling a SHUTDOWN after the COOKIE-ACK chunk. This way, the restarted associate immidiately enters the shutdown procedure and forces the termination of the unreachable association. Reported-by:
David Laight <David.Laight@aculab.com> Signed-off-by:
Vlad Yasevich <vyasevich@gmail.com> Signed-off-by:
-
KY Srinivasan authored
[ Upstream commit 3a67c9cc ] After the packet is successfully sent, we should not touch the packet as it may have been freed. This patch is based on the work done by Long Li <longli@microsoft.com>. David, please queue this up for stable. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reported-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
-
Joe Lawrence authored
[ Upstream commit 47549650 ] When team_notify_peers and team_mcast_rejoin are called, they both reset their respective .count_pending atomic variable. Then when the actual worker function is executed, the variable is atomically decremented. This pattern introduces a potential race condition where the .count_pending rolls over and the worker function keeps rescheduling until .count_pending decrements to zero again: THREAD 1 THREAD 2 ======== ======== team_notify_peers(teamX) atomic_set count_pending = 1 schedule_delayed_work team_notify_peers(teamX) atomic_set count_pending = 1 team_notify_peers_work atomic_dec_and_test count_pending = 0 (return) schedule_delayed_work team_notify_peers_work atomic_dec_and_test count_pending = -1 schedule_delayed_work (repeat until count_pending = 0) Instead of assigning a new value to .count_pending, use atomic_add to tack-on the additional desired worker function invocations. Signed-off-by:
Joe Lawrence <joe.lawrence@stratus.com> Acked-by:
Jiri Pirko <jiri@resnulli.us> Fixes: fc423ff0 ("team: add peer notification") Fixes: 492b200e ("team: add support for sending multicast rejoins") Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit e87474a6 ] Similar to commit bc23333b ("net: bcmgenet: fix bcmgenet_put_tx_csum()"), we need to return the skb pointer in case we had to reallocate the SKB headroom. Fixes: 80105bef ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Nicolas Dichtel authored
[ Upstream commit 3be07244 ] In xmit path, we build a flowi6 which will be used for the output route lookup. We are sending a GRE packet, neither IPv4 nor IPv6 encapsulated packet, thus the protocol should be IPPROTO_GRE. Fixes: c12b395a ("gre: Support GRE over IPv6") Reported-by:
Matthieu Ternisien d'Ouville <matthieu.tdo@6wind.com> Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
- 05 Oct, 2014 2 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds authored
Pull SCSI fixes from James Bottomley: "This is a set of two small fixes, both to code which went in during the merge window: cxgb4i has a scheduling in atomic bug in its new ipv6 code and uas fails to work properly with the new scsi-mq code" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: [SCSI] uas: disable use of blk-mq I/O path [SCSI] cxgb4i: avoid holding mutex in interrupt context
-
- 04 Oct, 2014 1 commit
-
-
https://git.kernel.org/pub/scm/linux/kernel/git/josh/linuxLinus Torvalds authored
Pull kconfig fixes for tiny setups from Josh Triplett: "Two Kconfig bugfixes for 3.17 related to tinification. These fixes make the Kconfig "General Setup" menu much more usable" * tag 'tiny/kconfig-for-3.17' of https://git.kernel.org/pub/scm/linux/kernel/git/josh/linux: init/Kconfig: Fix HAVE_FUTEX_CMPXCHG to not break up the EXPERT menu init/Kconfig: Hide printk log config if CONFIG_PRINTK=n
-
- 03 Oct, 2014 13 commits
-
-
Josh Triplett authored
commit 03b8c7b6 ("futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test") added the HAVE_FUTEX_CMPXCHG symbol right below FUTEX. This placed it right in the middle of the options for the EXPERT menu. However, HAVE_FUTEX_CMPXCHG does not depend on EXPERT or FUTEX, so Kconfig stops placing items in the EXPERT menu, and displays the remaining several EXPERT items (starting with EPOLL) directly in the General Setup menu. Since both users of HAVE_FUTEX_CMPXCHG only select it "if FUTEX", make HAVE_FUTEX_CMPXCHG itself depend on FUTEX. With this change, the subsequent items display as part of the EXPERT menu again; the EMBEDDED menu now appears as the next top-level item in the General Setup menu, which makes General Setup much shorter and more usable. Signed-off-by:
Josh Triplett <josh@joshtriplett.org> Acked-by:
Randy Dunlap <rdunlap@infradead.org> Cc: stable <stable@vger.kernel.org>
-
Josh Triplett authored
The buffers sized by CONFIG_LOG_BUF_SHIFT and CONFIG_LOG_CPU_MAX_BUF_SHIFT do not exist if CONFIG_PRINTK=n, so don't ask about their size at all. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c fixes from Wolfram Sang: "Two i2c driver bugfixes" * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: qup: Fix order of runtime pm initialization i2c: rk3x: fix 0 length write transfers
-
Linus Torvalds authored
Merge tag 'trace-fixes-v3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace Pull trace ring buffer iterator fix from Steven Rostedt: "While testing some new changes for 3.18, I kept hitting a bug every so often in the ring buffer. At first I thought it had to do with some of the changes I was working on, but then testing something else I realized that the bug was in 3.17 itself. I ran several bisects as the bug was not very reproducible, and finally came up with the commit that I could reproduce easily within a few minutes, and without the change I could run the tests over an hour without issue. The change fit the bug and I figured out a fix. That bad commit was: Commit 651e22f2 "ring-buffer: Always reset iterator to reader page" This commit fixed a bug, but in the process created another one. It used the wrong value as the cached value that is used to see if things changed while an iterator was in use. This made it look like a change always happened, and could cause the iterator to go into an infinite loop" * tag 'trace-fixes-v3.17-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace: ring-buffer: Fix infinite spin in reading buffer
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull cifs/smb3 fixes from Steve French: "Fix for CIFS/SMB3 oops on reconnect during readpages (3.17 regression) and for incorrectly closing file handle in symlink error cases" * 'for-linus' of git://git.samba.org/sfrench/cifs-2.6: CIFS: Fix readpages retrying on reconnects Fix problem recognizing symlinks
-
git://neil.brown.name/mdLinus Torvalds authored
Pull raid5 discard fix from Neil Brown: "One fix for raid5 discard issue" * tag 'md/3.17-final-fix' of git://neil.brown.name/md: md/raid5: disable 'DISCARD' by default due to safety concerns.
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Nothing too major or scary. One i915 regression fix, nouveau has a tmds regression fix, along with a regression fix for the runtime pm code for optimus laptops not restoring the display hw correctly" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: drm/nouveau: make sure display hardware is reinitialised on runtime resume drm/nouveau: punt fbcon resume out to a workqueue drm/nouveau: fix regression on original nv50 board drm/nv50/disp: fix dpms regression on certain boards drm/i915: Flush the PTEs after updating them before suspend
-
Christoph Hellwig authored
The uas driver uses the block layer tag for USB3 stream IDs. With blk-mq we can get larger tag numbers that the queue depth, which breaks this assumption. A fix is under way for 3.18, but sits on top of large changes so can't easily be backported. Set the disable_blk_mq path so that a uas device can't easily crash the system when using blk-mq for SCSI. Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
James Bottomley <JBottomley@Parallels.com>
-
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pmLinus Torvalds authored
Pull ACPI and power management fixes from Rafael Wysocki: "These are three regression fixes (cpufreq core, pcc-cpufreq, i915 / ACPI) and one trivial fix for a callback return value mismatch in the cpufreq integrator driver. Specifics: - A recent cpufreq core fix went too far and introduced a regression in the system suspend code path. Fix from Viresh Kumar. - An ACPI-related commit in the i915 driver that fixed backlight problems for some Thinkpads inadvertently broke a Dell machine (in 3.16). Fix from Aaron Lu. - The pcc-cpufreq driver was broken during the 3.15 cycle by a commit that put wait_event() under a spinlock by mistake. Fix that (Rafael J Wysocki). - The return value type of integrator_cpufreq_remove() is void, but should be int. Fix from Arnd Bergmann" * tag 'pm+acpi-3.17-final' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpufreq: update 'cpufreq_suspended' after stopping governors ACPI / i915: Update the condition to ignore firmware backlight change request cpufreq: integrator: fix integrator_cpufreq_remove return type cpufreq: pcc-cpufreq: Fix wait_event() under spinlock -
git://anongit.freedesktop.org/drm-intelDave Airlie authored
final regression fix for 3.17. * tag 'drm-intel-fixes-2014-10-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: Flush the PTEs after updating them before suspend
-
Andy Gross authored
The runtime pm calls need to be done before populating the children via the i2c_add_adapter call. If this is not done, a child can run into issues trying to do i2c read/writes due to the pm_runtime_sync failing. Signed-off-by:
Andy Gross <agross@codeaurora.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Cc: stable@kernel.org
-
Alexandru M Stan authored
i2cdetect -q was broken (everything was a false positive, and no transfers were actually being sent over i2c). The way it works is by sending a 0 length write request and checking for NACK. This patch fixes the 0 length writes and actually sends them. Reported-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Alexandru M Stan <amstan@chromium.org> Tested-by:
Max Schwarz <max.schwarz@online.de> Signed-off-by:
-
Rafael J. Wysocki authored
* pm-cpufreq: cpufreq: update 'cpufreq_suspended' after stopping governors cpufreq: integrator: fix integrator_cpufreq_remove return type cpufreq: pcc-cpufreq: Fix wait_event() under spinlock * acpi-video: ACPI / i915: Update the condition to ignore firmware backlight change request
-
- 02 Oct, 2014 4 commits
-
-
Linus Torvalds authored
Merge fixes from Andrew Morton: "5 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: mm: page_alloc: fix zone allocation fairness on UP perf: fix perf bug in fork() MAINTAINERS: change git URL for mpc5xxx tree mm: memcontrol: do not iterate uninitialized memcgs ocfs2/dlm: should put mle when goto kill in dlm_assert_master_handler
-
Johannes Weiner authored
The zone allocation batches can easily underflow due to higher-order allocations or spills to remote nodes. On SMP that's fine, because underflows are expected from concurrency and dealt with by returning 0. But on UP, zone_page_state will just return a wrapped unsigned long, which will get past the <= 0 check and then consider the zone eligible until its watermarks are hit. Commit 3a025760 ("mm: page_alloc: spill to remote nodes before waking kswapd") already made the counter-resetting use atomic_long_read() to accomodate underflows from remote spills, but it didn't go all the way with it. Make it clear that these batches are expected to go negative regardless of concurrency, and use atomic_long_read() everywhere. Fixes: 81c0a2bb ("mm: page_alloc: fair zone allocator policy") Reported-by:
Vlastimil Babka <vbabka@suse.cz> Reported-by:
Leon Romanovsky <leon@leon.nu> Signed-off-by:
Johannes Weiner <hannes@cmpxchg.org> Acked-by:
Mel Gorman <mgorman@suse.de> Cc: <stable@vger.kernel.org> [3.12+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Peter Zijlstra authored
Oleg noticed that a cleanup by Sylvain actually uncovered a bug; by calling perf_event_free_task() when failing sched_fork() we will not yet have done the memset() on ->perf_event_ctxp[] and will therefore try and 'free' the inherited contexts, which are still in use by the parent process. This is bad.. Suggested-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
-
Anatolij Gustschin authored
The repository for mpc5xxx has been moved, update git URL to new location. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
![Sylvain \\\"ythier\\\" Hitier's avatar](https://secure.gravatar.com/avatar/851d27533f7a6fcd12f89b5e5ab28164?s=80&d=identicon "Sylvain \\\\"ythier\\\\" Hitier")
