- 10 Feb, 2015 31 commits
-
-
subashab@codeaurora.org authored
commit fc752f1f upstream. An exception is seen in ICMP ping receive path where the skb destructor sock_rfree() tries to access a freed socket. This happens because ping_rcv() releases socket reference with sock_put() and this internally frees up the socket. Later icmp_rcv() will try to free the skb and as part of this, skb destructor is called and which leads to a kernel panic as the socket is freed already in ping_rcv(). -->|exception -007|sk_mem_uncharge -007|sock_rfree -008|skb_release_head_state -009|skb_release_all -009|__kfree_skb -010|kfree_skb -011|icmp_rcv -012|ip_local_deliver_finish Fix this incorrect free by cloning this skb and processing this cloned skb instead. This patch was suggested by Eric Dumazet Signed-off-by:
Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Cc: Eric Dumazet <edumazet@google.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Herbert Xu authored
commit 86f3cddb upstream. While working on rhashtable walking I noticed that the UDP diag dumping code is buggy. In particular, the socket skipping within a chain never happens, even though we record the number of sockets that should be skipped. As this code was supposedly copied from TCP, this patch does what TCP does and resets num before we walk a chain. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Acked-by:
Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
-
Eric Dumazet authored
commit 6088beef upstream. NAPI poll logic now enforces that a poller returns exactly the budget when it wants to be called again. If a driver limits TX completion, it has to return budget as well when the limit is hit, not the number of received packets. Reported-and-tested-by:
Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by:
Manish Chopra <manish.chopra@qlogic.com> Signed-off-by:
-
Hagen Paul Pfeifer authored
commit 9d289715 upstream. Reduce the attack vector and stop generating IPv6 Fragment Header for paths with an MTU smaller than the minimum required IPv6 MTU size (1280 byte) - called atomic fragments. See IETF I-D "Deprecating the Generation of IPv6 Atomic Fragments" [1] for more information and how this "feature" can be misused. [1] https://tools.ietf.org/html/draft-ietf-6man-deprecate-atomfrag-generation-00Signed-off-by:
Fernando Gont <fgont@si6networks.com> Signed-off-by:
Hagen Paul Pfeifer <hagen@jauu.net> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Eric Dumazet authored
commit ac64da0b upstream. softnet_data.input_pkt_queue is protected by a spinlock that we must hold when transferring packets from victim queue to an active one. This is because other cpus could still be trying to enqueue packets into victim queue. A second problem is that when we transfert the NAPI poll_list from victim to current cpu, we absolutely need to special case the percpu backlog, because we do not want to add complex locking to protect process_queue : Only owner cpu is allowed to manipulate it, unless cpu is offline. Based on initial patch from Prasad Sodagudi & Subash Abhinov Kasiviswanathan. This version is better because we do not slow down packet processing, only make migration safer. Reported-by:
Prasad Sodagudi <psodagud@codeaurora.org> Reported-by:
-
Willem de Bruijn authored
commit f812116b upstream. The sockaddr is returned in IP(V6)_RECVERR as part of errhdr. That structure is defined and allocated on the stack as struct { struct sock_extended_err ee; struct sockaddr_in(6) offender; } errhdr; The second part is only initialized for certain SO_EE_ORIGIN values. Always initialize it completely. An MTU exceeded error on a SOCK_RAW/IPPROTO_RAW is one example that would return uninitialized bytes. Signed-off-by:
Willem de Bruijn <willemb@google.com> ---- Also verified that there is no padding between errhdr.ee and errhdr.offender that could leak additional kernel data. Acked-by:
-
Ryusuke Konishi authored
commit 7ef3ff2f upstream. Nilfs2 eventually hangs in a stress test with fsstress program. This issue was caused by the following deadlock over I_SYNC flag between nilfs_segctor_thread() and writeback_sb_inodes(): nilfs_segctor_thread() nilfs_segctor_thread_construct() nilfs_segctor_unlock() nilfs_dispose_list() iput() iput_final() evict() inode_wait_for_writeback() * wait for I_SYNC flag writeback_sb_inodes() * set I_SYNC flag on inode->i_state __writeback_single_inode() do_writepages() nilfs_writepages() nilfs_construct_dsync_segment() nilfs_segctor_sync() * wait for completion of segment constructor inode_sync_complete() * clear I_SYNC flag after __writeback_single_inode() completed writeback_sb_inodes() calls do_writepages() for dirty inodes after setting I_SYNC flag on inode->i_state. do_writepages() in turn calls nilfs_writepages(), which can run segment constructor and wait for its completion. On the other hand, segment constructor calls iput(), which can call evict() and wait for the I_SYNC flag on inode_wait_for_writeback(). Since segment constructor doesn't know when I_SYNC will be set, it cannot know whether iput() will block or not unless inode->i_nlink has a non-zero count. We can prevent evict() from being called in iput() by implementing sop->drop_inode(), but it's not preferable to leave inodes with i_nlink == 0 for long periods because it even defers file truncation and inode deallocation. So, this instead resolves the deadlock by calling iput() asynchronously with a workqueue for inodes with i_nlink == 0. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Shiraz Hashim authored
commit 23aaed66 upstream. walk_page_range() silently skips vma having VM_PFNMAP set, which leads to undesirable behaviour at client end (who called walk_page_range). Userspace applications get the wrong data, so the effect is like just confusing users (if the applications just display the data) or sometimes killing the processes (if the applications do something with misunderstanding virtual addresses due to the wrong data.) For example for pagemap_read, when no callbacks are called against VM_PFNMAP vma, pagemap_read may prepare pagemap data for next virtual address range at wrong index. Eventually userspace may get wrong pagemap data for a task. Corresponding to a VM_PFNMAP marked vma region, kernel may report mappings from subsequent vma regions. User space in turn may account more pages (than really are) to the task. In my case I was using procmem, procrack (Android utility) which uses pagemap interface to account RSS pages of a task. Due to this bug it was giving a wrong picture for vmas (with VM_PFNMAP set). Fixes: a9ff785e ("mm/pagewalk.c: walk_page_range should avoid VM_PFNMAP areas") Signed-off-by:
Shiraz Hashim <shashim@codeaurora.org> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Signed-off-by:
-
Sylwester Nawrocki authored
commit fddcd300 upstream. I2S1, I2S2 on Exynos4 SoC series have limited functionality compared to I2S0, "samsung,s3c6410-i2s" compatible should be used for them. Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Myron Stowe authored
commit 06cf35f9 upstream. Some AMD CS553x devices have read-only BARs because of a firmware or hardware defect. There's a workaround in quirk_cs5536_vsa(), but it no longer works after 36e81648 ("PCI: Restore detection of read-only BARs"). Prior to 36e81648, we filled in res->start; afterwards we leave it zeroed out. The quirk only updated the size, so the driver tried to use a region starting at zero, which didn't work. Expand quirk_cs5536_vsa() to read the base addresses from the BARs and hard-code the sizes. On Nix's system BAR 2's read-only value is 0x6200. Prior to 36e81648, we interpret that as a 512-byte BAR based on the lowest-order bit set. Per datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to avoid clearing any address bits if a platform uses only 64-byte alignment. [bhelgaas: changelog, reduce BAR 2 size to 64] Fixes: 36e81648 ("PCI: Restore detection of read-only BARs") Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4 Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdfReported-and-tested-by:
Nix <nix@esperi.org.uk> Signed-off-by:
Myron Stowe <myron.stowe@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Eric Nelson authored
commit 58cc9c9a upstream. To quote from section 1.3.1 of the data sheet: The SGTL5000 has an internal reset that is deasserted 8 SYS_MCLK cycles after all power rails have been brought up. After this time, communication can start ... 1.0us represents 8 SYS_MCLK cycles at the minimum 8.0 MHz SYS_MCLK. Signed-off-by:
Eric Nelson <eric.nelson@boundarydevices.com> Reviewed-by:
Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by:
-
Will Deacon authored
commit 8e648066 upstream. Commit e1a5848e ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") removed the use of the reserved TTBR0 value for LPAE systems, since the ASID is held in the TTBR and can be updated atomicly with the pgd of the next mm. Unfortunately, this patch forgot to update flush_context, which deliberately avoids marking the local active ASID as allocated, since we used to switch via ASID zero and didn't need to allocate the ASID of the previous mm. The side-effect of this is that we can allocate the same ASID to the next mm and, between flushing the local TLB and updating TTBR0, we can perform speculative TLB fills for userspace nG mappings using the page table of the previous mm. The consequence of this is that the next mm can erroneously hit some mappings of the previous mm. Note that this was made significantly harder to hit by a391263c ("ARM: 8203/1: mm: try to re-use old ASID assignments following a rollover") but is still theoretically possible. This patch fixes the problem by removing the code from flush_context that forces the allocated ASID to zero for the local CPU. Many thanks to the Broadcom guys for tracking this one down. Fixes: e1a5848e ("ARM: 7924/1: mm: don't bother with reserved ttbr0 when running with LPAE") Reported-by:
Raymond Ngun <rngun@broadcom.com> Tested-by:
Gregory Fong <gregory.0xf0@gmail.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Alex Deucher authored
commit a124d068 upstream. Should be the same as cayman. We don't use VM by default on NI parts so this isn't critical. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 544143f9 upstream. If acceleration is disabled, it does not make sense to init gpuvm since nothing will use it. Moreover, if radeon_vm_init() gets called it uses accel to try and clear the pde tables, etc. which results in a bug. v2: handle vm_fini as well v3: handle bo_open/close as well Bug: https://bugs.freedesktop.org/show_bug.cgi?id=88786Signed-off-by:
-
Christian König authored
commit 72edd83c upstream. This is a workaround for RS880 and older chips which seem to have an additional limit on the minimum PLL input frequency. v2: fix signed/unsigned warning bugs: https://bugzilla.kernel.org/show_bug.cgi?id=91861 https://bugzilla.kernel.org/show_bug.cgi?id=83461Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Charlotte Richardson authored
commit 51ac3d2f upstream. NEC OEMs the same platforms as Stratus does, which have multiple devices on some PCIe buses under downstream ports. Link: https://bugzilla.kernel.org/show_bug.cgi?id=51331 Fixes: 1278998f ("PCI: Work around Stratus ftServer broken PCIe hierarchy (fix DMI check)") Signed-off-by:
Charlotte Richardson <charlotte.richardson@stratus.com> Signed-off-by:
-
NeilBrown authored
commit b1b02fe9 upstream. If a non-page-aligned write is destined for a device which is missing/faulty, we can deadlock. As the target device is missing, a read-modify-write cycle is not possible. As the write is not for a full-page, a recontruct-write cycle is not possible. This should be handled by logic in fetch_block() which notices there is a non-R5_OVERWRITE write to a missing device, and so loads all blocks. However since commit 67f45548, that code requires STRIPE_PREREAD_ACTIVE before it will active, and those circumstances never set STRIPE_PREREAD_ACTIVE. So: in handle_stripe_dirtying, if neither rmw or rcw was possible, set STRIPE_DELAYED, which will cause STRIPE_PREREAD_ACTIVE be set after a suitable delay. Fixes: 67f45548Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Tested-by:
Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Johan Hovold authored
commit 49d2ca84 upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when setting the gpio-line polarity. Fixes: 07697461 ("gpiolib: add support for changing value polarity in sysfs") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> [ luis: backported to 3.16: - file rename: drivers/gpio/gpiolib-sysfs.c -> drivers/gpio/gpiolib.c ] Signed-off-by:
-
Johan Hovold authored
commit 0f303db0 upstream. Fix memory leak in the gpio sysfs interface due to failure to drop reference to device returned by class_find_device when creating a link. Fixes: a4177ee7 ("gpiolib: allow exported GPIO nodes to be named using sysfs links") Signed-off-by:
-
Hemmo Nieminen authored
commit c7754e75 upstream. As printk() invocation can cause e.g. a TLB miss, printk() cannot be called before the exception handlers have been properly initialized. This can happen e.g. when netconsole has been loaded as a kernel module and the TLB table has been cleared when a CPU was offline. Call cpu_report() in start_secondary() only after the exception handlers have been initialized to fix this. Without the patch the kernel will randomly either lockup or crash after a CPU is onlined and the console driver is a module. Signed-off-by:
Hemmo Nieminen <hemmo.nieminen@iki.fi> Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Cc: David Daney <david.daney@cavium.com> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/8953/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
karl beldan authored
commit 9ce35779 upstream. Fixed commit added from64to32 under _#ifndef do_csum_ but used it under _#ifndef csum_tcpudp_nofold_, breaking some builds (Fengguang's robot reported TILEGX's). Move from64to32 under the latter. Fixes: 150ae0e9 ("lib/checksum.c: fix carry in csum_tcpudp_nofold") Reported-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
Karl Beldan <karl.beldan@rivierawaves.com> Cc: Eric Dumazet <edumazet@google.com> Cc: David S. Miller <davem@davemloft.net> Signed-off-by:
-
karl beldan authored
commit 150ae0e9 upstream. The carry from the 64->32bits folding was dropped, e.g with: saddr=0xFFFFFFFF daddr=0xFF0000FF len=0xFFFF proto=0 sum=1, csum_tcpudp_nofold returned 0 instead of 1. Signed-off-by:
-
Takashi Iwai authored
commit 4161b450 upstream. When ak4114 work calls its callback and the callback invokes ak4114_reinit(), it stalls due to flush_delayed_work(). For avoiding this, control the reentrance by introducing a refcount. Also flush_delayed_work() is replaced with cancel_delayed_work_sync(). The exactly same bug is present in ak4113.c and fixed as well. Reported-by:
Pavel Hofman <pavel.hofman@ivitera.com> Acked-by:
Jaroslav Kysela <perex@perex.cz> Tested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Bhuvanchandra DV authored
commit 973fbce6 upstream. devm_* API was supposed to be used only in probe function call. Memory is allocated at 'probe' and free automatically at 'remove'. Usage of devm_* functions outside probe sometimes leads to memory leak. Avoid using devm_kzalloc in dspi_setup_transfer and use kzalloc instead. Also add the dspi_cleanup function to free the controller data upon cleanup. Acked-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Bhuvanchandra DV <bhuvanchandra.dv@toradex.com> Signed-off-by:
-
Bo Shen authored
commit a43bd7e1 upstream. According to the I2S specification information as following: - WS = 0, channel 1 (left) - WS = 1, channel 2 (right) So, the start event should be TF/RF falling edge. Reported-by:
Songjun Wu <songjun.wu@atmel.com> Signed-off-by:
Bo Shen <voice.shen@atmel.com> Signed-off-by:
-
Lai Jiangshan authored
commit 4bee9686 upstream. The following race exists in the smpboot percpu threads management: CPU0 CPU1 cpu_up(2) get_online_cpus(); smpboot_create_threads(2); smpboot_register_percpu_thread(); for_each_online_cpu(); __smpboot_create_thread(); __cpu_up(2); This results in a missing per cpu thread for the newly onlined cpu2 and in a NULL pointer dereference on a consecutive offline of that cpu. Proctect smpboot_register_percpu_thread() with get_online_cpus() to prevent that. [ tglx: Massaged changelog and removed the change in smpboot_unregister_percpu_thread() because that's an optimization and therefor not stable material. ] Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Cc: David Rientjes <rientjes@google.com> Link: http://lkml.kernel.org/r/1406777421-12830-1-git-send-email-laijs@cn.fujitsu.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Sachin Prabhu authored
commit ca7df8e0 upstream. Commit c11f1df5 requires writers to wait for any pending oplock break handler to complete before proceeding to write. This is done by waiting on bit CIFS_INODE_PENDING_OPLOCK_BREAK in cifsFileInfo->flags. This bit is cleared by the oplock break handler job queued on the workqueue once it has completed handling the oplock break allowing writers to proceed with writing to the file. While testing, it was noticed that the filehandle could be closed while there is a pending oplock break which results in the oplock break handler on the cifsiod workqueue being cancelled before it has had a chance to execute and clear the CIFS_INODE_PENDING_OPLOCK_BREAK bit. Any subsequent attempt to write to this file hangs waiting for the CIFS_INODE_PENDING_OPLOCK_BREAK bit to be cleared. We fix this by ensuring that we also clear the bit CIFS_INODE_PENDING_OPLOCK_BREAK when we remove the oplock break handler from the workqueue. The bug was found by Red Hat QA while testing using ltp's fsstress command. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Acked-by:
Shirish Pargaonkar <shirishpargaonkar@gmail.com> Signed-off-by:
Jeff Layton <jlayton@samba.org> Signed-off-by:
Steve French <steve.french@primarydata.com> Signed-off-by:
-
Felix Fietkau authored
commit a3e6c1ef upstream. If the irq_chip does not define .irq_disable, any call to disable_irq will defer disabling the IRQ until it fires while marked as disabled. This assumes that the handler function checks for this condition, which handle_percpu_irq does not. In this case, calling disable_irq leads to an IRQ storm, if the interrupt fires while disabled. This optimization is only useful when disabling the IRQ is slow, which is not true for the MIPS CPU IRQ. Disable this optimization by implementing .irq_disable and .irq_enable Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8949/Signed-off-by:
-
Mark Rutland authored
commit 44b82b77 upstream. [backport to 3.16.x: fold in missing MIDR_EL1 recording] Commit d7a49086 (arm64: cpuinfo: print info for all CPUs) attempted to clean up /proc/cpuinfo, but due to concerns regarding further changes was reverted in commit 5e39977e (Revert "arm64: cpuinfo: print info for all CPUs"). There are two major issues with the arm64 /proc/cpuinfo format currently: * The "Features" line describes (only) the 64-bit hwcaps, which is problematic for some 32-bit applications which attempt to parse it. As the same names are used for analogous ISA features (e.g. aes) despite these generally being architecturally unrelated, it is not possible to simply append the 64-bit and 32-bit hwcaps in a manner that might not be misleading to some applications. Various potential solutions have appeared in vendor kernels. Typically the format of the Features line varies depending on whether the task is 32-bit. * Information is only printed regarding a single CPU. This does not match the ARM format, and does not provide sufficient information in big.LITTLE systems where CPUs are heterogeneous. The CPU information printed is queried from the current CPU's registers, which is racy w.r.t. cross-cpu migration. This patch attempts to solve these issues. The following changes are made: * When a task with a LINUX32 personality attempts to read /proc/cpuinfo, the "Features" line contains the decoded 32-bit hwcaps, as with the arm port. Otherwise, the decoded 64-bit hwcaps are shown. This aligns with the behaviour of COMPAT_UTS_MACHINE and COMPAT_ELF_PLATFORM. In the absense of compat support, the Features line is empty. The set of hwcaps injected into a task's auxval are unaffected. * Properties are printed per-cpu, as with the ARM port. The per-cpu information is queried from pre-recorded cpu information (as used by the sanity checks). * As with the previous attempt at fixing up /proc/cpuinfo, the hardware field is removed. The only users so far are 32-bit applications tied to particular boards, so no portable applications should be affected, and this should prevent future tying to particular boards. The following differences remain: * No model_name is printed, as this cannot be queried from the hardware and cannot be provided in a stable fashion. Use of the CPU {implementor,variant,part,revision} fields is sufficient to identify a CPU and is portable across arm and arm64. * The following system-wide properties are not provided, as they are not possible to provide generally. Programs relying on these are already tied to particular (32-bit only) boards: - Hardware - Revision - Serial No software has yet been identified for which these remaining differences are problematic. Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Ian Campbell <ijc@hellion.org.uk> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> [Mark: backport to v3.16.x] Signed-off-by:
-
Richard Guy Briggs authored
commit 63f13448 upstream. Since both ppc and ppc64 have LE variants which are now reported by uname, add that flag (__AUDIT_ARCH_LE) to syscall_get_arch() and add AUDIT_ARCH_PPC64LE variant. Without this, perf trace and auditctl fail. Mainline kernel reports ppc64le (per a0588015) but there is no matching AUDIT_ARCH_PPC64LE. Since 32-bit PPC LE is not supported by audit, don't advertise it in AUDIT_ARCH_PPC* variants. See: https://www.redhat.com/archives/linux-audit/2014-August/msg00082.html https://www.redhat.com/archives/linux-audit/2014-December/msg00004.htmlSigned-off-by:
Richard Guy Briggs <rgb@redhat.com> Acked-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> [bwh: Backported to 3.16: arch is passed in by do_syscall_trace_enter() rather than queried by calling syscall_get_arch()] Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Tested-by:
-
Luis Henriques authored
Signed-off-by:
-
- 04 Feb, 2015 9 commits
-
-
Hannes Frederic Sowa authored
commit df4d9254 upstream. Not caching dst_entries which cause redirects could be exploited by hosts on the same subnet, causing a severe DoS attack. This effect aggravated since commit f8864972 ("ipv4: fix dst race in sk_dst_get()"). Lookups causing redirects will be allocated with DST_NOCACHE set which will force dst_release to free them via RCU. Unfortunately waiting for RCU grace period just takes too long, we can end up with >1M dst_entries waiting to be released and the system will run OOM. rcuos threads cannot catch up under high softirq load. Attaching the flag to emit a redirect later on to the specific skb allows us to cache those dst_entries thus reducing the pressure on allocation and deallocation. This issue was discovered by Marcelo Leitner. Cc: Julian Anastasov <ja@ssi.bg> Signed-off-by:
Marcelo Leitner <mleitner@redhat.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
-
Hans de Goede authored
commit 841e11cc upstream. Wifi on this laptop does not work unless asus-nb-wmi.wapf=4 is specified on the kerne commandline, add a quirk for this. BugLink: https://bugs.launchpad.net/bugs/1173681Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 4ec7a45b upstream. X550VB as many others Asus laptops need wapf4 quirk to make RFKILL switch be functional. Otherwise system boots with wireless card disabled and is only possible to enable it by suspend/resume. Bug report: http://bugzilla.redhat.com/show_bug.cgi?id=1089731#c23Reported-and-tested-by:
Vratislav Podzimek <vpodzime@redhat.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit 831a444e upstream. As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681 the U32U needs wapf=4 too. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
Hans de Goede authored
commit 378008df upstream. The actual x401u does not use the so named x401u quirk but the x55u quirk. All that the x401u quirk does it setting wapf to 4, so rename it to wapf4 to stop the confusion. Signed-off-by:
-
Hans de Goede authored
commit 6d6ded3b upstream. As reported here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1173681 the X550CC needs wapf=4 too. Signed-off-by:
-
Hans de Goede authored
commit 22ba58c8 upstream. As reported here: https://bugs.launchpad.net/bugs/1277959 the X550CL needs wapf=4 too. Signed-off-by:
-
AceLan Kao authored
commit c66263a3 upstream. BIOS won't light on the wifi-led after S3, so asus-wmi driver needs to control the wifi and wifi-led status. But, it'll lead to bt status error if asus-wmi driver controls bt as well. So, for X200CA, asus-wmi driver controls wifi status only and have to set wapf to 1. Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Signed-off-by:
-
poma authored
commit 7216e102 upstream. The 'asus-nb-wmi' WAPF parameter must be set to 4, so the internal Wireless LAN device is operational. Signed-off-by:
poma <pomidorabelisima@gmail.com> Signed-off-by:
-
