[ Upstream commit 355b98553789b646ed97ad801a619ff898471b92 ]
net_hash_mix() currently uses kernel address of a struct net,
and is used in many places that could be used to reveal this
address to a patient attacker, thus defeating KASLR, for
the typical case (initial net namespace, &init_net is
not dynamically allocated)
I believe the original implementation tried to avoid spending
too many cycles in this function, but security comes first.
Also provide entropy regardless of CONFIG_NET_NS.
Fixes: 0b4419162a ("netns: introduce the net_hash_mix "salt" for hashes")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Amit Klein <aksecurity@gmail.com>
Reported-by: Benny Pinkas <benny@pinkas.net>
Cc: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46 upstream.
We used to delay switching to the new credentials until after we had
mapped the executable (and possible elf interpreter). That was kind of
odd to begin with, since the new executable will actually then _run_
with the new creds, but whatever.
The bigger problem was that we also want to make sure that we turn off
prof events and tracing before we start mapping the new executable
state. So while this is a cleanup, it's also a fix for a possible
information leak.
Reported-by: Robert Święcki <robert@swiecki.net>
Tested-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Acked-by: Eric W. Biederman <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Federico Manuel Bento <up201407890@fc.up.pt>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit d9c0b2afe820fa3b3f8258a659daee2cc71ca3ef ]
BE dai links only have internal PCM's and their substream ops may
not be set. Suspending these PCM's will result in their
ops->trigger() being invoked and cause a kernel oops.
So skip suspending PCM's if their ops are NULL.
[ NOTE: this change is required now for following the recent PCM core
change to get rid of snd_pcm_suspend() call. Since DPCM BE takes
the runtime carried from FE while keeping NULL ops, it can hit this
bug. See details at:
https://github.com/thesofproject/linux/pull/582
-- tiwai ]
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 74ffe79ae538283bbf7c155e62339f1e5c87b55a ]
Mostly unwind is done with irqs enabled however SLUB may call it with
irqs disabled while creating a new SLUB cache.
I had system freeze while loading a module which called
kmem_cache_create() on init. That means SLUB's __slab_alloc() disabled
interrupts and then
->new_slab_objects()
->new_slab()
->setup_object()
->setup_object_debug()
->init_tracking()
->set_track()
->save_stack_trace()
->save_stack_trace_tsk()
->walk_stackframe()
->unwind_frame()
->unwind_find_idx()
=>spin_lock_irqsave(&unwind_lock);
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1749ef00f7312679f76d5e9104c5d1e22a829038 ]
We had a test-report where, under memory pressure, adding LUNs to the
systems would fail (the tests add LUNs strictly in sequence):
[ 5525.853432] scsi 0:0:1:1088045124: Direct-Access IBM 2107900 .148 PQ: 0 ANSI: 5
[ 5525.853826] scsi 0:0:1:1088045124: alua: supports implicit TPGS
[ 5525.853830] scsi 0:0:1:1088045124: alua: device naa.6005076303ffd32700000000000044da port group 0 rel port 43
[ 5525.853931] sd 0:0:1:1088045124: Attached scsi generic sg10 type 0
[ 5525.854075] sd 0:0:1:1088045124: [sdk] Disabling DIF Type 1 protection
[ 5525.855495] sd 0:0:1:1088045124: [sdk] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB)
[ 5525.855606] sd 0:0:1:1088045124: [sdk] Write Protect is off
[ 5525.855609] sd 0:0:1:1088045124: [sdk] Mode Sense: ed 00 00 08
[ 5525.855795] sd 0:0:1:1088045124: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 5525.857838] sdk: sdk1
[ 5525.859468] sd 0:0:1:1088045124: [sdk] Attached SCSI disk
[ 5525.865073] sd 0:0:1:1088045124: alua: transition timeout set to 60 seconds
[ 5525.865078] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.015070] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.015213] sd 0:0:1:1088045124: alua: port group 00 state A preferred supports tolusnA
[ 5526.587439] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
[ 5526.588562] scsi_alloc_sdev: Allocation failure during SCSI scanning, some SCSI devices might not be configured
Looking at the code of scsi_alloc_sdev(), and all the calling contexts,
there seems to be no reason to use GFP_ATMOIC here. All the different
call-contexts use a mutex at some point, and nothing in between that
requires no sleeping, as far as I could see. Additionally, the code that
later allocates the block queue for the device (scsi_mq_alloc_queue())
already uses GFP_KERNEL.
There are similar allocations in two other functions:
scsi_probe_and_add_lun(), and scsi_add_lun(),; that can also be done with
GFP_KERNEL.
Here is the contexts for the three functions so far:
scsi_alloc_sdev()
scsi_probe_and_add_lun()
scsi_sequential_lun_scan()
__scsi_scan_target()
scsi_scan_target()
mutex_lock()
scsi_scan_channel()
scsi_scan_host_selected()
mutex_lock()
scsi_report_lun_scan()
__scsi_scan_target()
...
__scsi_add_device()
mutex_lock()
__scsi_scan_target()
...
scsi_report_lun_scan()
...
scsi_get_host_dev()
mutex_lock()
scsi_probe_and_add_lun()
...
scsi_add_lun()
scsi_probe_and_add_lun()
...
So replace all these, and give them a bit of a better chance to succeed,
with more chances of reclaim.
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
Reviewed-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7c5b019e3a638a5a290b0ec020f6ca83d2ec2aaa ]
Fix buffer overflow observed when running perf test.
The overflow is when trying to evaluate "1ULL << (64 - 1)" which is
resulting in -9223372036854775808 which overflows the 20 character
buffer.
If is possible this bug has been reported before but I still don't see
any fix checked in:
See: https://www.spinics.net/lists/linux-perf-users/msg07714.html
Reported-by: Michael Sartain <mikesart@fastmail.com>
Reported-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Tony Jones <tonyj@suse.de>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Fixes: f7d82350e5 ("tools/events: Add files to create libtraceevent.a")
Link: http://lkml.kernel.org/r/20190228015532.8941-1-tonyj@suse.de
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit afd07389d3f4933c7f7817a92fb5e053d59a3182 ]
One of the vmalloc stress test case triggers the kernel BUG():
<snip>
[60.562151] ------------[ cut here ]------------
[60.562154] kernel BUG at mm/vmalloc.c:512!
[60.562206] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[60.562247] CPU: 0 PID: 430 Comm: vmalloc_test/0 Not tainted 4.20.0+ #161
[60.562293] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[60.562351] RIP: 0010:alloc_vmap_area+0x36f/0x390
<snip>
it can happen due to big align request resulting in overflowing of
calculated address, i.e. it becomes 0 after ALIGN()'s fixup.
Fix it by checking if calculated address is within vstart/vend range.
Link: http://lkml.kernel.org/r/20190124115648.9433-2-urezki@gmail.com
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Joel Fernandes <joelaf@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 32a5ad9c22852e6bd9e74bdec5934ef9d1480bc5 ]
Currently, when writing
echo 18446744073709551616 > /proc/sys/fs/file-max
/proc/sys/fs/file-max will overflow and be set to 0. That quickly
crashes the system.
This commit sets the max and min value for file-max. The max value is
set to long int. Any higher value cannot currently be used as the
percpu counters are long ints and not unsigned integers.
Note that the file-max value is ultimately parsed via
__do_proc_doulongvec_minmax(). This function does not report error when
min or max are exceeded. Which means if a value largen that long int is
written userspace will not receive an error instead the old value will be
kept. There is an argument to be made that this should be changed and
__do_proc_doulongvec_minmax() should return an error when a dedicated min
or max value are exceeded. However this has the potential to break
userspace so let's defer this to an RFC patch.
Link: http://lkml.kernel.org/r/20190107222700.15954-3-christian@brauner.io
Signed-off-by: Christian Brauner <christian@brauner.io>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Waiman Long <longman@redhat.com>
[christian@brauner.io: v4]
Link: http://lkml.kernel.org/r/20190210203943.8227-3-christian@brauner.io
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 31b265b3baaf55f209229888b7ffea523ddab366 ]
As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
BUG for "sleeping function called from invalid context".
kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
atomic context. A very simple solution for this is to add allocation
flags to ring_buffer_read_prepare() so kdb can call it without
triggering the allocation error. This patch does that.
Note that in the original email thread about this, it was suggested
that perhaps the solution for kdb was to either preallocate the buffer
ahead of time or create our own iterator. I'm hoping that this
alternative of adding allocation flags to ring_buffer_read_prepare()
can be considered since it means I don't need to duplicate more of the
core trace code into "trace_kdb.c" (for either creating my own
iterator or re-preparing a ring allocator whose memory was already
allocated).
NOTE: another option for kdb is to actually figure out how to make it
reuse the existing ftrace_dump() function and totally eliminate the
duplication. This sounds very appealing and actually works (the "sr
z" command can be seen to properly dump the ftrace buffer). The
downside here is that ftrace_dump() fully consumes the trace buffer.
Unless that is changed I'd rather not use it because it means "ftdump
| grep xyz" won't be very useful to search the ftrace buffer since it
will throw away the whole trace on the first grep. A future patch to
dump only the last few lines of the buffer will also be hard to
implement.
[1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com
Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.org
Reported-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
This kind of fixes "qcacld-2.0: Add scenario based BUG report"
1. #include <linux/wcnss_wlan.h> is missing in wlan_hdd_main.c, so
HAVE_WCNSS_RESET_INTR is never defined, so wcnss_reset_intr() is
never called from wlan_hdd_restart_driver(). This is still the
case in upstream branches.
2. Even *if* we add this #include, wcnss_reset_intr() will be unavailable
because the Samsung apq8084 kernel is built without CONFIG_WCNSS_CORE.
3. And even *if* we try to enable CONFIG_WCNSS_CORE and *if* WCNSS
actually builds, we have no idea if wcnss_reset_intr() is actually doing
the right thing for our ROME chip since there are only branches for
PRONTO and RIVA. ROME is very certainly not PRONTO, but is it RIVA?
4. In comparison, on bullhead the situation is the same as above, plus
wcnss_reset_intr() is a no-op in the RIVA branch. Same on Samsung
msm8976, except wcnss_reset_intr() doesn't even exist.
5. Ultimately this makes vos_wlanRestart() a no-op which just logs stuff.
It's a complete mystery how this call was supposed to replace the old
VOS_BUG(0) call.
6. Conclusion: The code change in "qcacld-2.0: Add scenario based BUG report"
does never reset the WLAN driver, nor does it restart the device in case
of error. If that was really intended, why call vos_wlanRestart() at all?
7. For now we change wlan_hdd_restart_driver() to call VOS_BUG(0). That
will restart the device every time qcacld-2.0 deems an error as fatal,
just like before. Except, we now may have better logging. Either the
crash never occurs again, or we may have a chance to debug and fix the
original problem. Either way, we probably can revert this patch at one
point.
Change-Id: I339cb339d3919a47ce781918544391622bda4c94
Signed-off-by: Corinna Vinschen <xda@vinschen.de>
prima to qcacld-2.0 propagation
Currently only session id and reason code are posted to SME
during disassoc notification. SAP callback in HDD will deregister the
station based on the station ID which is determined using the peer
mac address and since peer mac address is not passed, it fails to
deregister the station.
To address this, pass the peer mac address while posting disassoc
notification from PE to SME.
CRs-Fixed: 957855
Change-Id: I2976bb5e441f4658ad46ce0d64e0420eae240ac8
Send the correct uevent after setting a CPU core online or offline.
This allows ueventd to set correct SELinux labels for newly created
sysfs CPU device nodes.
Bug: 28887345
Change-Id: If31b8529b31de9544914e27514aca571039abb60
Signed-off-by: Siqi Lin <siqilin@google.com>
Signed-off-by: Thierry Strudel <tstrudel@google.com>
In hdd_wlan_re_init(), SSR timer is deleted and isLogpInProgress is set to FALSE
but between these two there are NL socket related calls which can sleep
under low memory conditions (or etc) because of which timer is deleted but
isLogpInProgress is not reset to FALSE. This can potentially fail the
south-bound requests for a brief amount of time.
Hence it is always better to delete the SSR timer only after
isLogpInProgress is reset to FALSE.
Change-Id: I699438ff3e0c2f7b81e0bbf81be6f514841e194b
CRs-Fixed: 1017011
Fix incorrect logic to disable hi_rssi feature.
Both hi_rssi_scan_rssi_delta and neighborLookupThreshold are
positive values. Ideally it should be checked if the current
AP is better than the HI_RSSI threshold and then disable
the feature. The HI_RSSI threshold is the difference
between the lookup threshold and the hi_rssi delta.
CRs-Fixed: 1014859
Change-Id: I6980927b25c34b9b4d8ac13c22e93abc4ec500ec
prima to qcacld-2.0 propagation
If SME has active cmd, continuous BMiss in BMPS state will
exhaust sme command pool.
To avoid this, Ignore BMiss indication in case previous one is
not processed.
CRs-Fixed: 979109
Change-Id: I87f6d5437f181abb92772ad142b2101547d76657
Add changes to dump stack only once. Also, change thread stuck
timer to 10 seconds from 5 seconds (THREAD_STUCK_TIMER_VAL) and
probe thread only when thread stuck counter is zero to avoid
out of wrapper messages. Remove unnecessary error logs also.
Change-Id: I6c2ab331256b190fd0ce67f8fb95ed4d7cb5e61a
CRs-Fixed: 1032098
There is a potential deadlock scenario with a spin lock between
a tasklet and a thread context. Fix it by using spin_lock_bh
because that will disable bottom halves on that CPU and thus
prevent a dead lock that could otherwise occur if the process
context code took the lock and then a software IRQ was run which
attempt to acquire the same lock.
Change-Id: I5f83cb7cecd7227e0ea9c9db001bb0420bf09c94
CRs-Fixed: 1014766
prima to qcacld-2.0 propagation
Change to initiate BUG report in case of fatal event
Add INI support to Enable/Disable it.
The fatal event handled are as below:
- Roaming failed after successfull preauth.
- MC thread is Stucked for 15 sec.
- Sme command timeout.
- PE defer queue is full.
- VOS run out of message wrapper.
- Management tx timeout.
- HDD level wait for event timeout.
CRs-Fixed: 912560
Change-Id: I64dff8b7d0836340ce3bec5f5985d1919b600c23
prima to qcacld-2.0 propagation
When MC thread is stuck, currently there is no way to
get the call stack. So, add this support to dump the
call stack of MC thread that got stuck
Change-Id: I2e4f445c8e4d65905bc7f00bca215d000f61b1db
CRs-Fixed: 979886
Add changes to expose dump stack functionality which can be used
by driver to dump stack information when it requires.
CRs-Fixed: 979886
Change-Id: Ib929ad0a510b996ac54d17afd2957ea487c62851
Signed-off-by: Abhishek Singh <absingh@codeaurora.org>
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
commit bf959931ddb88c4e4366e96dd22e68fa0db9527c upstream.
The following program (simplified version of generated by syzkaller)
#include <pthread.h>
#include <unistd.h>
#include <sys/ptrace.h>
#include <stdio.h>
#include <signal.h>
void *thread_func(void *arg)
{
ptrace(PTRACE_TRACEME, 0,0,0);
return 0;
}
int main(void)
{
pthread_t thread;
if (fork())
return 0;
while (getppid() != 1)
;
pthread_create(&thread, NULL, thread_func, NULL);
pthread_join(thread, NULL);
return 0;
}
creates an unreapable zombie if /sbin/init doesn't use __WALL.
This is not a kernel bug, at least in a sense that everything works as
expected: debugger should reap a traced sub-thread before it can reap the
leader, but without __WALL/__WCLONE do_wait() ignores sub-threads.
Unfortunately, it seems that /sbin/init in most (all?) distributions
doesn't use it and we have to change the kernel to avoid the problem.
Note also that most init's use sys_waitid() which doesn't allow __WALL, so
the necessary user-space fix is not that trivial.
This patch just adds the "ptrace" check into eligible_child(). To some
degree this matches the "tsk->ptrace" in exit_notify(), ->exit_signal is
mostly ignored when the tracee reports to debugger. Or WSTOPPED, the
tracer doesn't need to set this flag to wait for the stopped tracee.
This obviously means the user-visible change: __WCLONE and __WALL no
longer have any meaning for debugger. And I can only hope that this won't
break something, but at least strace/gdb won't suffer.
We could make a more conservative change. Say, we can take __WCLONE into
account, or !thread_group_leader(). But it would be nice to not
complicate these historical/confusing checks.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Cc: Pedro Alves <palves@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: <syzkaller@googlegroups.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
This reverts commit bf26c01849 ("Prepare to fix racy accesses on task
breakpoints").
The patch was fine but we can no longer race with SIGKILL after commit
9899d11f65 ("ptrace: ensure arch_ptrace/ptrace_request can never race
with SIGKILL"), the __TASK_TRACED tracee can't be woken up and
->ptrace_bps[] can't go away.
Now that ptrace_get_breakpoints/ptrace_put_breakpoints have no callers,
we can kill them and remove task->ptrace_bp_refcnt.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
Acked-by: Michael Neuling <mikey@neuling.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit bf0b8f4b55 ("hw_breakpoints: Fix racy access to
ptrace breakpoints").
The patch was fine but we can no longer race with SIGKILL after commit
9899d11f65 ("ptrace: ensure arch_ptrace/ptrace_request can never race
with SIGKILL"), the __TASK_TRACED tracee can't be woken up and
->ptrace_bps[] can't go away.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Michael Neuling <mikey@neuling.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Prasad <prasad@linux.vnet.ibm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In case of PMF connection pmfcomeback timer is initialized
for the old session and not for new FT session and thus
gives warning while stopping the timer when FT session is
deleted.
Fix this issue by initializing PMF timer for FT session.
Change-Id: I7ef1db436c39a824aeb199e51d28a011d527f7bd
CRs-Fixed: 1050380
Bug: 31358630
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
Before configuring to firmware, validate multicast
filter count does not exceed the max allowed value.
Change-Id: I1bcb1c820a5154109565a8c283bf5131a3b90855
CRs-Fixed: 1059974
Bug: 31037507
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
Currently driver flushes driver and firmware logs irrespective of ring id.
Host should flush the logs only for driver ring id.
Add changes to fix the same issue.
Change-Id: I50cfde1baaf18c1a3992f956182b49044ccc4b1d
CRs-Fixed: 1053219
Do not probe MC thread when its suspended during cfg80211
suspend and increase thread stuck detection threshold to
avoid reporting false alarm.
Change-Id: Ia93289eaf89538818a8e1264dfcf3306d682bd9b
CRs-Fixed: 1047257
Bug: 30407099
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
In current driver, WE_UNIT_TEST_CMD has below problem.
- apps_arg[1] can have zero value and can lead to
buffer overead
Change the code to handle the number of args if user has
given zero.
CRs-Fixed: 1029540
Change-Id: Idc8e1d77d9623daeb98d0c4b7ad8a8d6cfa9c2d2
Bug: 29941999
Bug: 29944562
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
Some WMI Commands can be send in Runtime PM context and MC thread context.
Packets coming via MC Thread Context can be tagged as Runtime PM packets
when runtime pm in progress.
Packets should be tagged in the same caller context to avoid any race
condition. Being stability issue, addressing this issue by not tagging
any non-wow commands as runtime pm after wow suspend. This will ensure
all the non-wow packets coming after wow_suspend flag is set as non
runtime pm packets and will trigger a runtime resume.
CRs-Fixed: 1037430
Change-Id: I03528a395e1d88ca2c5aaeca27fa505c3426f778
Bug: 31438853
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
prima to qcacld-2.0 propagation
From Kernel-3.18 onwards pending scan request is handled
as part of NETDEV_DOWN event, by invoking the cfg80211_scan_done
callback which frees the scan request structure. To support this,
driver will not invoke scan_done_callback if interface is down.
In case, if interface down and up are called back to back there
is a chance that kernel frees scan request as part of NETDEV_DOWN
and after which before driver triggers scan_done_callback if
interface is made up, driver scan_done_callback is through its
execution and accesses the freed scan request results in kernel
panic.
To mitigate this, don't return from hdd_stop until scan request
is aborted. Though this fix is to avoid kernel panic due to 3.18
kernel specific changes, it is acceptable across all the kernel
versions.
Change-Id: Iba8bd7a32fac33e8a0c3eea293aad682a1105397
CRs-Fixed: 977264
Bug: 31438853
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
Kernel throws warnings on the invocation of schedule_work() before the
work is initialized.
To mitigate this issue, initialize the work before it is scheduled.
Change-Id: Ia73f3fb186ba0818162d8263a72187a71c2f4a07
CRs-Fixed: 1010964
Bug: 28405264
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
1.Fix argument type mismatch with format specifier in sscanf used by
hdd_hex_string_to_u16_array.
2.Fix bitwise operation on different size by typecasting.
Change-Id: Iccec386d8d88d69ccc4eacd2031d5664ed948acc
CRs-Fixed: 1018489
Bug: 31438853
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
It doesn't set tag HTC_TX_PACKET_TAG_AUTO_PM when attempt to suspend
and set vdev suspend dtim, which cause host wake up frequently.
Change-Id: Iba32c715694e64ce7d941f198990b25b9c87240d
CRs-Fixed: 1003313
Bug: 31438853
Signed-off-by: Srinivas Girigowda <sgirigow@codeaurora.org>
In order to bring lowmemorykiller in sync with Google sources,
the following Samsung specific changes have been removed:
SEC_TIMEOUT_LOW_MEMORY_KILLER
SEC_DEBUG_LMK_MEMINFO
SEC_DEBUG_LMK_COUNT_INFO
These options are not used upstream and conflict.
lowmemorykiller was not taking into account unevictable pages when
deciding what level to kill. If significant amounts of memory were
pinned, this caused lowmemorykiller to effectively stop at a much higher
level than it should.
bug 31255977
Change-Id: I763ecbfef8c56d65bb8f6147ae810692bd81b6e2
With ZRAM enabled it is observed that lowmemory killer
doesn't trigger properly. swap cached pages are
accounted in NR_FILE, and lowmemorykiller considers
this as reclaimable and adds to other_file. But these
pages can't be reclaimed unless lowmemorykiller triggers.
So subtract swap pages from other_file.
Signed-off-by: Vinayak Menon <vinayakm.list@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 058dbde928597e7a8bd04e28e77e5cfc4270591d)
Change-Id: I217e831bbe1db830e6d61c7943e442a32a7548a1
Eric Dumazet
Linus Torvalds
Manfred Schlaegl
Ranjani Sridharan
Sebastian Andrzej Siewior
Benjamin Block
Tony Jones
Uladzislau Rezki (Sony)
Christian Brauner
Douglas Anderson
Corinna Vinschen
Ratnam Rachuri
Nick Desaulniers
Siqi Lin
Srinivas Girigowda
Varun Reddy Yeturu
Gupta, Kapil
Padma, Santhosh Kumar
Mahesh Kumar Kalikot Veetil
Srinivas Girigowda
Oleg Nesterov
Sreelakshmi Konamki
syphyr
Tim Murray
Vinayak Menon
Thierry Strudel