Upstreamed Android kernel from v3.18.85 to v3.18.89

What is a linux kernel?

The linux kernel is a Organization established in 2002 to distribute the linux kernel & other opensource software to public without charge. The linux kernel org is maintained by the linux foundation

Why linux kernel is only used in Android Devices?

linux kernel is an open source project which means everyone can make modification & enhancements to meet mobile o/s requirements like better memory optimisations,Ram managements & better performance.

Description

Today i upstreamed my device kernel source to v3.18.89 there are more than 175+ patches to pick
here are link to some of them

https://github.com/DRohan898/kernel_xiaomi_msm8937/commit/c031c09c858bcb8319733a88985f01da929d9c9e

Description of this patch:-
If tcmu-runner is processing a STPG and needs to change the kernel's
ALUA state then we cannot use the same work queue for task management
requests and ALUA transitions, because we could deadlock. The problem
occurs when a STPG times out before tcmu-runner is able to
call into target_tg_pt_gp_alua_access_state_store->
core_alua_do_port_transition -> core_alua_do_transition_tg_pt ->
queue_work. In this case, the tmr is on the work queue waiting for
the STPG to complete, but the STPG transition is now queued behind
the waiting tmr

https://github.com/DRohan898/kernel_xiaomi_msm8937/commit/271dc225f7c0e0fab7ba49c5a2008cc890cc0145

Description of this patch:-
When the user sets count to zero the string buffer would remain
completely uninitialized which causes the kernel to parse its
own stack data, potentially leading to an info leak. In addition
to that, the string might be not terminated properly when the
user data does not contain a 0-terminator.

https://github.com/DRohan898/kernel_xiaomi_msm8937/commit/8aae5d24cdc72145da029982fccbef2b6e5a896a

Why this patch is used?
When session starts beyond offset 2^31 the arithmetics in
udf_check_vsd() would overflow. Make sure the computation is done in
large enough type.
A guy name Cezary Sliwa reported this issue so
changing
sector += (sbi->s_session << sb->s_blocksize_bits);
to
sector += (((loff_t)sbi->s_session) << sb->s_blocksize_bits);
will fix that issue

https://github.com/DRohan898/kernel_xiaomi_msm8937/commit/778e8f48dc8d44fb71b8763af46722676a000f39

why this patch is used?
It seems the driver need to include <asm/gpio.h> and <asm/irq.h>
to compile.
The Blackfin architecture was re-defining the Kconfig
PINCTRL symbol which is not OK, so replaced this with
PINCTRL_BLACKFIN_ADI2 which selects PINCTRL and PINCTRL_ADI2
just like most arches do.
Further, the old GPIO driver symbol GPIO_ADI was possible to
select at the same time as selecting PINCTRL. This was not
working because the arch-local <asm/gpio.h> header contains
an explicit #ifndef PINCTRL clause making compilation break
if you combine them. The same is true for DEBUG_MMRS.
Make sure the ADI2 pinctrl driver is not selected at the same
time as the old GPIO implementation. (This should be converted
to use gpiolib or pincontrol and move to drivers/...) Also make
sure the old GPIO_ADI driver or DEBUG_MMRS is not selected at
the same time as the new PINCTRL implementation, and only make
PINCTRL_ADI2 selectable for the Blackfin families that actually
have it.
This way it is still possible to add e.g. I2C-based pin
control expanders on the Blackfin.

https://github.com/DRohan898/kernel_xiaomi_msm8937/commit/61604bfd0f2414ede328e9ac87e57e1ec87dfb9d

This patch is used because
When removing a device, for example a VF being removed due to SR-IOV
teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
hot-unplug, we first remove the procfs and sysfs attributes for the device
before attempting to release the device from any driver bound to it.
Unbinding the driver from the device can take time. The device might need
to write out data or it might be actively in use. If it's in use by
userspace through a vfio driver, the unbind might block until the user
releases the device. This leads to a potentially non-trivial amount of
time where the device exists, but we've torn down the interfaces that
userspace uses to examine devices, for instance lspci might generate this
sort of error:
pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
lspci: Unable to read the standard configuration space header of device 0000:01:0a.3

https://github.com/DRohan898/kernel_xiaomi_msm8937/commit/2fa220cc7bac15cc251278293c8e9bb01e2832f0

Description of this patch:-
This patch fixes a deadlock caused when the jdata flag is set for
inodes that are already on the ordered write list. Since it is
on the ordered write list, log_flush calls gfs2_ordered_write which
calls filemap_fdatawrite. But since the inode had the jdata flag
set, that calls gfs2_jdata_writepages, which tries to start a new
transaction. A new transaction cannot be started because it tries
to acquire the log_flush rwsem which is already locked by the log
flush operation.

I can't list all the patches u can check it here & read commit name & its description for info