block: row: Remove warning massage from add_request

Regular priority queues is marked as "starved" if it skipped a dispatch
due to being empty. When a new request is added to a "starved" queue
it will be marked as urgent.
The removed WARN_ON was warning about an impossible case when a regular
priority (read) queue was marked as starved but wasn't empty. This is
a possible case due to the bellow:
If the device driver fetched a read request that is pending for
transmission and an URGENT request arrives, the fetched read will be
reinserted back to the scheduler. Its possible that the queue it will be
reinserted to was marked as "starved" in the meanwhile due to being empty.

CRs-fixed: 517800
Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
Revert "block: Add URGENT request notification support to CFQ scheduler"

This reverts commit b410a82118cdaa1dc92759e7995c20dcce0d1f1a.
The reverted commit was identified as the cause of the FS error
mentioned in the CR bellow.
It's reverted till further annalists of the root cause of FS error.

Change-Id: Ia75216de8012a2491b87f33e8c21f75592d87c80
CRs-fixed: 531257
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: core: Refactor bus speed selection code

The bus speed selection code in mmc_card_init() is convoluted, refactor
the code to simplify this and make it simpler for adding new bus speed
capabilities.

Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: card: update long_sequential_write_test queue depth

Since some systems have higher memory pressure, we limit the amount of
simultaneous test requests. The former limitation was 118, due to the
request queue size, but now we further restrict this number to half.

Change-Id: I893b9ad1b133c922f90497b0ec1f416514529fb8
CRs-fixed: 510814
Signed-off-by: Lee Susman <lsusman@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: block: flush request requeue after timeout.

On some eMMC cards cache flush is taking longer than 30 sec timeout
after HPI issued and -EIO reported to the upper layers. This may result
into journaling issues as flush calls are issued by the file system
joulrnaling code.

This change increases flash cache timeout to 90 sec, in case of timeout
occurs, after HPI issued, flash request re-queued to the block layer queue
to execute it later and keep journaling logic valid.

Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>

Conflicts:
	drivers/mmc/card/block.c

Change-Id: I1e968c07056062fd9c8e14e5bc3e62b3b4b99c64
Signed-off-by: Panwar Vivek <vpanwa@codeaurora.org>

Conflicts:

	drivers/mmc/card/block.c

Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
sdhci: sdhci_stop_request() returns error when no request

There is race between sdhci_tasklet_finish()
and sdhci_stop_request(): when the request is finished before
stop flow called, error returned.

Change-Id: Ic036feae925b2e9e5435e44f97b24a179547bf49
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: core: skip stop flow when current request already done

When mmc_stop_request() has no request to stop, because underlying
host driver reported this, the flow should wait for the mmc done()
callback marking that urgent still pending.

Change-Id: Iacc95591ee76a965916af05a31a67dd8997c233e
CRs-Fixed: 538117
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: block: Fix error path of mmc_blk_alloc_req()

In case of any error within mmc_blk_alloc_req(), the bitmaps
that keep track of devices are not getting cleared. This may
result in failure to detect a card in case it reaches maximum
devices limitation. Fix it by clearing those bitmaps appropriately.

CRs-fixed: 563264
Change-Id: I0e23c45856355565534146f5fabb957fd4b1d007
Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: sdhci: Use max timeout and skip timeout calculation

Several data-timeout issues were seen, most of which were
due to the card taking a longer time to respond. This patch
increases the timeout of the controller to 0xF i.e. max
possible.

Change-Id: I6739de3eb5d9cccf8e39d9dc4730056782334162
CRs-Fixed: 536832
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: core: increase timeout for disable cache operation

According to eMMC specification, there is no upper bound defined on
a flush request and the duration of flush operation is left to card
vendor's implementation. This means that it may take a very long
time to complete.

When eMMC cache is disabled, the card has to flush all the data in its
cache. So this means that for certain cards, the driver is not waiting
long enough for the flush to complete during cache disable operation,
leading to data on the card being corrupted.

This change increases the timeout for cache disable operation, thus
preventing data corruption.

CRs-Fixed: 562350
Change-Id: If68328ab56b50c7596800f07ef92c0ab16a55ec0
Signed-off-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: David Ng <dave@codeaurora.org>
Signed-off-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: core: do not reinsert prepeared FUA and FLUSH requests in stop flow

