Task->on_rq has three states:
0 - Task is not on runqueue (rq)
1 (TASK_ON_RQ_QUEUED) - Task is on rq
2 (TASK_ON_RQ_MIGRATING) - Task is on rq but in the
process of being migrated to another rq
When a task is moving between rqs task->on_rq state should be
TASK_ON_RQ_MIGRATING in order for WALT to account rq's cumulative
runnable average correctly. Without such state marking for all the
classes, WALT's update_history() would try to fixup task's demand
which was never contributed to any of CPUs during migration.
Change-Id: Iced3428f3924fe8ab5d0075698273ead04f12d5b
Signed-off-by: Olav Haugan <ohaugan@codeaurora.org>
[joonwoop: Reinforced changelog to explain why this is needed by WALT.
Fixed conflicts in deadline.c]
Signed-off-by: Joonwoo Park <joonwoop@codeaurora.org>
Unserialized access to diag_dbgfs_dci_data_index can lead to
heap overflow. Add mutex protection while updating the
diag_dbgfs_dci_data_index.
Change-Id: Iee9d0447494e3576e6293afcd4d7611bc429aa8a
Signed-off-by: Sreelakshmi Gownipalli <sgownipa@codeaurora.org>
RX intent no timeout value when waiting for response. This can result
in calling function to wait indefinitely.
Set max waiting time to 500 ms.
CRs-Fixed: 2127311
Change-Id: I30475ca49f107e62bed41d3d26287562574d988c
Signed-off-by: Dhoat Harpal <hdhoat@codeaurora.org>
In function ufs_qcom_dbg_testbus_cfg_write(), the global
variable ufs_qcom_host (host) is not protected by lock.
In function ufs_qcom_testbug_config(), we are checking this
variable in switch case and there is possibility of race
condition while accessing host variable in both of these
functions. This change fixes the possible race scenario
using spin_lock on host_lock.
Change-Id: I4e3fa1c3b80b92a648965371e12e52352cf80ce5
Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Create new function ext4_issue_zeroout() to zeroout contiguous (both
logically and physically) part of inode data. We will need to issue
zeroout when extent structure is not readily available and this function
will allow us to do it without making up fake extent structures.
Change-Id: I5deb04b49d3ebdd1ac12f8bb950faf46d08f5d80
Signed-off-by: Jan Kara <jack@suse.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Git-commit: 53085fac02d12fcd29a9cb074ec480ff0f77ae5c
Git-repo: https://source.codeaurora.org/quic/la/kernel/msm-4.4
[srkupp@codeaurora.org: Resolved minor conflict]
Signed-off-by: Srinivasa Rao Kuppala <srkupp@codeaurora.org>
(from https://patchwork.kernel.org/patch/10005409/)
If there's some data written through inline data or dentry, we need to shouw
st_blocks. This fixes reporting zero blocks even though there is small written
data.
Bug: 67651285
Bug: 67600404
Change-Id: I9ad5cb137eb627b9fd22740d2ab98e0221433c95
Cc: stable@vger.kernel.org
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
qcedev_sha_req_cb() is only called by _sha_complete() during sha
operation, and will copy byte_count value from authdata array.
This array size is two, and only contains two byte_count value
that are used for sha operation. So make change to only copy the
first two elements from this array.
Change-Id: I535f2ec0e358870a9a2163b3c0bf154b2c8d003f
Signed-off-by: Zhen Kong <zkong@codeaurora.org>
Currently, there is a possibility of nested sleep
during handling of data ready notification to diag
clients. The patch fixes the issue by properly
handling data ready notifications.
Change-Id: Ib30455b41d1b05bff33cc0a627c1fc7e9a1b7568
Signed-off-by: Mohit Aggarwal <maggarwa@codeaurora.org>
In mmc_wr_pack_stats_read(), userspace buffer is directly accessed
which is violating PAN (Privilege Access Never).
So to prevent this, data which needs to be copied to user buffer is
gathered into a local buffer and at the end, this local buffer
contents are copied back to buffer supplied from user space using
copy_to_user().
Change-Id: Id772613fe54c47d64906c18d3d0249eee2f6ac26
Signed-off-by: Siba Prasad <sibap@codeaurora.org>
Set fixed rate in of_dummy_get since dummy_clk_dt_parser
is not called.
Change-Id: Id33be0a00a0a29100618f5fd25a917983f654025
Signed-off-by: Zhiqiang Tu <ztu@codeaurora.org>
Currently, charge_counter is based off CC_SOC_SW which is based
off coulomb counter. However, there could be some accumulation
of error due to inaccuracy in ADC over time. This can potentially
affect the accuracy of charge_counter. To overcome this, prime
CC_SOC_SW during discharging based off battery SOC and to a full
value during charge termination.
While at it, expose the charge_counter_shadow property based off
battery SOC for comparison.
CRs-Fixed: 2109421
Change-Id: I50de44afbdbd747db95946416a09062df205fd6c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
When SOC is held @ 100% after charge termination, charge_full
flag is cleared only when the monotonic SOC drops below recharge
SOC threshold. This can cause the flag to be held for a long time
when the charger is removed. Fix this by clearing charge_full
flag when charging status had changed from FULL.
Change-Id: I35b52ddc45f314347f0e4d8433d5fb550663267c
Signed-off-by: Subbaraman Narayanamurthy <subbaram@codeaurora.org>
Add null terminator at the end of string
extend_ioctl_data.u.rmnet_mux_val.vchannel_name
to avoid potential security issue.
Change-Id: I57fe3a9f7e3ad6a499b62a9cfc49bc6b2f3b42e0
Acked-by: Shihuan Liu <shihuanl@qti.qualcomm.com>
Signed-off-by: Skylar Chang <chiaweic@codeaurora.org>
If wlan driver probe returns error of defer, platform driver will
try to recover by calling probe again. The maximun probe count
is 2.
CRs-Fixed: 2124152
Change-Id: Ic973d0f1d76fc59ce5950397d42a9e778cacaa5a
Signed-off-by: Yuanyuan Liu <yuanliu@codeaurora.org>
commit d41519a69b35b10af7fda867fb9100df24fdf403 upstream.
On sparc, if we have an alloca() like situation, as is the case with
SHASH_DESC_ON_STACK(), we can end up referencing deallocated stack
memory. The result can be that the value is clobbered if a trap
or interrupt arrives at just the right instruction.
It only occurs if the function ends returning a value from that
alloca() area and that value can be placed into the return value
register using a single instruction.
For example, in lib/libcrc32c.c:crc32c() we end up with a return
sequence like:
return %i7+8
lduw [%o5+16], %o0 ! MEM[(u32 *)__shash_desc.1_10 + 16B],
%o5 holds the base of the on-stack area allocated for the shash
descriptor. But the return released the stack frame and the
register window.
So if an intererupt arrives between 'return' and 'lduw', then
the value read at %o5+16 can be corrupted.
Add a data compiler barrier to work around this problem. This is
exactly what the gcc fix will end up doing as well, and it absolutely
should not change the code generated for other cpus (unless gcc
on them has the same bug :-)
With crucial insight from Eric Sandeen.
Reported-by: Anatoly Pugachev <matorola@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As Ju Hyung Park reported:
"When 'fstrim' is called for manual trim, a BUG() can be triggered
randomly with this patch.
I'm seeing this issue on both x86 Desktop and arm64 Android phone.
On x86 Desktop, this was caused during Ubuntu boot-up. I have a
cronjob installed which calls 'fstrim -v /' during boot. On arm64
Android, this was caused during GC looping with 1ms gc_min_sleep_time
& gc_max_sleep_time."
Root cause of this issue is that f2fs_wait_discard_bios can only be
used by f2fs_put_super, because during put_super there must be no
other referrers, so it can ignore discard entry's reference count
when removing the entry, otherwise in other caller we will hit bug_on
in __remove_discard_cmd as there may be other issuer added reference
count in discard entry.
Thread A Thread B
- issue_discard_thread
- f2fs_ioc_fitrim
- f2fs_trim_fs
- f2fs_wait_discard_bios
- __issue_discard_cmd
- __submit_discard_cmd
- __wait_discard_cmd
- dc->ref++
- __wait_one_discard_bio
- __wait_discard_cmd
- __remove_discard_cmd
- f2fs_bug_on(sbi, dc->ref)
Change-Id: I8fb5c8215e6222ae853e7781218d5084e1f11166
Fixes: 969d1b180d987c2be02de890d0fff0f66a0e80de
Reported-by: Ju Hyung Park <qkrwngud825@gmail.com>
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
(cherry picked from commit 638164a2718f337ea224b747cf5977ef143166a4)
This patch removes fscrypto.h which was missed to remove when porting the
latest fs/crypto stuffs.
Change-Id: Ib17cba17d48535b0d754ae52537053098248a036
Fixes: 13f002354d ("f2fs: catch up to v4.14-rc1")
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
We should use FLAT_BINDER_FLAG_SCHED_POLICY_MASK as
the mask to calculate sched policy.
Change-Id: Ic252fd7c68495830690130d792802c02f99fc8fc
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Add verify flag in fs_mgr of vendor label to enable
verity on vendor partition for sdm630, sdm660 & msm8998.
Change-Id: I172b3f8da55059658bb0caff5c8b2cab905a21ad
Signed-off-by: Sachin Grover <sgrover@codeaurora.org>
commit 173b8439e1ba362007315868928bf9d26e5cc5a6 upstream.
While we allow deletes without the key, the following should not be
permitted:
# cd /vdc/encrypted-dir-without-key
# ls -l
total 4
-rw-r--r-- 1 root root 0 Dec 27 22:35 6,LKNRJsp209FbXoSvJWzB
-rw-r--r-- 1 root root 286 Dec 27 22:35 uRJ5vJh9gE7vcomYMqTAyD
# mv uRJ5vJh9gE7vcomYMqTAyD 6,LKNRJsp209FbXoSvJWzB
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a3bb2d5587521eea6dab2d05326abb0afb460abd upstream.
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by moving posix_acl_update_mode() out of
__ext4_set_acl() into ext4_set_acl(). That way the function will not be
called when inheriting ACLs which is what we want as it prevents SGID
bit clearing and the mode has been properly set by posix_acl_create()
anyway.
Fixes: 073931017b49d9458aa351605b43a7e34598caef
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a056bdaae7a181f7dcc876cfab2f94538e508709 upstream.
mpage_submit_page() can race with another process growing i_size and
writing data via mmap to the written-back page. As mpage_submit_page()
samples i_size too early, it may happen that ext4_bio_write_page()
zeroes out too large tail of the page and thus corrupts user data.
Fix the problem by sampling i_size only after the page has been
write-protected in page tables by clear_page_dirty_for_io() call.
Reported-by: Michael Zimmer <michael@swarm64.com>
CC: stable@vger.kernel.org
Fixes: cb20d51883
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50e76632339d4655859523a39249dd95ee5e93e7 upstream.
Cpusets vs. suspend-resume is _completely_ broken. And it got noticed
because it now resulted in non-cpuset usage breaking too.
On suspend cpuset_cpu_inactive() doesn't call into
cpuset_update_active_cpus() because it doesn't want to move tasks about,
there is no need, all tasks are frozen and won't run again until after
we've resumed everything.
But this means that when we finally do call into
cpuset_update_active_cpus() after resuming the last frozen cpu in
cpuset_cpu_active(), the top_cpuset will not have any difference with
the cpu_active_mask and this it will not in fact do _anything_.
So the cpuset configuration will not be restored. This was largely
hidden because we would unconditionally create identity domains and
mobile users would not in fact use cpusets much. And servers what do use
cpusets tend to not suspend-resume much.
An addition problem is that we'd not in fact wait for the cpuset work to
finish before resuming the tasks, allowing spurious migrations outside
of the specified domains.
Fix the rebuild by introducing cpuset_force_rebuild() and fix the
ordering with cpuset_wait_for_hotplug().
Reported-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Tejun Heo <tj@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: deb7aa308e ("cpuset: reorganize CPU / memory hotplug handling")
Link: http://lkml.kernel.org/r/20170907091338.orwxrqkbfkki3c24@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 77bf25ea70200cddf083f74b7f617e5f07fac8bd upstream.
[Back-ported to 4.4. The difference is the file location of the struct
definition that's adding the mutex.
This fixes reported kernel panics in 4.4-stable from simultaneous
controller resets that was never supposed to be allowed to happen.]
Signed-off-by: Keith Busch <keith.busch@intel.com>
[hch: split from a larger patch]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
