- 31 Mar, 2014 30 commits
-
-
Gavin Shan authored
commit 93aef2a7 upstream. Prior to the completion of PCI enumeration, we actively detects EEH errors on PCI config cycles and dump PHB diag-data if necessary. The EEH backend also dumps PHB diag-data in case of frozen PE or fenced PHB. However, we are using different functions to dump the PHB diag-data for those 2 cases. The patch merges the functions for dumping PHB diag-data to one so that we can avoid duplicate code. Also, we never dump PHB3 diag-data during PCI config cycles with frozen PE. The patch fixes it as well. Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Markus Pargmann authored
commit 66fda75f upstream. There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit 608cfbe4 upstream. The call to clamp_t() first truncates the variable signed 8 bit and as a result, the actual clamp is a no-op. Fixes: 0d78156e ('p54: improve site survey') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Guenter Roeck authored
commit 63238f2c upstream. The following build error is seen if CONFIG_32BIT is undefined, CONFIG_64BIT is defined, and CONFIG_MIPS32_O32 is undefined. asm/syscall.h: In function 'mips_get_syscall_arg': arch/mips/include/asm/syscall.h:32:16: error: unused variable 'usp' [-Werror=unused-variable] cc1: all warnings being treated as errors Fixes: c0ff3c53 ('MIPS: Enable HAVE_ARCH_TRACEHOOK') Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
John Crispin <blogic@openwrt.org> Patchwork: http://patchwork.linux-mips.org/patch/6160/Signed-off-by:
-
Ben Hutchings authored
commit f8ce239d upstream. builddeb generates a control file that says the linux-headers package can only be built for the build system primary architecture. This breaks cross-building configurations. We should use $debarch for this instead. Since $debarch is not yet set when generating the control file, set Architecture: any and use control file variables to fill in the description. Fixes: cd8d60a2 ('kbuild: create linux-headers package in deb-pkg') Reported-and-tested-by:
"Niew, Sh." <shniew@gmail.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Ben Hutchings authored
commit c5e318f6 upstream. These commands will mysteriously fail: $ make ARCH=arm versatile_defconfig [...] $ make ARCH=arm deb-pkg [...] make[1]: *** [deb-pkg] Error 1 make: *** [deb-pkg] Error 2 The Debian architecture selection for these kernel architectures does 'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this aborts the script if grep does not find the given config symbol. Fixes: 10f26fa6 ('build, deb-pkg: select userland architecture based on UTS_MACHINE') Signed-off-by:
-
Peter Zijlstra authored
commit f428ebd1 upstream. Someone got the load and store barriers mixed up for AAAAARGH64. Turn them the right side up. Reported-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Fixes: a94d342b ("tools/perf: Add required memory barriers") Cc: Ingo Molnar <mingo@kernel.org> Cc: Will Deacon <will.deacon@arm.com> Link: http://lkml.kernel.org/r/20140124154002.GF31570@twins.programming.kicks-ass.netSigned-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Russell King authored
commit e83b3664 upstream. We must use a 64-bit for this, otherwise overflowed bits get lost, and that can result in a lower than intended value set. Fixes: 8e0cb8a1 ("ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations") Fixes: 7d35496d ("ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations") Tested-Acked-by:
Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Linus Torvalds authored
commit e4178d80 upstream. This is not a buffer overflow in the traditional sense: we don't overflow any *kernel* buffers, but we do mis-count the amount of data we copy back to user space for the SYSLOG_ACTION_READ_ALL case. In particular, if the user buffer is too small to hold everything, and *if* there is a continuation line at just the right place, we can end up giving the user more data than he asked for. The reason is that we first count up the number of bytes all the log records contains, then we walk the records again until we've skipped the records at the beginning that won't fit, and then we walk the rest of the records and copy them to the user space buffer. And in between that "skip the initial records that won't fit" and the "copy the records that *will* fit to user space", we reset the 'prev' variable that contained the record information for the last record not copied. That meant that when we started copying to user space, we now had a different character count than what we had originally calculated in the first record walk-through. The fix is to simply not clear the 'prev' flags value (in both cases where we had the same logic: syslog_print_all and kmsg_dump_get_buffer: the latter is used for pstore-like dumping) Reported-and-tested-by:
Debabrata Banerjee <dbanerje@akamai.com> Acked-by:
Kay Sievers <kay@vrfy.org> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Josh Hunt <joshhunt00@gmail.com> Signed-off-by:
-
Alexei Starovoitov authored
commit fdfaf64e upstream. Commit a998d434 claimed to introduce negative offset support to x86 jit, but it couldn't be working, since at the time of the execution of LD+ABS or LD+IND instructions via call into bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func) had junk value instead of access size in bytes (1 or 2 or 4). Store size into %edx instead of %ecx (what original commit intended to do) Fixes: a998d434 ("bpf jit: Let the x86 jit handle negative offsets") Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Cc: Jan Seiffert <kaffeemonster@googlemail.com> Cc: Eric Dumazet <edumazet@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Trond Myklebust authored
commit e9776d0f upstream. In gss_alloc_msg(), if the call to gss_encode_v1_msg() fails, we want to release the reference to the pipe_version that was obtained earlier in the function. Fixes: 9d3a2260 (SUNRPC: Fix buffer overflow checking in...) Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Ben Peddell authored
commit 4c235cb9 upstream. Commit 65939301 (arm: set initrd_start/initrd_end for fdt scan) caused the FDT initrd_start and initrd_end to override the phys_initrd_start and phys_initrd_size set by the initrd= kernel parameter. With this patch initrd_start and initrd_end will be overridden if phys_initrd_start and phys_initrd_size are set by the kernel initrd= parameter. Fixes: 65939301 (arm: set initrd_start/initrd_end for fdt scan) Signed-off-by:
Ben Peddell <klightspeed@killerwolves.net> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Ben Hutchings authored
commit d9317aea upstream. As part of a workaround for a hardware erratum in the SFC9100 family (SF bug 35388), the TX_DESC_UPD_DWORD register address is also used for communicating with the event block, and only descriptor pointer values < 2048 are valid. If the TX DMA ring size is increased to 4096 descriptors (which the firmware still allows) then we may write a descriptor pointer value >= 2048, which has entirely different and undesirable effects! Limit the TX DMA ring size correctly when this workaround is in effect. Fixes: 8127d661 ('sfc: Add support for Solarflare SFC9100 family') Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
Shradha Shah <sshah@solarflare.com> Signed-off-by:
-
Peter Zijlstra authored
commit 177c53d9 upstream. We must use smp_call_function_single(.wait=1) for the irq_cpu_stop_queue_work() to ensure the queueing is actually done under stop_cpus_lock. Without this we could have dropped the lock by the time we do the queueing and get the race we tried to fix. Fixes: 7053ea1a ("stop_machine: Fix race between stop_two_cpus() and stop_cpus()") Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Stephen Warren authored
commit e126a646 upstream. The REVISION_ID register is not currently marked readable. snd_soc_read() refuses to read the register, and hence probe() fails. Fixes: d4807ad2 ("regmap: Check readable regs in _regmap_read") [exposed the bug, by checking for readability] Fixes: 685e4215 ("ASoC: Replace max98090 Device Driver") [left out this register from the readable list] Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Josh Durgin authored
commit 9a1ea2db upstream. With the current full handling, there is a race between osds and clients getting the first map marked full. If the osd wins, it will return -ENOSPC to any writes, but the client may already have writes in flight. This results in the client getting the error and propagating it up the stack. For rbd, the block layer turns this into EIO, which can cause corruption in filesystems above it. To avoid this race, osds are being changed to drop writes that came from clients with an osdmap older than the last osdmap marked full. In order for this to work, clients must resend all writes after they encounter a full -> not full transition in the osdmap. osds will wait for an updated map instead of processing a request from a client with a newer map, so resent writes will not be dropped by the osd unless there is another not full -> full transition. This approach requires both osds and clients to be fixed to avoid the race. Old clients talking to osds with this fix may hang instead of returning EIO and potentially corrupting an fs. New clients talking to old osds have the same behavior as before if they encounter this race. Fixes: http://tracker.ceph.com/issues/6938Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
Josh Durgin <josh.durgin@inktank.com> Signed-off-by:
-
Josh Durgin authored
commit d29adb34 upstream. The PAUSEWR and PAUSERD flags are meant to stop the cluster from processing writes and reads, respectively. The FULL flag is set when the cluster determines that it is out of space, and will no longer process writes. PAUSEWR and PAUSERD are purely client-side settings already implemented in userspace clients. The osd does nothing special with these flags. When the FULL flag is set, however, the osd responds to all writes with -ENOSPC. For cephfs, this makes sense, but for rbd the block layer translates this into EIO. If a cluster goes from full to non-full quickly, a filesystem on top of rbd will not behave well, since some writes succeed while others get EIO. Fix this by blocking any writes when the FULL flag is set in the osd client. This is the same strategy used by userspace, so apply it by default. A follow-on patch makes this configurable. __map_request() is called to re-target osd requests in case the available osds changed. Add a paused field to a ceph_osd_request, and set it whenever an appropriate osd map flag is set. Avoid queueing paused requests in __map_request(), but force them to be resent if they become unpaused. Also subscribe to the next osd map from the monitor if any of these flags are set, so paused requests can be unblocked as soon as possible. Fixes: http://tracker.ceph.com/issues/6079Reviewed-by:
-
Dan Carpenter authored
commit e351bf25 upstream. It upsets static checkers when we don't check for allocation failure. I moved the memset() of "tv" earlier so we don't use uninitialized data on error. Fixes: 1d212cf0 ('[media] cx18: struct i2c_client is too big for stack') Signed-off-by:
Andy Walls <awalls@md.metrocast.net> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Dan Carpenter authored
commit 324ed533 upstream. We recently introduced some new error paths but the unlocks are missing. Fixes: 0065a79a ('[media] dw2102: Don't use dynamic static allocation') Signed-off-by:
-
Dan Carpenter authored
commit 1cdbcc5d upstream. We recently introduced some new error paths which are missing their unlocks. Fixes: 64f7ef8a ('[media] cxusb: Don't use dynamic static allocation') Signed-off-by:
-
Trond Myklebust authored
commit 292f503c upstream. We need to use the same net namespace that was used to resolve the hostname and sockaddr arguments. Fixes: 32e62b7c (NFS: Add nfs4_update_server) Cc: Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Christian Riesch authored
commit 33b7107f upstream. In commit 6892b41d Author: Lad, Prabhakar <prabhakar.csengg@gmail.com> Date: Tue Jun 25 21:24:51 2013 +0530 net: davinci: emac: Convert to devm_* api the call of request_irq is replaced by devm_request_irq and the call of free_irq is removed. But since interrupts are requested in emac_dev_open, doing ifconfig up/down on the board requests the interrupts again each time, causing devm_request_irq to fail. The interface is dead until the device is rebooted. This patch reverts said commit partially: It changes the driver back to use request_irq instead of devm_request_irq, puts free_irq back in place, but keeps the remaining changes of the original patch. Reported-by:
Jon Ringle <jon@ringle.org> Signed-off-by:
Christian Riesch <christian.riesch@omicron.at> Cc: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Helge Deller authored
commit a2fb4d78 upstream. STI console is used on parisc and m68k HP machines. This patch partly reverts my previous commit and as such restores the fonts for the m68k machines. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Vaibhav Nagarnaik authored
commit 87291347 upstream. In event format strings, the array size is reported in two locations. One in array subscript and then via the "size:" attribute. The values reported there have a mismatch. For e.g., in sched:sched_switch the prev_comm and next_comm character arrays have subscript values as [32] where as the actual field size is 16. name: sched_switch ID: 301 format: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1;signed:0; field:int common_pid; offset:4; size:4; signed:1; field:char prev_comm[32]; offset:8; size:16; signed:1; field:pid_t prev_pid; offset:24; size:4; signed:1; field:int prev_prio; offset:28; size:4; signed:1; field:long prev_state; offset:32; size:8; signed:1; field:char next_comm[32]; offset:40; size:16; signed:1; field:pid_t next_pid; offset:56; size:4; signed:1; field:int next_prio; offset:60; size:4; signed:1; After bisection, the following commit was blamed: 92edca07 tracing: Use direct field, type and system names This commit removes the duplication of strings for field->name and field->type assuming that all the strings passed in __trace_define_field() are immutable. This is not true for arrays, where the type string is created in event_storage variable and field->type for all array fields points to event_storage. Use __stringify() to create a string constant for the type string. Also, get rid of event_storage and event_storage_mutex that are not needed anymore. also, an added benefit is that this reduces the overhead of events a bit more: text data bss dec hex filename 8424787 2036472 1302528 11763787 b3804b vmlinux 8420814 2036408 1302528 11759750 b37086 vmlinux.patched Link: http://lkml.kernel.org/r/1392349908-29685-1-git-send-email-vnagarnaik@google.com Cc: Laurent Chavey <chavey@google.com> Signed-off-by:
Vaibhav Nagarnaik <vnagarnaik@google.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Chris Wilson authored
commit 0f4706d2 upstream. We have reports of heavy screen corruption if we try to use the stolen memory reserved by the BIOS whilst the DMA-Remapper is active. This quirk may be only specific to a few machines or BIOSes, but first lets apply the big hammer and always disable use of stolen memory when DMAR is active. v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
commit 5c673b60 upstream. We need to enable interrupt processing before all the modeset state is set up. But that means we can fall over when we get a pipe underrun. This shouldn't happen as long as the bios works correctly but as usual this turns out to be wishful thinking. So disable error interrupts at irq install time and rely on the re-enabling code in the modeset functions to take care of this. Note that due to the SDE interrupt handling race we must uncondtionally enable all interrupt sources in SDEIER, hence no need to enable the SERR bit specifically. On gmch platforms we don't have an explicit enable/mask bit for fifo underruns. Fixing this up would require a bit of software tracking, hence is material for a separate patch. To make this possible we need to switch all gmch platforms to the new pipestat interrupt handling scheme Imre implemented for vlv, and then also add a safe form of sw state checking to __cpu_fifo_underrun_reporting_enabled a bit. v2: Also handle the ilk/snb cpu fifo underrun bits accordingly. Spotted by Ville. v3: Also handle the south interrupt underrun bits on ibx. Again spotted by Ville. Reported-by:
Rob Clark <robdclark@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ben Widawsky authored
commit 24bd9bf5 upstream. | has a higher precedence than ?. Therefore, the calculation doesn't do at all what you would expect. Thanks to Ken for convincing me that this was indeed the issue. Send me back to C programmer school, please. I'm sort of surprised PSR was continuing to work for people. It should be broken IMO (and it was broken for me, but I had assumed it never worked). Regression from: commit ed8546ac Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Nov 4 22:45:05 2013 -0800 drm/i915/bdw: Support eDP PSR Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com> Cc: Kenneth Graunke <kenneth.w.graunke@intel.com> Cc: Art Runyan <arthur.j.runyan@intel.com> Reported-by:
"Kumar, Kiran S" <kiran.s.kumar@intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Stefan Agner authored
commit 224aa3ed upstream. Vybrids PIT register is monitonic decreasing. However, sched_clock reading needs to be monitonic increasing. Use bitwise not to get the complement of the clock register. This fixes the clock going backward. Also, the clock now starts at 0 since we load the register with the maximum value at start. Signed-off-by:
Stefan Agner <stefan@agner.ch> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Cc: daniel.lezcano@linaro.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux@arm.linux.org.uk Link: http://lkml.kernel.org/r/d25af915993aec1b486be653eb86f748ddef54fe.1394057313.git.stefan@agner.chSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Charles Keepax authored
commit 749d3223 upstream. The snd_compr_open function would always return 0 even if the compressed ops open function failed, obviously this is incorrect. Looks like this was introduced by a small typo in: commit a0830dbd ALSA: Add a reference counter to card instance This patch returns the value from the compressed op as it should. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Fernando Luis Vazquez Cao authored
commit 47587fc0 upstream. I noticed that after hot unplugging a Logitech unifying receiver (drivers/hid/hid-logitech-dj.c) the kernel would occasionally spew a stack trace similar to this: usb 1-1.1.2: USB disconnect, device number 7 WARNING: CPU: 0 PID: 2865 at fs/sysfs/group.c:216 device_del+0x40/0x1b0() sysfs group ffffffff8187fa20 not found for kobject 'hidraw0' [...] CPU: 0 PID: 2865 Comm: upowerd Tainted: G W 3.14.0-rc4 #7 Hardware name: LENOVO 7783PN4/ , BIOS 9HKT43AUS 07/11/2011 0000000000000009 ffffffff814cd684 ffff880427ccfdf8 ffffffff810616e7 ffff88041ec61800 ffff880427ccfe48 ffff88041e444d80 ffff880426fab8e8 ffff880429359960 ffffffff8106174c ffffffff81714b98 0000000000000028 Call Trace: [<ffffffff814cd684>] ? dump_stack+0x41/0x51 [<ffffffff810616e7>] ? warn_slowpath_common+0x77/0x90 [<ffffffff8106174c>] ? warn_slowpath_fmt+0x4c/0x50 [<ffffffff81374fd0>] ? device_del+0x40/0x1b0 [<ffffffff8137516f>] ? device_unregister+0x2f/0x50 [<ffffffff813751fa>] ? device_destroy+0x3a/0x40 [<ffffffffa03ca245>] ? drop_ref+0x55/0x120 [hid] [<ffffffffa03ca3e6>] ? hidraw_release+0x96/0xb0 [hid] [<ffffffff811929da>] ? __fput+0xca/0x210 [<ffffffff8107fe17>] ? task_work_run+0x97/0xd0 [<ffffffff810139a9>] ? do_notify_resume+0x69/0xa0 [<ffffffff814dbd22>] ? int_signal+0x12/0x17 ---[ end trace 63f4a46f6566d737 ]--- During device removal hid_disconnect() is called via hid_hw_stop() to stop the device and free all its resources, including the sysfs files. The problem is that if a user space process, such as upowerd, holds a reference to a hidraw file the corresponding sysfs files will be kept around (drop_ref() does not call device_destroy() if the open counter is not 0) and it will be usb_disconnect() who, by calling device_del() for the USB device, will indirectly remove the sysfs files of the hidraw device (sysfs_remove_dir() is recursive these days). Because of this, by the time user space releases the last reference to the hidraw file and drop_ref() tries to destroy the device the sysfs files are already gone and the kernel will print the warning above. Fix this by calling device_destroy() at USB disconnect time. Signed-off-by:
Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
- 24 Mar, 2014 10 commits
-
-
Greg Kroah-Hartman authored
-
Zhang Rui authored
commit 89935315 upstream. Before commit b355cee8 (ACPI / resources: ignore invalid ACPI device resources), if acpi_dev_resource_memory()/acpi_dev_resource_io() returns false, it means the the resource is not a memeory/IO resource. But after commit b355cee8, those functions return false if the given memory/IO resource entry is invalid (the length of the resource is zero). This breaks pnpacpi_allocated_resource(), because it now recognizes the invalid memory/io resources as resources of unknown type. Thus users see confusing warning messages on machines with zero length ACPI memory/IO resources. Fix the problem by rearranging pnpacpi_allocated_resource() so that it calls acpi_dev_resource_memory() for memory type and IO type resources only, respectively. Fixes: b355cee8 (ACPI / resources: ignore invalid ACPI device resources) Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Reported-and-tested-by:
Markus Trippelsdorf <markus@trippelsdorf.de> Reported-and-tested-by:
Julian Wollrath <jwollrath@web.de> Reported-and-tested-by:
Paul Bolle <pebolle@tiscali.nl> [rjw: Changelog] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Filipe Brandenburger authored
commit 4fb1a86f upstream. Sometimes the cleanup after memcg hierarchy testing gets stuck in mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0. There may turn out to be several causes, but a major cause is this: the workitem to offline parent can get run before workitem to offline child; parent's mem_cgroup_reparent_charges() circles around waiting for the child's pages to be reparented to its lrus, but it's holding cgroup_mutex which prevents the child from reaching its mem_cgroup_reparent_charges(). Further testing showed that an ordered workqueue for cgroup_destroy_wq is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched stage on the way can mess up the order before reaching the workqueue. Instead, when offlining a memcg, call mem_cgroup_reparent_charges() on all its children (and grandchildren, in the correct order) to have their charges reparented first. Fixes: e5fca243 ("cgroup: use a dedicated workqueue for cgroup destruction") Signed-off-by:
Filipe Brandenburger <filbranden@google.com> Signed-off-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Tejun Heo <tj@kernel.org> Acked-by:
Michal Hocko <mhocko@suse.cz> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: <stable@vger.kernel.org> [v3.10+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Steve Capper authored
commit 84fe6826 upstream. Page table entries on ARM64 are 64 bits, and some pte functions such as pte_dirty return a bitwise-and of a flag with the pte value. If the flag to be tested resides in the upper 32 bits of the pte, then we run into the danger of the result being dropped if downcast. For example: gather_stats(page, md, pte_dirty(*pte), 1); where pte_dirty(*pte) is downcast to an int. This patch adds a double logical invert to all the pte_ accessors to ensure predictable downcasting. Signed-off-by:
Steve Capper <steve.capper@linaro.org> [steve.capper@linaro.org: rebased patch to leave pte_write alone to allow for merge with 3.13 stable] Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Nicholas Bellinger authored
commit 5837c80e upstream. This patch addresses a bug in bio_integrity_verify() code that has been causing DIF READ verify operations to be silently skipped. The issue is that bio->bi_idx will have been incremented within bio_advance() code in the normal blk_update_request() -> req_bio_endio() completion path, and bio_integrity_verify() is using bio_for_each_segment() which starts the bio segment walk at the current bio->bi_idx. So instead use bio_for_each_segment_all() to always start the bio segment walk from zero, regardless of the current bio->bi_idx value after bio_advance() has been called. (Context change for v3.10.y -> v3.13.y code - nab) Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Qais Yousef authored
commit 87c99203 upstream. The file uses u16 type but doesn't include its definition explicitly I was getting this error when including this header in my driver: arch/mips/include/asm/mipsregs.h:644:33: error: unknown type name ‘u16’ Signed-off-by:
Qais Yousef <qais.yousef@imgtec.com> Reviewed-by:
Steven J. Hill <Steven.Hill@imgtec.com> Acked-by:
-
Oleg Drokin authored
commit d22e6338 upstream. Recent changes to retry on ESTALE in linkat (commit 442e31ca) introduced a mountpoint reference leak and a small memory leak in case a filesystem link operation returns ESTALE which is pretty normal for distributed filesystems like lustre, nfs and so on. Free old_path in such a case. [AV: there was another missing path_put() nearby - on the previous goto retry] Signed-off-by:
Oleg Drokin: <green@linuxhacker.ru> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Shuah Khan authored
commit acc3d5ce upstream. Change "dummy supplies not allowed" error message to warning instead, as this is a just warning message with no change to the behavior. [Added a CC to stable since some other bug fixes cause this to come up more frequently on PCs which is how it was noticed -- broonie] Signed-off-by:
Shuah Khan <shuah.kh@samsung.com> Signed-off-by:
-
Roman Volkov authored
commit 1f91ecc1 upstream. When selecting the audio output destinations (headphones, FP headphones, multichannel output), the channel routing should be changed depending on what destination selected. Also unnecessary I2S channels are digitally muted. This function called when the user selects the destination in the ALSA mixer. Signed-off-by:
Roman Volkov <v1ron@mail.ru> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Dirk Brandewie authored
commit 61d8d2ab upstream. A documentation update exposed the existance of the turbo ratio register. Update baytrail support to use the turbo range. Signed-off-by:
Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by:
-