When mmc context has unblocked from waiting current request because of
urgent request notification coming from block layer, there is prepeared
request.  In the case, when the request is REQ_FUA or REQ_FLUSH, the
flow should not reinsert it back to i/o scheduler (since according to
block layer logic flush requests with data should never enter elevator).
Instead this request starts immediately.

Change-Id: Ia78b56c6135dd1a8d75a98fd5b771a5035e5c360
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
mmc: block: stop bkops during shutdown

[   42.885198] SysRq : Emergency Remount R/O
[   43.003988] mmc0: mmc_bus_shutdown: invoked ###
[   43.033289] mmc0: mmc_bus_shutdown: done ###
[   43.118486] mmc0: sdhci_request: sending cmd8 after bus shutdown !!!
[   43.147955] [<c0659ca4>] (sdhci_request+0x4c/0x260) from
				[<c063ee24>] (mmc_start_request+0x27c/0x2b0)
[   43.157152] [<c063ee24>] (mmc_start_request+0x27c/0x2b0) from
				[<c063eec4>] (mmc_wait_for_req+0x6c/0x13c)
[   43.166618] [<c063eec4>] (mmc_wait_for_req+0x6c/0x13c) from
				[<c0645ed4>] (mmc_send_cxd_data+0xe0/0x114)
[   43.175991] [<c0645ed4>] (mmc_send_cxd_data+0xe0/0x114) from
				[<c0645f24>] (mmc_send_ext_csd+0x1c/0x20)
[   43.185277] [<c0645f24>] (mmc_send_ext_csd+0x1c/0x20) from
				[<c063df28>] (mmc_read_bkops_status+0x98/0xdc)
[   43.194823] [<c063df28>] (mmc_read_bkops_status+0x98/0xdc) from
				[<c06417ac>] (mmc_start_bkops+0x168/0x324)
[   43.204461] [<c06417ac>] (mmc_start_bkops+0x168/0x324) from
				[<c01a9584>] (process_one_work+0x200/0x400)
[   43.213835] [<c01a9584>] (process_one_work+0x200/0x400) from
				[<c01a9934>] (worker_thread+0x184/0x2a4)
[   43.223039] [<c01a9934>] (worker_thread+0x184/0x2a4) from
				[<c01ae010>] (kthread+0x80/0x90)
[   43.231286] [<c01ae010>] (kthread+0x80/0x90) from
				[<c0106c4c>] (kernel_thread_exit+0x0/0x8)
[   45.648206] wcnss crash shutdown 0
[   45.650599] Rebooting in 5 seconds..

In the above log, it is seen that the bkops thread runs after
mmc_bus_shutdown is completed and sends CMD8. Hence, cancel
bkops work during shutdown to prevent sending commands after
mmc bus is shutdown.

CRs-fixed: 593813
Change-Id: I3e8e9eb228bd03603d04561eb478d60664f50aaa
Signed-off-by: Asutosh Das <asutoshd@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
block: do not notify urgent request, when flush with data in flight

MMC device driver implements URGENT request execution with priority
(using stop flow), as a result currently running (and prepared) request
may be reinserted back into I/O scheduler. This will break block layer
logic of flushes (flush request should not be inserted into I/O scheduler).

Block layer flush machinery keep q->flush_data_in_flight list updated with
started but not completed flush requests with data (REQ_FUA).

This change will not notify underling block device driver about pending
urgent request during flushes in flight.

Change-Id: I8b654925a3c989250fcb8f4f7c998795fb203923
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
fs/super.c: sync ro remount after blocking writers

Move sync_filesystem() after sb_prepare_remount_readonly().  If writers
sneak in anywhere from sync_filesystem() to sb_prepare_remount_readonly()
it can cause inodes to be dirtied and writeback to occur well after
sys_mount() has completely successfully.

This was spotted by corrupted ubifs filesystems on reboot, but appears
that it can cause issues with any filesystem using writeback.

