- 16 Jan, 2015 18 commits
-
-
Ard Biesheuvel authored
commit 0e63ea48 upstream. The early ioremap support introduced by patch bf4b558e ("arm64: add early_ioremap support") failed to add a call to early_ioremap_reset() at an appropriate time. Without this call, invocations of early_ioremap etc. that are done too late will go unnoticed and may cause corruption. This is exactly what happened when the first user of this feature was added in patch f84d0275 ("arm64: add EFI runtime services"). The early mapping of the EFI memory map is unmapped during an early initcall, at which time the early ioremap support is long gone. Fix by adding the missing call to early_ioremap_reset() to setup_arch(), and move the offending early_memunmap() to right after the point where the early mapping of the EFI memory map is last used. Fixes: f84d0275 ("arm64: add EFI runtime services") Signed-off-by:
Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> [ luis: backported to 3.16: adjusted context ] Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
J. Bruce Fields authored
commit 49a068f8 upstream. A struct xdr_stream at a page boundary might point to the end of one page or the beginning of the next, but xdr_truncate_encode isn't prepared to handle the former. This can cause corruption of NFSv4 READDIR replies in the case that a readdir entry that would have exceeded the client's dircount/maxcount limit would have ended exactly on a 4k page boundary. You're more likely to hit this case on large directories. Other xdr_truncate_encode callers are probably also affected. Reported-by:
Holger Hoffstätte <holger.hoffstaette@googlemail.com> Tested-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Wei Yang authored
commit 7c2e211f upstream. Current vfio-pci just supports normal pci device, so vfio_pci_probe() will return if the pci device is not a normal device. While current code makes a mistake. PCI_HEADER_TYPE is the offset in configuration space of the device type, but we use this value to mask the type value. This patch fixs this by do the check directly on the pci_dev->hdr_type. Signed-off-by:
Wei Yang <weiyang@linux.vnet.ibm.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Aaron Plattner authored
commit 60834b73 upstream. Vendor ID 0x10de0072 is used by a yet-to-be-named GPU chip. Signed-off-by:
Aaron Plattner <aplattner@nvidia.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Linus Torvalds authored
commit fee7e49d upstream. Jay Foad reports that the address sanitizer test (asan) sometimes gets confused by a stack pointer that ends up being outside the stack vma that is reported by /proc/maps. This happens due to an interaction between RLIMIT_STACK and the guard page: when we do the guard page check, we ignore the potential error from the stack expansion, which effectively results in a missing guard page, since the expected stack expansion won't have been done. And since /proc/maps explicitly ignores the guard page (commit d7824370: "mm: fix up some user-visible effects of the stack guard page"), the stack pointer ends up being outside the reported stack area. This is the minimal patch: it just propagates the error. It also effectively makes the guard page part of the stack limit, which in turn measn that the actual real stack is one page less than the stack limit. Let's see if anybody notices. We could teach acct_stack_growth() to allow an extra page for a grow-up/grow-down stack in the rlimit test, but I don't want to add more complexity if it isn't needed. Reported-and-tested-by:
Jay Foad <jay.foad@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Rafael J. Wysocki authored
commit 1b1f3e16 upstream. If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Alex Deucher authored
commit 02ae7af5 upstream. Enabling bapm seems to cause clocking problems on some KV configurations. Disable it by default for now. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 410cce2a upstream. The check was already in place in the dp mode_valid check, but radeon_dp_get_dp_link_clock() never returned the high clock mode_valid was checking for because that function clipped the clock based on the hw capabilities. Add an explicit check in the mode_valid function. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87172Signed-off-by:
-
Alex Deucher authored
commit 5665c3eb upstream. Make it consistent with the sad code for other asics to deal with monitors that don't report sads. bug: https://bugzilla.kernel.org/show_bug.cgi?id=89461Signed-off-by:
-
Alex Deucher authored
commit fbedf1c3 upstream. Enable all three in the driver. Early documentation indicated the 3rd one was used for something else, but that is not the case. v2: handle disable as well Signed-off-by:
-
Takashi Iwai authored
commit c507de88 upstream. stac_store_hints() does utterly wrong for masking the values for gpio_dir and gpio_data, likely due to copy&paste errors. Fortunately, this feature is used very rarely, so the impact must be really small. Reported-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Felipe Balbi authored
commit 7ce67a38 upstream. The CPSW IP implements pulse-signaled interrupts. Due to that we must write a correct, pre-defined value to the CPDMA_MACEOIVECTOR register so the controller generates a pulse on the correct IRQ line to signal the End Of Interrupt. The way the driver is written today, all four IRQ lines are requested using the same IRQ handler and, because of that, we could fall into situations where a TX IRQ fires but we tell the controller that we ended an RX IRQ (or vice-versa). This situation triggers an IRQ storm on the reserved IRQ 127 of INTC which will in turn call ack_bad_irq() which will, then, print a ton of: unexpected IRQ trap at vector 00 In order to fix the problem, we are moving all calls to cpdma_ctlr_eoi() inside the IRQ handler and making sure we *always* write the correct value to the CPDMA_MACEOIVECTOR register. Note that the algorithm assumes that IRQ numbers and value-to-be-written-to-EOI are proportional, meaning that a write of value 0 would trigger an EOI pulse for the RX_THRESHOLD Interrupt and that's the IRQ number sitting in the 0-th index of our irqs_table array. This, however, is safe at least for current implementations of CPSW so we will refrain from making the check smarter (and, as a side-effect, slower) until we actually have a platform where IRQ lines are swapped. This patch has been tested for several days with AM335x- and AM437x-based platforms. AM57x was left out because there are still pending patches to enable ethernet in mainline for that platform. A read of the TRM confirms the statement on previous paragraph. Reported-by:
Yegor Yefremov <yegorslists@googlemail.com> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly) Signed-off-by:
Felipe Balbi <balbi@ti.com> Acked-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Chris Mason authored
commit 6f896054 upstream. Commit 1d52c78a (Btrfs: try not to ENOSPC on log replay) added a check to skip delayed inode updates during log replay because it confuses the enospc code. But the delayed processing will end up ignoring delayed refs from log replay because the inode itself wasn't put through the delayed code. This can end up triggering a warning at commit time: WARNING: CPU: 2 PID: 778 at fs/btrfs/delayed-inode.c:1410 btrfs_assert_delayed_root_empty+0x32/0x34() Which is repeated for each commit because we never process the delayed inode ref update. The fix used here is to change btrfs_delayed_delete_inode_ref to return an error if we're currently in log replay. The caller will do the ref deletion immediately and everything will work properly. Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Alan Stern authored
commit 511833ac upstream. Commit ac61d195 (scsi: set correct completion code in scsi_send_eh_cmnd()) introduced a bug. It changed the stored return value from a queuecommand call, but it didn't take into account that the return value was used again later on. This patch fixes the bug by changing the later usage. There is a big comment in the middle of scsi_send_eh_cmnd() which does a good job of explaining how the routine works. But it mentions a "rtn = FAILURE" value that doesn't exist in the code. This patch adjusts the code to match the comment (I assume the comment is right and the code is wrong). This fixes Bugzilla #88341. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-by:
Андрей Аладьев <aladjev.andrew@gmail.com> Tested-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Steev Klimaszewski authored
commit 007487f1 upstream. Currently we enable Exynos devices in the multi v7 defconfig, however, when testing on my ODROID-U3, I noticed that USB was not working. Enabling this option causes USB to work, which enables networking support as well since the ODROID-U3 has networking on the USB bus. [arnd] Support for odroid-u3 was added in 3.10, so it would be nice to backport this fix at least that far. Signed-off-by:
Steev Klimaszewski <steev@gentoo.org> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Tomi Valkeinen authored
commit 30ea9c52 upstream. fb_deferred_io_fsync() returns the value of schedule_delayed_work() as an error code, but schedule_delayed_work() does not return an error. It returns true/false depending on whether the work was already queued. Fix this by ignoring the return value of schedule_delayed_work(). Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Tomi Valkeinen authored
commit 92b004d1 upstream. If the probe of an fb driver has been deferred due to missing dependencies, and the probe is later ran when a module is loaded, the fbdev framework will try to find a logo to use. However, the logos are __initdata, and have already been freed. This causes sometimes page faults, if the logo memory is not mapped, sometimes other random crashes as the logo data is invalid, and sometimes nothing, if the fbdev decides to reject the logo (e.g. the random value depicting the logo's height is too big). This patch adds a late_initcall function to mark the logos as freed. In reality the logos are freed later, and fbdev probe may be ran between this late_initcall and the freeing of the logos. In that case we will miss drawing the logo, even if it would be possible. Signed-off-by:
-
Andy Lutomirski authored
commit 1ddf0b1b upstream. In Linux 3.18 and below, GCC hoists the lsl instructions in the pvclock code all the way to the beginning of __vdso_clock_gettime, slowing the non-paravirt case significantly. For unknown reasons, presumably related to the removal of a branch, the performance issue is gone as of e76b027e x86,vdso: Use LSL unconditionally for vgetcpu but I don't trust GCC enough to expect the problem to stay fixed. There should be no correctness issue, because the __getcpu calls in __vdso_vlock_gettime were never necessary in the first place. Note to stable maintainers: In 3.18 and below, depending on configuration, gcc 4.9.2 generates code like this: 9c3: 44 0f 03 e8 lsl %ax,%r13d 9c7: 45 89 eb mov %r13d,%r11d 9ca: 0f 03 d8 lsl %ax,%ebx This patch won't apply as is to any released kernel, but I'll send a trivial backported version if needed. [ Backported by Andy Lutomirski. Should apply to all affected versions. This fixes a functionality bug as well as a performance bug: buggy kernels can infinite loop in __vdso_clock_gettime on affected compilers. See, for exammple: https://bugzilla.redhat.com/show_bug.cgi?id=1178975 ] Fixes: 51c19b4f x86: vdso: pvclock gettime support Cc: Marcelo Tosatti <mtosatti@redhat.com> Acked-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Andy Lutomirski <luto@amacapital.net> [ luis: backported to 3.16: used Andy's backport for stable kernels ] Signed-off-by:
-
- 15 Jan, 2015 22 commits
-
-
Andrew Jackson authored
commit 3475c3d0 upstream. Flush the FIFOs when the stream is prepared for use. This avoids an inadvertent swapping of the left/right channels if the FIFOs are not empty at startup. Signed-off-by:
Andrew Jackson <Andrew.Jackson@arm.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Ilia Mirkin authored
commit 4761703b upstream. Several users have, over time, reported issues with MSI on these IGPs. They're old, rarely available, and MSI doesn't provide such huge advantages on them. Just disable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87361 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74492 Fixes: fa8c9ac7 ("drm/nv4c/mc: nv4x igp's have a different msi rearm register") Signed-off-by:
Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Andy Lutomirski authored
commit 394f56fe upstream. The theory behind vdso randomization is that it's mapped at a random offset above the top of the stack. To avoid wasting a page of memory for an extra page table, the vdso isn't supposed to extend past the lowest PMD into which it can fit. Other than that, the address should be a uniformly distributed address that meets all of the alignment requirements. The current algorithm is buggy: the vdso has about a 50% probability of being at the very end of a PMD. The current algorithm also has a decent chance of failing outright due to incorrect handling of the case where the top of the stack is near the top of its PMD. This fixes the implementation. The paxtest estimate of vdso "randomisation" improves from 11 bits to 18 bits. (Disclaimer: I don't know what the paxtest code is actually calculating.) It's worth noting that this algorithm is inherently biased: the vdso is more likely to end up near the end of its PMD than near the beginning. Ideally we would either nix the PMD sharing requirement or jointly randomize the vdso and the stack to reduce the bias. In the mean time, this is a considerable improvement with basically no risk of compatibility issues, since the allowed outputs of the algorithm are unchanged. As an easy test, doing this: for i in `seq 10000` do grep -P vdso /proc/self/maps |cut -d- -f1 done |sort |uniq -d used to produce lots of output (1445 lines on my most recent run). A tiny subset looks like this: 7fffdfffe000 7fffe01fe000 7fffe05fe000 7fffe07fe000 7fffe09fe000 7fffe0bfe000 7fffe0dfe000 Note the suspicious fe000 endings. With the fix, I get a much more palatable 76 repeated addresses. Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Ville Syrjälä authored
commit 7d47559e upstream. The flip stall detector kicks in when pending>=INTEL_FLIP_COMPLETE. That means if we first call intel_prepare_page_flip() but don't call intel_finish_page_flip(), the next stall check will erroneosly think the page flip was somehow stuck. With enough debug spew emitted from the interrupt handler my 830 hangs when this happens. My theory is that the previous vblank interrupt gets sufficiently delayed that the handler will see the pending bit set in IIR, but ISR still has the bit set as well (ie. the flip was processed by CS but didn't complete yet). In this case the handler will proceed to call intel_check_page_flip() immediately after intel_prepare_page_flip(). It then tries to print a backtrace for the stuck flip WARN, which apparetly results in way too much debug spew delaying interrupt processing further. That then seems to cause an endless loop in the interrupt handler, and the machine is dead until the watchdog kicks in and reboots. At least limiting the number of iterations of the loop in the interrupt handler also prevented the hang. So it seems better to not call intel_prepare_page_flip() without immediately calling intel_finish_page_flip(). The IIR/ISR trickery avoids races here so this is a perfectly safe thing to do. v2: Fix typo in commit message (checkpatch) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88381 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85888Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Hisashi Nakamura authored
commit 01576056 upstream. SH-MSIOF driver is enabled autosuspend API of spi framework. But autosuspend framework doesn't work during initializing. So runtime PM lock is added in SH-MSIOF driver initializing. Fixes: e2a0ba54 (spi: sh-msiof: Convert to spi core auto_runtime_pm framework) Signed-off-by:
Hisashi Nakamura <hisashi.nakamura.ak@renesas.com> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
-
Luis Henriques authored
Signed-off-by: -
Sasha Levin authored
commit a3a87844 upstream. When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
David Howells <dhowells@redhat.com> Cc: Moritz Muehlenhoff <jmm@inutil.org> Signed-off-by:
-
Al Viro authored
commit ca5358ef upstream. ... by not hitting rename_retry for reasons other than rename having happened. In other words, do _not_ restart when finding that between unlocking the child and locking the parent the former got into __dentry_kill(). Skip the killed siblings instead... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Cc: Moritz Muehlenhoff <jmm@inutil.org> Signed-off-by:
-
Al Viro authored
commit 946e51f2 upstream. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Moritz Muehlenhoff <jmm@inutil.org> Signed-off-by:
-
Sven Eckelmann authored
commit 5b6698b0 upstream. The fragmentation code was replaced in 610bfc6b ("batman-adv: Receive fragmented packets and merge"). The new code provided a mostly unused parameter skb for the merging function. It is used inside the function to calculate the additionally needed skb tailroom. But instead of increasing its own tailroom, it is only increasing the tailroom of the first queued skb. This is not correct in some situations because the first queued entry can be a different one than the parameter. An observed problem was: 1. packet with size 104, total_size 1464, fragno 1 was received - packet is queued 2. packet with size 1400, total_size 1464, fragno 0 was received - packet is queued at the end of the list 3. enough data was received and can be given to the merge function (1464 == (1400 - 20) + (104 - 20)) - merge functions gets 1400 byte large packet as skb argument 4. merge function gets first entry in queue (104 byte) - stored as skb_out 5. merge function calculates the required extra tail as total_size - skb->len - pskb_expand_head tail of skb_out with 64 bytes 6. merge function tries to squeeze the extra 1380 bytes from the second queued skb (1400 byte aka skb parameter) in the 64 extra tail bytes of skb_out Instead calculate the extra required tail bytes for skb_out also using skb_out instead of using the parameter skb. The skb parameter is only used to get the total_size from the last received packet. This is also the total_size used to decide that all fragments were received. Reported-by:
Philipp Psurek <philipp.psurek@gmail.com> Signed-off-by:
Sven Eckelmann <sven@narfation.org> Acked-by:
Martin Hundebøll <martin@hundeboll.net> Signed-off-by:
-
Michael Mullin authored
commit b90b3c4a upstream. Add support for the acer c720p touchscreen. Tested manually by using the touchscreen on the acer c720p-2664 Based on the following patch by Dave Parker <dparker@chromium.org>: https://chromium-review.googlesource.com/#/c/167136/Signed-off-by:
Michael Mullin <masmullin@gmail.com> Reviewed-by:
Benson Leung <bleung@chromium.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Cc: Scot Doyle <lkml14@scotdoyle.com> Signed-off-by:
-
Gene Chen authored
commit 963cb6fa upstream. Add support for Leon touch devices, which is the same as falco/peppy/wolf on the same buses using the LynxPoint-LP I2C via the i2c-designware-pci driver. Based on these patches from the chromeos-3.8 kernel: https://chromium-review.googlesource.com/168351 https://chromium-review.googlesource.com/173445Signed-off-by:
Gene Chen <gene.chen@intel.com> Signed-off-by:
Scot Doyle <lkml14@scotdoyle.com> Reviewed-by:
-
Mohammed Habibulla authored
commit 0e1e5e59 upstream. Add support for Dell Chromebook 11's touch device, which is the same as falco/peppy on the same bus using the LynxPoint-LP I2C via the i2c-designware-pci driver. Based on these patches from the chromeos-3.8 kernel: https://chromium-review.googlesource.com/#/c/65320/ https://chromium-review.googlesource.com/#/c/174664/Signed-off-by:
Mohammed Habibulla <moch@chromium.org> Signed-off-by:
-
Benson Leung authored
commit 5ea9567f upstream. Add support for the trackpad on HP Chromebook 14. Signed-off-by:
-
Mika Westerberg authored
commit da3b0ab7 upstream. Acer C720 has touchpad and light sensor connected to a separate I2C buses. Since the designware I2C host controller driver has two instances on this particular machine we need a way to match the correct instance. Add support for this and then register both C720 touchpad and light sensor. This code is based on following patch from Benson Leung: https://patchwork.kernel.org/patch/3074411/Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Jan Kara authored
commit e237ec37 upstream. Check that length specified in a component of a symlink fits in the input buffer we are reading. Also properly ignore component length for component types that do not use it. Otherwise we read memory after end of buffer for corrupted udf image. Reported-by:
Carl Henrik Lunde <chlunde@ping.uio.no> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Jan Kara authored
commit a1d47b26 upstream. UDF specification allows arbitrarily large symlinks. However we support only symlinks at most one block large. Check the length of the symlink so that we don't access memory beyond end of the symlink block. Reported-by:
Carl Henrik Lunde <chlunde@gmail.com> Signed-off-by:
-
Jan Kara authored
commit e159332b upstream. Verify that inode size is sane when loading inode with data stored in ICB. Otherwise we may get confused later when working with the inode and inode size is too big. Reported-by:
-
Jan Kara authored
commit 0e5cc9a4 upstream. Symlink reading code does not check whether the resulting path fits into the page provided by the generic code. This isn't as easy as just checking the symlink size because of various encoding conversions we perform on path. So we have to check whether there is still enough space in the buffer on the fly. Reported-by:
-
Rabin Vincent authored
commit 7e77bdeb upstream. If a request is backlogged, it's complete() handler will get called twice: once with -EINPROGRESS, and once with the final error code. af_alg's complete handler, unlike other users, does not handle the -EINPROGRESS but instead always completes the completion that recvmsg() is waiting on. This can lead to a return to user space while the request is still pending in the driver. If userspace closes the sockets before the requests are handled by the driver, this will lead to use-after-frees (and potential crashes) in the kernel due to the tfm having been freed. The crashes can be easily reproduced (for example) by reducing the max queue length in cryptod.c and running the following (from http://www.chronox.de/libkcapi.html) on AES-NI capable hardware: $ while true; do kcapi -x 1 -e -c '__ecb-aes-aesni' \ -k 00000000000000000000000000000000 \ -p 00000000000000000000000000000000 >/dev/null & done Signed-off-by:
Rabin Vincent <rabin.vincent@axis.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jan Kara authored
commit 4e202462 upstream. We didn't check length of rock ridge ER records before printing them. Thus corrupted isofs image can cause us to access and print some memory behind the buffer with obvious consequences. Reported-and-tested-by:
-
Johannes Berg authored
commit d6ca18de upstream. With a significant number of deployed APs, enabling uAPSD leads to the AP never using aggregation sessions (likely due to the complexities involved in handling uAPSD in those.) This obviously results in a large drop in throughput with such APs. On the other hand, uAPSD can result in some power consumption benefits, but for now just disable it to get performance with affected APs back up. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
