- 24 Apr, 2018 40 commits
-
-
Dmitry Torokhov authored
commit 2e210bbb upstream. The commit 581c4484 ("HID: input: map digitizer battery usage") assumed that devices having input (qas opposed to feature) report for battery strength would report the data on their own, without the need to be polled by the kernel; unfortunately it is not so. Many wireless mice do not send unsolicited reports with battery strength data and have to be polled explicitly. As a complication, stylus devices on digitizers are not normally connected to the base and thus can not be polled - the base can only determine battery strength in the stylus when it is in proximity. To solve this issue, we add a special flag that tells the kernel to avoid polling the device (and expect unsolicited reports) and set it when report field with physical usage of digitizer stylus (HID_DG_STYLUS). Unless this flag is set, and we have not seen the unsolicited reports, the kernel will attempt to poll the device when userspace attempts to read "capacity" and "state" attributes of power_supply object corresponding to the devices battery. Fixes: 581c4484 ("HID: input: map digitizer battery usage") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198095 Cc: stable@vger.kernel.org Reported-and-tested-by:
Martin van Es <martin@mrvanes.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Theodore Ts'o authored
commit d848e5f8 upstream. Add a new ioctl which forces the the crng to be reseeded. Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
-
Theodore Ts'o authored
commit 0bb29a84 upstream. Reported-by:
Jann Horn <jannh@google.com> Fixes: 1e7f583a ("random: make /dev/urandom scalable for silly...") Cc: stable@kernel.org # 4.8+ Signed-off-by:
-
Theodore Ts'o authored
commit dc12baac upstream. add_device_randomness() use of crng_fast_load() was highly problematic. Some callers of add_device_randomness() can pass in a large amount of static information. This would immediately promote the crng_init state from 0 to 1, without really doing much to initialize the primary_crng's internal state with something even vaguely unpredictable. Since we don't have the speed constraints of add_interrupt_randomness(), we can do a better job mixing in the what unpredictability a device driver or architecture maintainer might see fit to give us, and do it in a way which does not bump the crng_init_cnt variable. Also, since add_device_randomness() doesn't bump any entropy accounting in crng_init state 0, mix the device randomness into the input_pool entropy pool as well. This is related to CVE-2018-1108. Reported-by:
-
Theodore Ts'o authored
commit 43838a23 upstream. The crng_init variable has three states: 0: The CRNG is not initialized at all 1: The CRNG has a small amount of entropy, hopefully good enough for early-boot, non-cryptographical use cases 2: The CRNG is fully initialized and we are sure it is safe for cryptographic use cases. The crng_ready() function should only return true once we are in the last state. This addresses CVE-2018-1108. Reported-by:
-
Hui Wang authored
commit a3dafb22 upstream. There are two front mics on this machine, if we don't adjust the location for one of them, they will have the same mixer name, pulseaudio can't handle this situation. After applying this FIXUP, they will have different mixer name, then pulseaudio can handle them correctly. Cc: <stable@vger.kernel.org> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Hui Wang authored
commit 3ce0d5aa upstream. Otherwise, the pin will be regarded as microphone, and the jack name is "Mic Phantom", it is always on in the pulseaudio even nothing is plugged into the jack. So the UI is confusing to users since the microphone always shows up in the UI even there is no microphone plugged. After adding this flag, the jack name is "Headset Mic Phantom", then the pulseaudio can handle its detection correctly. Fixes: f0ba9d69 ("ALSA: hda/realtek - Fix Dell headset Mic can't record") Cc: <stable@vger.kernel.org> Signed-off-by:
-
David Wang authored
commit af52f998 upstream. This patch is used to tell kernel that new VIA HDAC controller also support no-snoop path. [ minor coding style fix by tiwai ] Signed-off-by:
David Wang <davidwang@zhaoxin.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit 8a56ef4f upstream. Some rawmidi compat ioctls lack of the input substream checks (although they do check only for rfile->output). This many eventually lead to an Oops as NULL substream is passed to the rawmidi core functions. Fix it by adding the proper checks before each function call. The bug was spotted by syzkaller. Reported-by: syzbot+f7a0348affc3b67bc617@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
-
Fabián Inostroza authored
commit 7ecb46e9 upstream. Sending MIDI messages to a PODxt through the USB connection shows "usb_submit_urb failed" in dmesg and the message is not received by the POD. The error is caused because in the funcion send_midi_async() in midi.c there is a call to usb_sndbulkpipe() for endpoint 3 OUT, but the PODxt USB descriptor shows that this endpoint it's an interrupt endpoint. Patch tested with PODxt only. [ The bug has been present from the very beginning in the staging driver time, but Fixes below points to the commit moving to sound/ directory so that the fix can be cleanly applied -- tiwai ] Fixes: 61864d84 ("ALSA: move line6 usb driver into sound/usb") Signed-off-by:
Fabián Inostroza <fabianinostroza@udec.cl> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Paul Parsons authored
commit 85e290d9 upstream. Two years ago I tried an AMD Radeon E8860 embedded GPU with the drm driver. The dmesg output included driver warnings about an invalid PCIe lane width. Tracking the problem back led to si_set_pcie_lane_width_in_smc(). The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere. Applying the increment silenced the warnings. The code has not changed since, so either my analysis was incorrect or the bug has gone unnoticed. Hence submitting this as an RFC. Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
Paul Parsons <lost.distance@yahoo.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Nico Sneck authored
commit b1550359 upstream. With this the dGPU turns on correctly. Signed-off-by:
Nico Sneck <nicosneck@hotmail.com> Signed-off-by:
-
Marc Zyngier authored
commit 5f9e93fe upstream. Calling request_irq() followed by disable_irq() is usually a bad idea, specially if the interrupt can be pending, and you're not yet in a position to handle it. This is exactly what happens on my kevin system when rebooting in a second kernel using kexec: Some interrupt is left pending from the previous kernel, and we take it too early, before disable_irq() could do anything. Let's clear the pending interrupts as we initialize the HW, and move the interrupt request after that point. This ensures that we're in a sane state when the interrupt is requested. Cc: stable@vger.kernel.org Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com> [adapted to recent rockchip-drm changes] Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20180220130120.5254-2-marc.zyngier@arm.comSigned-off-by:
-
Alex Deucher authored
commit 20ca25e8 upstream. Required for dpm setup on some asics. Fixes a NULL dereference on asics that require it. Acked-by:
Abel Garcia Dorta <mercuriete@yahoo.es> Signed-off-by:
-
Alex Deucher authored
commit 41212e2f upstream. The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere. Port of the radeon fix to amdgpu. Acked-by:
-
Alex Deucher authored
commit 4a8e06f7 upstream. Needs to be a 32 bit mask. Acked-by:
Huang Rui <ray.huang@amd.com> Reviewed-by:
-
Bas Nieuwenhuizen authored
commit a20ee0b1 upstream. If these bos are evicted and are in the validated list things blow up, so do not put them in there. Notably, that tries to add the bo to the LRU twice, which results in a BUG_ON in ttm_bo.c. While for the bo_list an alternative would be to not allow always valid bos in there, that does not work for the user fence. v2: Fixed whitespace issue pointed out by checkpatch.pl Signed-off-by:
Bas Nieuwenhuizen <basni@chromium.org> Reviewed-by:
-
Alex Deucher authored
commit 13b40935 upstream. _PR3 doesn't seem to work properly, use ATPX instead. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104064Reviewed-by:
-
Takashi Iwai authored
commit e15dc99d upstream. The commit 02a5d692 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") split the PCM preparation code to a locked version, and it added a sanity check of runtime->oss.prepare flag along with the change. This leaded to an endless loop when the stream gets XRUN: namely, snd_pcm_oss_write3() and co call snd_pcm_oss_prepare() without setting runtime->oss.prepare flag and the loop continues until the PCM state reaches to another one. As the function is supposed to execute the preparation unconditionally, drop the invalid state check there. The bug was triggered by syzkaller. Fixes: 02a5d692 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") Reported-by: syzbot+150189c103427d31a053@syzkaller.appspotmail.com Reported-by: syzbot+7e3f31a52646f939c052@syzkaller.appspotmail.com Reported-by: syzbot+4f2016cf5185da7759dc@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit f6d297df upstream. The previous fix 40cab6e8 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams") introduced some mutex unbalance; the check of runtime->oss.rw_ref was inserted in a wrong place after the mutex lock. This patch fixes the inconsistency by rewriting with the helper functions to lock/unlock parameters with the stream check. Fixes: 40cab6e8 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit 40cab6e8 upstream. OSS PCM stream management isn't modal but it allows ioctls issued at any time for changing the parameters. In the previous hardening patch ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write"), we covered these races and prevent the corruption by protecting the concurrent accesses via params_lock mutex. However, this means that some ioctls that try to change the stream parameter (e.g. channels or format) would be blocked until the read/write finishes, and it may take really long. Basically changing the parameter while reading/writing is an invalid operation, hence it's even more user-friendly from the API POV if it returns -EBUSY in such a situation. This patch adds such checks in the relevant ioctls with the addition of read/write access refcount. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit 02a5d692 upstream. Although we apply the params_lock mutex to the whole read and write operations as well as snd_pcm_oss_change_params(), we may still face some races. First off, the params_lock is taken inside the read and write loop. This is intentional for avoiding the too long locking, but it allows the in-between parameter change, which might lead to invalid pointers. We check the readiness of the stream and set up via snd_pcm_oss_make_ready() at the beginning of read and write, but it's called only once, by assuming that it remains ready in the rest. Second, many ioctls that may change the actual parameters (i.e. setting runtime->oss.params=1) aren't protected, hence they can be processed in a half-baked state. This patch is an attempt to plug these holes. The stream readiness check is moved inside the read/write inner loop, so that the stream is always set up in a proper state before further processing. Also, each ioctl that may change the parameter is wrapped with the params_lock for avoiding the races. The issues were triggered by syzkaller in a few different scenarios, particularly the one below appearing as GPF in loopback_pos_update. Reported-by: syzbot+c4227aec125487ec3efa@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Signed-off-by:
-
Takashi Iwai authored
commit c64ed5dd upstream. Fix the last standing EINTR in the whole subsystem. Use more correct ERESTARTSYS for pending signals. Signed-off-by:
-
Alex Williamson authored
commit cf0d53ba upstream. MRRS defines the maximum read request size a device is allowed to make. Drivers will often increase this to allow more data transfer with a single request. Completions to this request are bound by the MPS setting for the bus. Aside from device quirks (none known), it doesn't seem to make sense to set an MRRS value less than MPS, yet this is a likely scenario given that user drivers do not have a system-wide view of the PCI topology. Virtualize MRRS such that the user can set MRRS >= MPS, but use MPS as the floor value that we'll write to hardware. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Igor Pylypiv authored
commit 977f6f68 upstream. F71808FG_FLAG_WD_EN defines bit position, not a bitmask Signed-off-by:
Igor Pylypiv <igor.pylypiv@gmail.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Sean Wang authored
commit 55a5fcaf upstream. Just add binding for a fixed-factor clock axisel_d4, which would be referenced by PWM devices on MT7623 or MT2701 SoC. Cc: stable@vger.kernel.org Fixes: 1de9b216 ("clk: mediatek: Add dt-bindings for MT2701 clocks") Signed-off-by:
Sean Wang <sean.wang@mediatek.com> Reviewed-by:
Rob Herring <robh@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: devicetree@vger.kernel.org Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Mikhail Lappo authored
commit cf1ba1d7 upstream. When device boots with T > T_trip_1 and requests interrupt, the race condition takes place. The interrupt comes before THERMAL_DEVICE_ENABLED is set. This leads to an attempt to reading sensor value from irq and disabling the sensor, based on the data->mode field, which expected to be THERMAL_DEVICE_ENABLED, but still stays as THERMAL_DEVICE_DISABLED. Afher this issue sensor is never re-enabled, as the driver state is wrong. Fix this problem by setting the 'data' members prior to requesting the interrupts. Fixes: 37713a1e ("thermal: imx: implement thermal alarm interrupt handling") Cc: <stable@vger.kernel.org> Signed-off-by:
Mikhail Lappo <mikhail.lappo@esrlabs.com> Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
Zhang Rui <rui.zhang@intel.com> Signed-off-by:
-
Ryo Kodama authored
commit 6225f9c6 upstream. This patch fixes an issue that is possible to set mismatch value to duty for R-Car PWM if we input the following commands: # cd /sys/class/pwm/<pwmchip>/ # echo 0 > export # cd pwm0 # echo 30 > period # echo 30 > duty_cycle # echo 0 > duty_cycle # cat duty_cycle 0 # echo 1 > enable --> Then, the actual duty_cycle is 30, not 0. So, this patch adds a condition into rcar_pwm_config() to fix this issue. Signed-off-by:
Ryo Kodama <ryo.kodama.vz@renesas.com> [shimoda: revise the commit log and add Fixes and Cc tags] Fixes: ed6c1476 ("pwm: Add support for R-Car PWM Timer") Cc: Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Boris Brezillon authored
commit 75387237 upstream. In order to enable a PLL, not only the PLL has to be powered up and locked, but you also have to de-assert the reset signal. The last part was missing. Add it so PLLs that were not enabled by the FW/bootloader can be enabled from Linux. Fixes: 41691b88 ("clk: bcm2835: Add support for programming the audio domain clocks") Cc: <stable@vger.kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@bootlin.com> Reviewed-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Sean Wang authored
commit 89cd7aec upstream. The clock for which all PWM devices on MT7623 or MT2701 actually depending on has to be divided by four from its parent clock axi_sel in the clock path prior to PWM devices. Consequently, adding a fixed-factor clock axisel_d4 as one-fourth of clock axi_sel allows that PWM devices can have the correct resolution calculation. Cc: stable@vger.kernel.org Fixes: e9862118 ("clk: mediatek: Add MT2701 clock support") Signed-off-by:
-
Arnd Bergmann authored
commit ce33f284 upstream. When we build this driver with on x86-32, gcc produces a false-positive warning: drivers/clk/renesas/clk-sh73a0.c: In function 'sh73a0_cpg_clocks_init': drivers/clk/renesas/clk-sh73a0.c:155:10: error: 'parent_name' may be used uninitialized in this function [-Werror=maybe-uninitialized] return clk_register_fixed_factor(NULL, name, parent_name, 0, We can work around that warning by adding a fake initialization, I tried and failed to come up with any better workaround. This is currently one of few remaining warnings for a 4.14.y randconfig build, so it would be good to also have it backported at least to that version. Older versions have more randconfig warnings, so we might not care. I had not noticed this earlier, because one patch in my randconfig test tree removes the '-ffreestanding' option on x86-32, and that avoids the warning. The -ffreestanding flag was originally global but moved into arch/i386 by Andi Kleen in commit 6edfba1b ("[PATCH] x86_64: Don't define string functions to builtin") as a 'temporary workaround'. Like many temporary hacks, this turned out to be rather long-lived, from all I can tell we still need a simple fix to asm/string_32.h before it can be removed, but I'm not sure about how to best do that. Cc: stable@vger.kernel.org Cc: Andi Kleen <ak@linux.intel.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Richard Genoud authored
commit 6a4a4595 upstream. Clearfog boards can come with a CPU clocked at 1600MHz (commercial) or 1333MHz (industrial). They have also some dip-switches to select a different clock (666, 800, 1066, 1200). The funny thing is that the recovery button is on the MPP34 fq selector. So, when booting an industrial board with this button down, the frequency 666MHz is selected (and the kernel didn't boot). This patch add all the missing clocks. The only mode I didn't test is 2GHz (uboot found 4294MHz instead :/ ). Fixes: 0e85aece ("clk: mvebu: add clock support for Armada 380/385") Cc: <stable@vger.kernel.org> # 3.16.x: 9593f4f5: clk: mvebu: armada-38x: add support for 1866MHz variants Cc: <stable@vger.kernel.org> # 3.16.x Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Acked-by:
Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by:
-
Sinan Kaya authored
commit 1b30dfd3 upstream. Per PCIe r3.1, sec 2.2.6.2 and 7.8.4, a Requester may not use 8-bit Tags unless its Extended Tag Field Enable is set, but all Receivers/Completers must handle 8-bit Tags correctly regardless of their Extended Tag Field Enable. Some devices do not handle 8-bit Tags as Completers, so add a quirk for them. If we find such a device, we disable Extended Tags for the entire hierarchy to make peer-to-peer DMA possible. The Broadcom HT1100/HT2000/HT2100 seems to have issues with handling 8-bit tags. Mark it as broken. This fixes Xorg hangs and unresponsive keyboards with errors like this: radeon 0000:06:00.0: GPU lockup (current fence id 0x000000000000000e last fence id 0x0000000000000 [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) [drm:r600_resume [radeon]] *ERROR* r600 startup failed on resume Fixes: 60db3a4d ("PCI: Enable PCIe Extended Tags if supported") Link: https://bugzilla.kernel.org/show_bug.cgi?id=196197Signed-off-by:
Sinan Kaya <okaya@codeaurora.org> Signed-off-by:
Bjorn Helgaas <helgaas@kernel.org> CC: stable@vger.kernel.org # v4.11: 62ce94a7 PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken CC: stable@vger.kernel.org # v4.11 Signed-off-by:
-
Masaharu Hayakawa authored
commit fc167daf upstream. If an error was detected when CMD23 was issued, command sequence should be terminated with errors and CMD23 should be issued after retuning. Fixes: 8b22c3c1 ("mmc: tmio: add CMD23 support") Signed-off-by:
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: <stable@vger.kernel.org> # 4.13+ Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Alex Smith authored
commit a04f0017 upstream. A spinlock is held while updating the internal copy of the IRQ mask, but not while writing it to the actual IMASK register. After the lock is released, an IRQ can occur before the IMASK register is written. If handling this IRQ causes the mask to be changed, when the handler returns back to the middle of the first mask update, a stale value will be written to the mask register. If this causes an IRQ to become unmasked that cannot have its status cleared by writing a 1 to it in the IREG register, e.g. the SDIO IRQ, then we can end up stuck with the same IRQ repeatedly being fired but not handled. Normally the MMC IRQ handler attempts to clear any unexpected IRQs by writing IREG, but for those that cannot be cleared in this way then the IRQ will just repeatedly fire. This was resulting in lockups after a while of using Wi-Fi on the CI20 (GitHub issue #19). Resolve by holding the spinlock until after the IMASK register has been updated. Cc: stable@vger.kernel.org Link: https://github.com/MIPS/CI20_linux/issues/19 Fixes: 61bfbdb8 ("MMC: Add support for the controller on JZ4740 SoCs.") Tested-by:
Mathieu Malaterre <malat@debian.org> Signed-off-by:
Alex Smith <alex.smith@imgtec.com> Signed-off-by:
-
Lu Baolu authored
commit bbe4b3af upstream. A memory block was allocated in intel_svm_bind_mm() but never freed in a failure path. This patch fixes this by free it to avoid memory leakage. Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Lu Baolu <baolu.lu@linux.intel.com> Fixes: 2f26e0a9 ('iommu/vt-d: Add basic SVM PASID support') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Krzysztof Mazur authored
commit 4d1a535b upstream. glibc 2.26 removed the 'struct ucontext' to "improve" POSIX compliance and break programs, including User Mode Linux. Fix User Mode Linux by using POSIX ucontext_t. This fixes: arch/um/os-Linux/signal.c: In function 'hard_handler': arch/um/os-Linux/signal.c:163:22: error: dereferencing pointer to incomplete type 'struct ucontext' mcontext_t *mc = &uc->uc_mcontext; arch/x86/um/stub_segv.c: In function 'stub_segv_handler': arch/x86/um/stub_segv.c:16:13: error: dereferencing pointer to incomplete type 'struct ucontext' &uc->uc_mcontext); Cc: stable@vger.kernel.org Signed-off-by:
Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Jason A. Donenfeld authored
commit 530ba6c7 upstream. Recent libcs have gotten a bit more strict, so we actually need to include the right headers and use the right types. This enables UML to compile again. Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Steven Rostedt (VMware) authored
commit 2a872fa4 upstream. The ring buffer is made up of a link list of pages. When making the ring buffer bigger, it will allocate all the pages it needs before adding to the ring buffer, and if it fails, it frees them and returns an error. This makes increasing the ring buffer size an all or nothing action. When this was first created, the pages were allocated with "NORETRY". This was to not cause any Out-Of-Memory (OOM) actions from allocating the ring buffer. But NORETRY was too strict, as the ring buffer would fail to expand even when there's memory available, but was taken up in the page cache. Commit 84861885 ("tracing/ring_buffer: Try harder to allocate") changed the allocating from NORETRY to RETRY_MAYFAIL. The RETRY_MAYFAIL would allocate from the page cache, but if there was no memory available, it would simple fail the allocation and not trigger an OOM. This worked fine, but had one problem. As the ring buffer would allocate one page at a time, it could take up all memory in the system before it failed to allocate and free that memory. If the allocation is happening and the ring buffer allocates all memory and then tries to take more than available, its allocation will not trigger an OOM, but if there's any allocation that happens someplace else, that could trigger an OOM, even though once the ring buffer's allocation fails, it would free up all the previous memory it tried to allocate, and allow other memory allocations to succeed. Commit d02bd27b ("mm/page_alloc.c: calculate 'available' memory in a separate function") separated out si_mem_availble() as a separate function that could be used to see how much memory is available in the system. Using this function to make sure that the ring buffer could be allocated before it tries to allocate pages we can avoid allocating all memory in the system and making it vulnerable to OOMs if other allocations are taking place. Link: http://lkml.kernel.org/r/1522320104-6573-1-git-send-email-zhaoyang.huang@spreadtrum.com CC: stable@vger.kernel.org Cc: linux-mm@kvack.org Fixes: 84861885 ("tracing/ring_buffer: Try harder to allocate") Requires: d02bd27b ("mm/page_alloc.c: calculate 'available' memory in a separate function") Reported-by:
Zhaoyang Huang <huangzhaoyang@gmail.com> Tested-by:
Joel Fernandes <joelaf@google.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Dan Williams authored
commit 0731de47 upstream. Per the ACPI specification the only functional purpose for a DIMM Control Region to be mapped into the system physical address space, from an OSPM perspective, is to support block-apertures. However, there are some BIOSen that publish DIMM Control Region SPA entries for pre-boot environment consumption. Undo the kernel policy of generating disabled 'ndblk' regions when this configuration is detected. Cc: <stable@vger.kernel.org> Fixes: 1f7df6f8 ("libnvdimm, nfit: regions (block-data-window...)") Reviewed-by:
Toshi Kani <toshi.kani@hpe.com> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