CRs-Fixed: 627559
Change-Id: Ib417b59d39210aab2de4e5ae48b18129e8bc3e26
Cc: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
CC: Richard Weinberger <richard@nod.at>
Co-authored-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Andrew Ruder <andrew.ruder@elecsyscorp.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Git-commit: 807612db2f9940b9fa6deaef054eb16d51bd3e00
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
WLAN subsystem: Sysctl support for key TCP/IP parameters

It has been observed that default values for some of key tcp/ip
parameters are affecting the tput/performance of the system. Hence
extending configuration capabilities to TCP/Ip stack through
sysctl interface

CRs-Fixed: 507581

Change-Id: Ibaf821fcac9fba6448c5c23aef9d72946808e3cf
Signed-off-by: Kiran Kumar Lokere <klokere@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
msm: Create shadow files under /sys/kernel/ipv4

The TCP delayed ack parameters can be configured from user space
application which runs with non-root credentials and does not have
direct write access to /proc entries. This commit creates shadow
files under /sys/kernel/ipv4 which maps to /proc/sys/net/ipv4.

CRs-Fixed: 628139
Change-Id: Ib7242aaae930dbc02133e44c04e182ebc52bc89f
Signed-off-by: Ravi Joshi <ravij@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
tracing/syscalls: Fix perf syscall tracing when syscall_nr == -1

syscall_get_nr can return -1 in the case that the task is not executing
a system call.

This patch fixes perf_syscall_{enter,exit} to check that the syscall
number is valid before using it as an index into a bitmap.

Link: http://lkml.kernel.org/r/1345137254-7377-1-git-send-email-will.deacon@arm.com

Change-Id: Iedc719957e184c6572b3ad94e241ae2a97a0b533
Cc: Jason Baron <jbaron@redhat.com>
Cc: Wade Farnsworth <wade_farnsworth@mentor.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
tracing/syscalls: Ignore numbers outside NR_syscalls' range

ARM has some private syscalls (for example, set_tls(2)) which lie
outside the range of NR_syscalls.  If any of these are called while
syscall tracing is being performed, out-of-bounds array access will
occur in the ftrace and perf sys_{enter,exit} handlers.

 # trace-cmd record -e raw_syscalls:* true && trace-cmd report
 ...
 true-653   [000]   384.675777: sys_enter:            NR 192 (0, 1000, 3, 4000022, ffffffff, 0)
 true-653   [000]   384.675812: sys_exit:             NR 192 = 1995915264
 true-653   [000]   384.675971: sys_enter:            NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1)
 true-653   [000]   384.675988: sys_exit:             NR 983045 = 0
 ...

 # trace-cmd record -e syscalls:* true
 [   17.289329] Unable to handle kernel paging request at virtual address aaaaaace
 [   17.289590] pgd = 9e71c000
 [   17.289696] [aaaaaace] *pgd=00000000
 [   17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
 [   17.290169] Modules linked in:
 [   17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21
 [   17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000
 [   17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8
 [   17.290866] LR is at syscall_trace_enter+0x124/0x184

Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers.

Commit cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls"
added the check for less than zero, but it should have also checked
for greater than NR_syscalls.

Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in

Fixes: cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls"
Cc: stable@vger.kernel.org # 2.6.33+
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>

Conflicts:
	kernel/trace/trace_syscalls.c

Change-Id: I512142f8f1e1b2a8dc063209666dbce9737377e7
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
rtc: alarm: have dummy set_power_on_alarm function

When !CONFIG_RTC_CLASS we need to have a dummy set_power_on_alarm
function. Otherwise, it is easy to have build issues.

Change-Id: I39310241cc2e59f672964c8bc0ee4c3607aedf4e
Signed-off-by: Maria Yu <aiquny@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>
rtc: alarm: init power_on_alarm_lock mutex in alarmtimer_rtc_timer_init

Moved mutex_init of power_on_alarm_lock into alarmtimer_rtc_timer_init
so that if CONFIG_RTC_CLASS is not enabled, we dont try to initialize
the mutex.  This fixes a build issue when !CONFIG_RTC_CLASS

Change-Id: I270564b94fd54162aa177a2c9767655098662259
Signed-off-by: Kumar Gala <galak@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: Stefanescu Cristian <howerkraft@gmail.com>