TRATS2: fimc: resetting the ctrl->status

resetting the ctrl->status with FIMC_STREAMOFF in an attempt to resolve
a 'fimc is running' issue after finishing the fimc_streamoff_capture
function. There is a case that ctrl->status isn't FIMC_STREAMOFF after
finishing the fimc_streamoff_capture function. Because the checking
available buffer in the fimc_irq_cap function can change ctrl->status
from FIMC_STREAMOFF to FIMC_BUFFER_STOP.

Signed-off-by: HJ.CHOI <hj210.choi@samsung.com>
Change-Id: I230ba88d76994e57279c6d7d19cdf67ece1d410b

[Fix for systemd] Enable autofs support

systemd has a great feature which can automatically mount filesystem on
demand, see systemd.automount(5) for details. This feature depends on
autofs support, so here just enable it.

Currently, only /proc/sys/fs/binfmt_misc leverages this feature, but
there maybe more in future.

Change-Id: I78b76e7070929da301f62c5284bcd4ff4bfc9fb4
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>

Protect global init (PID#1) from getting killed

OOM killer MUST NOT kill the global init. The same way init is protected
in mm/oom_kill.c.

Change-Id: Ia8d192e26b0fe3262efb18f62ac92fc8ada3f8a3
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

TRATS1: FIMC: workaround for fimc capture irq handling

workaround for TREL-267

Change-Id: I183bf5981a20b8d75ea74596edf2413605e8ccaa
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: slp_s5c73m3: Fix Full HD recording problem
apply variable frame rate for fix full HD recording issue. (2nd patch)
Signed-off-by: HJ.CHOI <hj210.choi@samsung.com>
Change-Id: I08f91ca5276f8907a813898416f1bda824db4bbd

TRATS2: slp_s5c73m3: Fix Full HD recording problem.
apply variable frame rate for fix full HD recording issue.

Change-Id: I12b786e55a66987767f4be1c5911120cf90737a4
Signed-off-by: Hyungjun Choi <hj210.choi@samsung.com>

drivers: misc: fix improper assigning value of old_real_free

This patch changes the unit of old_real_free from the page count to MB.

/* we save the tasks and rss info when free memory size is minimum,
 * which means total used memory is highest at that moment. */
if (check_peak && (old_real_free > real_free)) {
    old_real_free = real_free;

If initial value of the old_real_free is saved in page count, this comparison is
totally wrong. So we need to change the unit of old_real_free.

Please refer this issue in the https://bugs.tizen.org/jira/browse/TDIST-163

Change-Id: Idd8805cb7af83858b5d92ec8d9064ea221e1cb60
Reported-by: Youngsik Yoon<youngsik.yoon@intel.com>
Signed-off-by: Chanho Park <chanho61.park@samsung.com>

TRATS2: fimc: Fix front camera 640x420 capture fail error

Fix padding buffer size error when someone is using it.

Change-Id: Ia84ecd811c23ecea52576e80cf847182d4f57980
Signed-off-by: HJ.CHOI <hj210.choi@samsung.com>

When smk_set_cipso() parsing the CIPSO setting from userspace, the offset of CIPSO level
should be "strlen(label)+1" instead of "strlen(label)"

Change-Id: I7eb62db733895e992765e19e350d254bf06d7123

drm/exynos: fix user interface to g2d driver

64bit data type should be used to transfer user space pointer
into kernel space.

Change-Id: I35590c8d158908e3ac6556495dd30559c4e50b16
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Bluetooth: Add support for 128-bit UUIDs in EIR data

This patch adds the necessary code for encoding a list of 128-bit UUIDs
into the EIR data.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=c7998c8a434d80e5d4d19ed1196ba390fc36a56a

Change-Id: I7a5febd0ec2d96991994b2c9f0e938eda24eda76
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Add support for 32-bit UUIDs in EIR data

This patch adds the necessary code for inserting a list of 32-bit UUIDs
into the EIR data.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=cf4e4acd982b59602b2208bc4ddfb720d30521ea

Change-Id: Ic6d433ed22d9a7b655e9283803fc98c371c833d7
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Refactor UUID-16 list generation into its own function

We will need to create three separate UUID lists in the EIR data (for
16, 32 and 128 bit UUIDs) so the code is easier to follow if each list
is generated in their own function.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=4d071aebc17f788b2fc11041236dd6ca293ef4c6

Change-Id: Ib7a2ed514f7fb72881d088d282297850d2aa6bc3
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Remove useless eir_len variable from EIR creation

The amount of data encoded so far in the create_eir() function can be
calculated simply through the difference between the data and ptr
pointer variables. The eir_len variable then becomes essentially
useless.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=63365177976154ac6455962f45cf003928212d64

Change-Id: Ieeb6c572e07c69ca27ebf7ce5e35a34f754425fd
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Simplify UUID16 list generation for EIR

There's no need to use two separate loops to generate a UUID list for
the EIR data. This patch merges the two loops previously used for the
16-bit UUID list generation into a single loop, thus simplifying the
code a great deal.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=186dc23da07b3fe827343089a5728325da0776bb

Change-Id: Ide1d38477db57fd6e412cc958117fdff36966f19
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Simplify UUID removal code

The UUID removal code can be simplified by using
list_for_each_entry_safe instead of list_for_each_safe.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=1ef2f5a1cb9afcacb5063a96e3401b189d2921ac

Change-Id: I1a8f5c6ee117bab4986aac66bf784c341fb2191d
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <goodguy.lee@samsung.com>

Bluetooth: Keep track of UUID type upon addition

The primary purpose of the UUIDs is to enable generation of EIR and AD
data. In these data formats the UUIDs are split into separate fields
based on whether they're 16, 32 or 128 bit UUIDs. To make the generation
of these data fields simpler this patch adds a type member to the
bt_uuid struct and assigns a value to it as soon as the UUID is added to
the kernel. This way the type doesn't need to be calculated each time
the UUID list is later iterated.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=225ac2c1279f9f33ecce15257692603604cdb467

Change-Id: Ia6d355dee6414b15396ce39abaab662d57374499
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Simplify UUIDs clearing code

The code for clearing the UUIDs list can be simplified by using
list_for_each_entry_safe instead of list_for_each_safe.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=6051357b978e28c461fbbdfa00061466152fd01e

Change-Id: I1ada4bc11a7edcb23d1bbea3232eaeda76c94609
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

Bluetooth: Store UUIDs in the same order that they were added

We should be encoding UUIDs to the EIR data in the same order that they
were added to the kernel, i.e. each UUID should be added to the end of
the UUIDs list. This patch fixes the issue by using list_add_tail
instead of list_add for storing the UUIDs.

Ref: http://git.kernel.org/?p=linux/kernel/git/bluetooth/bluetooth-next.git;
a=commit;h=863d6dff829fbfce7f7b6f3f9a91e09022a00f9e

Change-Id: I3b8624ef6f301b41b008ea390ef6a492506032b8
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Tested-by: Dohyun Pyun <dh79.pyun@samsung.com>

TRATS/TRATS2: enable the IKCONFIG_PROC

Enabled the IKCONFIG_PROC for using /proc/config.gz

Change-Id: I4bdd2f81dfa4bc232e2be4ddf6ca06be9e18579e
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: M5MO: revert FACEDETECT configuration by default

By removing flash feature, it is no longer needed FACEDTECT configuration
by default.

Change-Id: Idae74a7e85875c3a74884a007a6897b8e00598d4
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

kernel/sys.c: fix stack memory content leak via UNAME26

Calling uname() with the UNAME26 personality set allows a leak of kernel
stack contents.  This fixes it by defensively calculating the length of
copy_to_user() call, making the len argument unsigned, and initializing
the stack buffer to zero (now technically unneeded, but hey, overkill).

CVE-2012-0957

Reported-by: PaX Team <pageexec@freemail.hu>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: PaX Team <pageexec@freemail.hu>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I9de2af6803b746650c44de30e22a7ed63a139cfc

TRATS2: S5C73M3: support 3264x2488 and 3264x1836 preview resolution.

support 3264x2488 and 3264x1836 preview resolution(S5C73M3_PREVIEW_HDR)

Change-Id: I34a26b2a625e55ec3478a41d80a3fe452c0b6efe
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS: defconfig: enable BLK_DEV_CRYPTOLOOP

Enabled this config for moving something to the internal storage

Change-Id: I80f44b394bf3e8413dccf483aa97d3dbeb7dfdfe
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

Revert "TRATS: M5MO: ZOOM_LEVEL_MAX changed to 12."

This reverts commit c596d48c84d238fdea7cf1371112b4b185bbd613.

It is decided to remove U1HD-M5MO FLASH function.
Thus, we do not need workarounds for FLASH function anymore.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I4c3243cb9102c0eee12551470f6334856c4f3e75

rtc: max77686: Disable day of week for alram setting.

Change-Id: I05e76ae843161742fea43e58518792cad24bd98f
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>

Sensor: AK8975: reduce delay of magnetic sensor

We have added delay for AK8975 operations; however, the previous
delay value was an overkill and could be reduced.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: Ib22548a3db2840d97303f925bbd9771eed22d1d1

TRATS2: fix umts io devices

Apply umts io devices of tizen.

Change-Id: I55165d79aae3da57e60f68b8944177fdee6982a7
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS2: remove EHCI_REG_DUMP feature

We don't use this.

Change-Id: I929698f33ef9a0edcb5bf0811bde56d1fbe9066d
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS2: remove modem simdetect polarity feature

We don't use this.

Change-Id: I3f76dc0aae20db32a033781f470349e49ce6d836
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS2: fix modem gpio configuration

Use s5p_gpio_set_pd_cfg instead of s3c_gpio_slp_cfgpin to set gpio pd
configuation.

Change-Id: Ibd630945142d580e0fbab5bb8012e9a42cc77c62
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

TRATS: M5MO: ZOOM_LEVEL_MAX changed to 12.

Change-Id: I2230bbeca8f2fdf4ad60060f6b91d57dc024efef
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: AK8975C Sensor Operation Issue

When two IOCTLS and MODE CHANGES arrive with too short interval,
AK8975C halts operating and provides the same value until a reboot.
This patch gives an unconditional msleep in order to prevent this.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I6d930ccb993871daba94ed3157de192f9f483c1a

BUSFREQ: Disable low freqeuncy; 133Mhz, 100Mhz.

Change-Id: Ib090b43c3eae6924bc1ced3edcff083f9d2225bc
Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>

TRATS: m5mo: initiate status of focus mode to select the first auto mode.

to select the fist auto mode, initial status of focus mode was changed
to FOCUS_MODE_DEFAULT.

Change-Id: I3db2bb9550fb435526a11aff8168020b2f9b2f0a
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2:Sensor:When light sensor is enabled, input event report immediatedly

This patch fixed the bug related with sound volum.

Change-Id: I30f1cb6a8bedb8651065aa44526b4d6bb9a75cdb
Signed-off-by: cs2005.oh <cs2005.oh@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

SLP: All: Apply tempory fix for screen blinking.

we applied fix for screen blinking issue which revise busfreq.

Change-Id: I44ea734b757b51a90a6fe2308c43f86ffd7cab62
Signed-off-by: dongil01.park <dongil01.park@samsung.com>

BUSFREQ: add bus_dev to get exynos-busfreq device

Change-Id: Iec009c4411aedad88e3ea05e47d9a48cccb74b90
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

SLP:Trats:Sensor:Change the gp2ap020 sensor driver

-When proximity sensor and light sensor is enabled all, proximity raw data is reported wrong
-Change the driver file that is fixed this issue

-Cherry-picked to address TDIS-2945

Change-Id: Ifdea8246ccf7ee3c94bc3a968042b3cc3cb87009
Signed-off-by: cs2005.oh <cs2005.oh@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>

TRATS2: video: fix horizontal porch value

fix horizontal porch values to set mipi dsi timming.
After this patch, unexpected line on display panel was removed.

Change-Id: I248cfb70b9317e14e5d28cc2cfe3ecddb3692502
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2: video: update mipi dsi platform data

update mipi dsi platform data properly

Change-Id: I9f436397bcd695d029e012b25f74401abfac3c24
Signed-off-by: Donghwa Lee <dh09.lee@samsung.com>

TRATS2 / Move jack event handler to sync charger status.

Move jack event handler to sync charer status in order to
have the event triggered faster, eliminating mismatched
events.

Conflict resolved from the original patch of
dongil01.park <dongil01.park@samsung.com>.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: I6f8069c2dae476fc295139a8bd93ba14c516d000

TRATS: WiFi: remove the duplicated define

WRITE_MACADDR is already defined at Makefile.

Change-Id: I340e07c5b0fe3e02643a9e518c7953fcee67d9ea
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: WiFi: Fixed kernel panic problem for specific scan

Original author is Byeonghoon Ahn

Change-Id: I50c96a980b58eb5748eb3bb75f13076b80fed290
Signed-off-by: Byeonghoon Ahn <bh87.ahn@samsung.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: bluetooth: enable CONFIG_BT_TIZEN

enable CONFIG_BT_TIZEN for TRATS1

Change-Id: Id6fbf7813f30a7ff0c8de84ceadb66f0b85c4882
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

TRATS2: PM: remove the unnecessary code for sleep

When WiFi is entered suspend, didn't power down.

Change-Id: I2002073c00be904b72e5e416105d872ed68e04fd
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: M5MO: enable FACE_DETECT_CTL by default

Enable to draw frame on YUV-data and face detect by default.
And change mode to FOCUS_MODE_AUTO when driver receives invalid
value.

Change-Id: I57af8f0428e282c112b8ec73b865ce4d6c1bae1b
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

[PATCH] Bluetooth: Fix to update EIR for uuid16 properly

If we register uuid other than uuid16, especially custom 128 bit uuid
then nothing is updated in the EIR and it was broken.
Currently only uuid16 is only handled in the EIR updation.

After registering a 16 bit uuid. ex: "sdptool add SP" we can see the
uuid in the EIR.
< 0000: 01 52 0c f1 00 08 09 52  65 64 77 6f 6f 64 15 03  .R.....Redwood..
  0010: 01 11 32 11 2f 11 06 11  05 11 0a 11 0e 11 0c 11  ..2./...........
  0020: 1f 11 12 11 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0080: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00f0: 00 00 00 00 00                                    .....
> 0000: 04 0e 04 01 52 0c 00                              ....R..

After register a user defined 128 bit uuid, nothing is
updated in the EIR.

< 0000: 01 52 0c f1 00 08 09 52  65 64 77 6f 6f 64 00 00  .R.....Redwood..
  0010: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0020: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0030: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0040: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0050: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0060: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0070: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0080: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  0090: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00a0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00b0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00c0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00d0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00e0: 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ................
  00f0: 00 00 00 00 00                                    .....
> 0000: 04 0e 04 01 52 0c 00                              ....R..

Change-Id: I68e4a3ce379157d4f68722d916570a54c4bda136

TRATS: fixed default auto focus mode and wrong fps value

fixed default auto focus mode and print warning message.
And fixed wrong fps value.

Change-Id: I07d12e2ebbb88cbdbfbc6aecc4104f618bc74ed4
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

TRATS/TRATS2: enable the FANOTIFY config for system readahead

Enable the FANOTFY configuration for system readahead.

Change-Id: I5ed4097dc279cf06f24e3d7972905c33163dfa04
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

oom: fix integer overflow of points in oom_badness

An integer overflow will happen on 64bit archs if task's sum of rss,
swapents and nr_ptes exceeds (2^31)/1000 value.  This was introduced by
commit

f755a04 oom: use pte pages in OOM score

where the oom score computation was divided into several steps and it's no
longer computed as one expression in unsigned long(rss, swapents, nr_pte
are unsigned long), where the result value assigned to points(int) is in
range(1..1000).  So there could be an int overflow while computing

176          points *= 1000;

and points may have negative value. Meaning the oom score for a mem hog task
will be one.

196          if (points <= 0)
197                  return 1;

For example:
[ 3366]     0  3366 35390480 24303939   5       0             0 oom01
Out of memory: Kill process 3366 (oom01) score 1 or sacrifice child

Here the oom1 process consumes more than 24303939(rss)*4096~=92GB physical
memory, but it's oom score is one.

In this situation the mem hog task is skipped and oom killer kills another and
most probably innocent task with oom score greater than one.

The points variable should be of type long instead of int to prevent the
int overflow.

Signed-off-by: Frantisek Hrbata <fhrbata@redhat.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
[Patch applied to resolve tizendev.org issue: TDIS-1691]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Id434f1615af88e5dc9979d4b8c45213875633dbe

rds: set correct msg_namelen

Jay Fenlason (fenlason@redhat.com) found a bug,
that recvfrom() on an RDS socket can return the contents of random kernel
memory to userspace if it was called with a address length larger than
sizeof(struct sockaddr_in).
rds_recvmsg() also fails to set the addr_len paramater properly before
returning, but that's just a bug.
There are also a number of cases wher recvfrom() can return an entirely bogus
address. Anything in rds_recvmsg() that returns a non-negative value but does
not go through the "sin = (struct sockaddr_in *)msg->msg_name;" code path
at the end of the while(1) loop will return up to 128 bytes of kernel memory
to userspace.

And I write two test programs to reproduce this bug, you will see that in
rds_server, fromAddr will be overwritten and the following sock_fd will be
destroyed.
Yes, it is the programmer's fault to set msg_namelen incorrectly, but it is
better to make the kernel copy the real length of address to user space in
such case.

How to run the test programs ?
I test them on 32bit x86 system, 3.5.0-rc7.

1 compile
gcc -o rds_client rds_client.c
gcc -o rds_server rds_server.c

2 run ./rds_server on one console

3 run ./rds_client on another console

4 you will see something like:
server is waiting to receive data...
old socket fd=3
server received data from client:data from client
msg.msg_namelen=32
new socket fd=-1067277685
sendmsg()
: Bad file descriptor

/***************** rds_client.c ********************/

int main(void)
{
int sock_fd;
struct sockaddr_in serverAddr;
struct sockaddr_in toAddr;
char recvBuffer[128] = "data from client";
struct msghdr msg;
struct iovec iov;

sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
if (sock_fd < 0) {
perror("create socket error\n");
exit(1);
}

memset(&serverAddr, 0, sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
serverAddr.sin_port = htons(4001);

if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
perror("bind() error\n");
close(sock_fd);
exit(1);
}

memset(&toAddr, 0, sizeof(toAddr));
toAddr.sin_family = AF_INET;
toAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
toAddr.sin_port = htons(4000);
msg.msg_name = &toAddr;
msg.msg_namelen = sizeof(toAddr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_iov->iov_base = recvBuffer;
msg.msg_iov->iov_len = strlen(recvBuffer) + 1;
msg.msg_control = 0;
msg.msg_controllen = 0;
msg.msg_flags = 0;

if (sendmsg(sock_fd, &msg, 0) == -1) {
perror("sendto() error\n");
close(sock_fd);
exit(1);
}

printf("client send data:%s\n", recvBuffer);

memset(recvBuffer, '\0', 128);

msg.msg_name = &toAddr;
msg.msg_namelen = sizeof(toAddr);
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_iov->iov_base = recvBuffer;
msg.msg_iov->iov_len = 128;
msg.msg_control = 0;
msg.msg_controllen = 0;
msg.msg_flags = 0;
if (recvmsg(sock_fd, &msg, 0) == -1) {
perror("recvmsg() error\n");
close(sock_fd);
exit(1);
}

printf("receive data from server:%s\n", recvBuffer);

close(sock_fd);

return 0;
}

/***************** rds_server.c ********************/

int main(void)
{
struct sockaddr_in fromAddr;
int sock_fd;
struct sockaddr_in serverAddr;
unsigned int addrLen;
char recvBuffer[128];
struct msghdr msg;
struct iovec iov;

sock_fd = socket(AF_RDS, SOCK_SEQPACKET, 0);
if(sock_fd < 0) {
perror("create socket error\n");
exit(0);
}

memset(&serverAddr, 0, sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_addr.s_addr = inet_addr("127.0.0.1");
serverAddr.sin_port = htons(4000);
if (bind(sock_fd, (struct sockaddr*)&serverAddr, sizeof(serverAddr)) < 0) {
perror("bind error\n");
close(sock_fd);
exit(1);
}

printf("server is waiting to receive data...\n");
msg.msg_name = &fromAddr;

/*
 * I add 16 to sizeof(fromAddr), ie 32,
 * and pay attention to the definition of fromAddr,
 * recvmsg() will overwrite sock_fd,
 * since kernel will copy 32 bytes to userspace.
 *
 * If you just use sizeof(fromAddr), it works fine.
 * */
msg.msg_namelen = sizeof(fromAddr) + 16;
/* msg.msg_namelen = sizeof(fromAddr); */
msg.msg_iov = &iov;
msg.msg_iovlen = 1;
msg.msg_iov->iov_base = recvBuffer;
msg.msg_iov->iov_len = 128;
msg.msg_control = 0;
msg.msg_controllen = 0;
msg.msg_flags = 0;

while (1) {
printf("old socket fd=%d\n", sock_fd);
if (recvmsg(sock_fd, &msg, 0) == -1) {
perror("recvmsg() error\n");
close(sock_fd);
exit(1);
}
printf("server received data from client:%s\n", recvBuffer);
printf("msg.msg_namelen=%d\n", msg.msg_namelen);
printf("new socket fd=%d\n", sock_fd);
strcat(recvBuffer, "--data from server");
if (sendmsg(sock_fd, &msg, 0) == -1) {
perror("sendmsg()\n");
close(sock_fd);
exit(1);
}
}

close(sock_fd);
return 0;
}

Signed-off-by: Weiping Pan <wpan@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-1589]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I72b79e8e3f33ff2d6e90ce71a75ca0d3a77bc7ee

mm: Hold a file reference in madvise_remove

Otherwise the code races with munmap (causing a use-after-free
of the vma) or with close (causing a use-after-free of the struct
file).

The bug was introduced by commit 90ed52ebe481 ("[PATCH] holepunch: fix
mmap_sem i_mutex deadlock")

Cc: Hugh Dickins <hugh@veritas.com>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Nick Piggin <npiggin@suse.de>
Cc: stable@vger.kernel.org
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1590]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Iffd4324271a6ac7831b4efea3477995f692c3d30

block: fail SCSI passthrough ioctls on partition devices

Linux allows executing the SG_IO ioctl on a partition or LVM volume, and
will pass the command to the underlying block device.  This is
well-known, but it is also a large security problem when (via Unix
permissions, ACLs, SELinux or a combination thereof) a program or user
needs to be granted access only to part of the disk.

This patch lets partitions forward a small set of harmless ioctls;
others are logged with printk so that we can see which ioctls are
actually sent.  In my tests only CDROM_GET_CAPABILITY actually occurred.
Of course it was being sent to a (partition on a) hard disk, so it would
have failed with ENOTTY and the patch isn't changing anything in
practice.  Still, I'm treating it specially to avoid spamming the logs.

In principle, this restriction should include programs running with
CAP_SYS_RAWIO.  If for example I let a program access /dev/sda2 and
/dev/sdb, it still should not be able to read/write outside the
boundaries of /dev/sda2 independent of the capabilities.  However, for
now programs with CAP_SYS_RAWIO will still be allowed to send the
ioctls.  Their actions will still be logged.

This patch does not affect the non-libata IDE driver.  That driver
however already tests for bd != bd->bd_contains before issuing some
ioctl; it could be restricted further to forbid these ioctls even for
programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO.

Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>
Cc: James Bottomley <JBottomley@parallels.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[ Make it also print the command name when warning - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1622]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ib19bb420d7c57358dd7fd00475dcb1f26a57b6ac

xfs: validate acl count

This prevents in-memory corruption and possible panics if the on-disk
ACL is badly corrupted.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Ben Myers <bpm@sgi.com>
[Patch applied to resolve tizendev.org issue: TDIS-1623]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I473d0982f4b307e9373df9d849b430ec00cc03fe

KVM: x86: fix missing checks in syscall emulation

On hosts without this patch, 32bit guests will crash (and 64bit guests
may behave in a wrong way) for example by simply executing following
nasm-demo-application:

    [bits 32]
    global _start
    SECTION .text
    _start: syscall

(I tested it with winxp and linux - both always crashed)

    Disassembly of section .text:

    00000000 <_start>:
       0:   0f 05                   syscall

The reason seems a missing "invalid opcode"-trap (int6) for the
syscall opcode "0f05", which is not available on Intel CPUs
within non-longmodes, as also on some AMD CPUs within legacy-mode.
(depending on CPU vendor, MSR_EFER and cpuid)

Because previous mentioned OSs may not engage corresponding
syscall target-registers (STAR, LSTAR, CSTAR), they remain
NULL and (non trapping) syscalls are leading to multiple
faults and finally crashs.

Depending on the architecture (AMD or Intel) pretended by
guests, various checks according to vendor's documentation
are implemented to overcome the current issue and behave
like the CPUs physical counterparts.

[mtosatti: cleanup/beautify code]

Signed-off-by: Stephan Baerwolf <stephan.baerwolf@tu-ilmenau.de>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
[Patch applied to resolve tizendev.org issue: TDIS-1624]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I645b230089f377d3ea1ca1c4970c80553b3ba684

cifs: fix dentry refcount leak when opening a FIFO on lookup

The cifs code will attempt to open files on lookup under certain
circumstances. What happens though if we find that the file we opened
was actually a FIFO or other special file?

Currently, the open filehandle just ends up being leaked leading to
a dentry refcount mismatch and oops on umount. Fix this by having the
code close the filehandle on the server if it turns out not to be a
regular file. While we're at it, change this spaghetti if statement
into a switch too.

Cc: stable@vger.kernel.org
Reported-by: CAI Qian <caiqian@redhat.com>
Tested-by: CAI Qian <caiqian@redhat.com>
Reviewed-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
[Patch applied to resolve tizendev.org issue: TDIS-1626]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ibafb2fa4656d5decdb8ef4f289f6602bfd10ca88

mm: thp: fix pmd_bad() triggering in code paths holding mmap_sem read…

In some cases it may happen that pmd_none_or_clear_bad() is called with
the mmap_sem hold in read mode.  In those cases the huge page faults can
allocate hugepmds under pmd_none_or_clear_bad() and that can trigger a
false positive from pmd_bad() that will not like to see a pmd
materializing as trans huge.

It's not khugepaged causing the problem, khugepaged holds the mmap_sem
in write mode (and all those sites must hold the mmap_sem in read mode
to prevent pagetables to go away from under them, during code review it
seems vm86 mode on 32bit kernels requires that too unless it's
restricted to 1 thread per process or UP builds).  The race is only with
the huge pagefaults that can convert a pmd_none() into a
pmd_trans_huge().

Effectively all these pmd_none_or_clear_bad() sites running with
mmap_sem in read mode are somewhat speculative with the page faults, and
the result is always undefined when they run simultaneously.  This is
probably why it wasn't common to run into this.  For example if the
madvise(MADV_DONTNEED) runs zap_page_range() shortly before the page
fault, the hugepage will not be zapped, if the page fault runs first it
will be zapped.

Altering pmd_bad() not to error out if it finds hugepmds won't be enough
to fix this, because zap_pmd_range would then proceed to call
zap_pte_range (which would be incorrect if the pmd become a
pmd_trans_huge()).

The simplest way to fix this is to read the pmd in the local stack
(regardless of what we read, no need of actual CPU barriers, only
compiler barrier needed), and be sure it is not changing under the code
that computes its value.  Even if the real pmd is changing under the
value we hold on the stack, we don't care.  If we actually end up in
zap_pte_range it means the pmd was not none already and it was not huge,
and it can't become huge from under us (khugepaged locking explained
above).

All we need is to enforce that there is no way anymore that in a code
path like below, pmd_trans_huge can be false, but pmd_none_or_clear_bad
can run into a hugepmd.  The overhead of a barrier() is just a compiler
tweak and should not be measurable (I only added it for THP builds).  I
don't exclude different compiler versions may have prevented the race
too by caching the value of *pmd on the stack (that hasn't been
verified, but it wouldn't be impossible considering
pmd_none_or_clear_bad, pmd_bad, pmd_trans_huge, pmd_none are all inlines
and there's no external function called in between pmd_trans_huge and
pmd_none_or_clear_bad).

if (pmd_trans_huge(*pmd)) {
if (next-addr != HPAGE_PMD_SIZE) {
VM_BUG_ON(!rwsem_is_locked(&tlb->mm->mmap_sem));
split_huge_page_pmd(vma->vm_mm, pmd);
} else if (zap_huge_pmd(tlb, vma, pmd, addr))
continue;
/* fall through */
}
if (pmd_none_or_clear_bad(pmd))

Because this race condition could be exercised without special
privileges this was reported in CVE-2012-1179.

The race was identified and fully explained by Ulrich who debugged it.
I'm quoting his accurate explanation below, for reference.

====== start quote =======
      mapcount 0 page_mapcount 1
      kernel BUG at mm/huge_memory.c:1384!

    At some point prior to the panic, a "bad pmd ..." message similar to the
    following is logged on the console:

      mm/memory.c:145: bad pmd ffff8800376e1f98(80000000314000e7).

    The "bad pmd ..." message is logged by pmd_clear_bad() before it clears
    the page's PMD table entry.

        143 void pmd_clear_bad(pmd_t *pmd)
        144 {
    ->  145         pmd_ERROR(*pmd);
        146         pmd_clear(pmd);
        147 }

    After the PMD table entry has been cleared, there is an inconsistency
    between the actual number of PMD table entries that are mapping the page
    and the page's map count (_mapcount field in struct page). When the page
    is subsequently reclaimed, __split_huge_page() detects this inconsistency.

       1381         if (mapcount != page_mapcount(page))
       1382                 printk(KERN_ERR "mapcount %d page_mapcount %d\n",
       1383                        mapcount, page_mapcount(page));
    -> 1384         BUG_ON(mapcount != page_mapcount(page));

    The root cause of the problem is a race of two threads in a multithreaded
    process. Thread B incurs a page fault on a virtual address that has never
    been accessed (PMD entry is zero) while Thread A is executing an madvise()
    system call on a virtual address within the same 2 MB (huge page) range.

               virtual address space
              .---------------------.
              |                     |
              |                     |
            .-|---------------------|
            | |                     |
            | |                     |<-- B(fault)
            | |                     |
      2 MB  | |/////////////////////|-.
      huge <  |/////////////////////|  > A(range)
      page  | |/////////////////////|-'
            | |                     |
            | |                     |
            '-|---------------------|
              |                     |
              |                     |
              '---------------------'

    - Thread A is executing an madvise(..., MADV_DONTNEED) system call
      on the virtual address range "A(range)" shown in the picture.

    sys_madvise
      // Acquire the semaphore in shared mode.
      down_read(&current->mm->mmap_sem)
      ...
      madvise_vma
        switch (behavior)
        case MADV_DONTNEED:
             madvise_dontneed
               zap_page_range
                 unmap_vmas
                   unmap_page_range
                     zap_pud_range
                       zap_pmd_range
                         //
                         // Assume that this huge page has never been accessed.
                         // I.e. content of the PMD entry is zero (not mapped).
                         //
                         if (pmd_trans_huge(*pmd)) {
                             // We don't get here due to the above assumption.
                         }
                         //
                         // Assume that Thread B incurred a page fault and
             .---------> // sneaks in here as shown below.
             |           //
             |           if (pmd_none_or_clear_bad(pmd))
             |               {
             |                 if (unlikely(pmd_bad(*pmd)))
             |                     pmd_clear_bad
             |                     {
             |                       pmd_ERROR
             |                         // Log "bad pmd ..." message here.
             |                       pmd_clear
             |                         // Clear the page's PMD entry.
             |                         // Thread B incremented the map count
             |                         // in page_add_new_anon_rmap(), but
             |                         // now the page is no longer mapped
             |                         // by a PMD entry (-> inconsistency).
             |                     }
             |               }
             |
             v
    - Thread B is handling a page fault on virtual address "B(fault)" shown
      in the picture.

    ...
    do_page_fault
      __do_page_fault
        // Acquire the semaphore in shared mode.
        down_read_trylock(&mm->mmap_sem)
        ...
        handle_mm_fault
          if (pmd_none(*pmd) && transparent_hugepage_enabled(vma))
              // We get here due to the above assumption (PMD entry is zero).
              do_huge_pmd_anonymous_page
                alloc_hugepage_vma
                  // Allocate a new transparent huge page here.
                ...
                __do_huge_pmd_anonymous_page
                  ...
                  spin_lock(&mm->page_table_lock)
                  ...
                  page_add_new_anon_rmap
                    // Here we increment the page's map count (starts at -1).
                    atomic_set(&page->_mapcount, 0)
                  set_pmd_at
                    // Here we set the page's PMD entry which will be cleared
                    // when Thread A calls pmd_clear_bad().
                  ...
                  spin_unlock(&mm->page_table_lock)

    The mmap_sem does not prevent the race because both threads are acquiring
    it in shared mode (down_read).  Thread B holds the page_table_lock while
    the page's map count and PMD table entry are updated.  However, Thread A
    does not synchronize on that lock.

====== end quote =======

[akpm@linux-foundation.org: checkpatch fixes]
Reported-by: Ulrich Obergfell <uobergfe@redhat.com>
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Dave Jones <davej@redhat.com>
Acked-by: Larry Woodman <lwoodman@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Mark Salter <msalter@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1629]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I9f91598c091fa80dfc3aa5506d7d0f595d7642ca

KVM: Ensure all vcpus are consistent with in-kernel irqchip settings

If some vcpus are created before KVM_CREATE_IRQCHIP, then
irqchip_in_kernel() and vcpu->arch.apic will be inconsistent, leading
to potential NULL pointer dereferences.

Fix by:
- ensuring that no vcpus are installed when KVM_CREATE_IRQCHIP is called
- ensuring that a vcpu has an apic if it is installed after KVM_CREATE_IRQCHIP

This is somewhat long winded because vcpu->arch.apic is created without
kvm->lock held.

Based on earlier patch by Michael Ellerman.

Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Avi Kivity <avi@redhat.com>
[Patch applied to resolve tizendev.org issue: TDIS-1630]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I33b128c1762ead12a12ef13df8d1a1bfedc798ff

KVM: unmap pages from the iommu when slots are removed

commit 32f6daa upstream.

We've been adding new mappings, but not destroying old mappings.
This can lead to a page leak as pages are pinned using
get_user_pages, but only unpinned with put_page if they still
exist in the memslots list on vm shutdown.  A memslot that is
destroyed while an iommu domain is enabled for the guest will
therefore result in an elevated page reference count that is
never cleared.

Additionally, without this fix, the iommu is only programmed
with the first translation for a gpa.  This can result in
peer-to-peer errors if a mapping is destroyed and replaced by a
new mapping at the same gpa as the iommu will still be pointing
to the original, pinned memory address.

Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1632]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ie349c15d2597a1726a23a84c8cdfdd0adacdd05e

hugepages: fix use after free bug in "quota" handling

hugetlbfs_{get,put}_quota() are badly named.  They don't interact with the
general quota handling code, and they don't much resemble its behaviour.
Rather than being about maintaining limits on on-disk block usage by
particular users, they are instead about maintaining limits on in-memory
page usage (including anonymous MAP_PRIVATE copied-on-write pages)
associated with a particular hugetlbfs filesystem instance.

Worse, they work by having callbacks to the hugetlbfs filesystem code from
the low-level page handling code, in particular from free_huge_page().
This is a layering violation of itself, but more importantly, if the
kernel does a get_user_pages() on hugepages (which can happen from KVM
amongst others), then the free_huge_page() can be delayed until after the
associated inode has already been freed.  If an unmount occurs at the
wrong time, even the hugetlbfs superblock where the "quota" limits are
stored may have been freed.

Andrew Barry proposed a patch to fix this by having hugepages, instead of
storing a pointer to their address_space and reaching the superblock from
there, had the hugepages store pointers directly to the superblock,
bumping the reference count as appropriate to avoid it being freed.
Andrew Morton rejected that version, however, on the grounds that it made
the existing layering violation worse.

This is a reworked version of Andrew's patch, which removes the extra, and
some of the existing, layering violation.  It works by introducing the
concept of a hugepage "subpool" at the lower hugepage mm layer - that is a
finite logical pool of hugepages to allocate from.  hugetlbfs now creates
a subpool for each filesystem instance with a page limit set, and a
pointer to the subpool gets added to each allocated hugepage, instead of
the address_space pointer used now.  The subpool has its own lifetime and
is only freed once all pages in it _and_ all other references to it (i.e.
superblocks) are gone.

subpools are optional - a NULL subpool pointer is taken by the code to
mean that no subpool limits are in effect.

Previous discussion of this bug found in:  "Fix refcounting in hugetlbfs
quota handling.". See:  https://lkml.org/lkml/2011/8/11/28 or
http://marc.info/?l=linux-mm&m=126928970510627&w=1

v2: Fixed a bug spotted by Hillf Danton, and removed the extra parameter to
alloc_huge_page() - since it already takes the vma, it is not necessary.

Signed-off-by: Andrew Barry <abarry@cray.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Cc: Hugh Dickins <hughd@google.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1635]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I63783f5ab9494acdf243cb80a47668ee1933a3d4

hugetlb: fix resv_map leak in error path

Memory leak in mm/hugetlb.c in the Linux kernel before 3.4.2
allows local users to cause a denial of service (memory
consumption or system crash) via invalid MAP_HUGETLB mmap
operations.

Signed-off-by: Dave Hansen <dave@linux.vnet.ibm.com>
Acked-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: Christoph Lameter <cl@linux.com>
Tested-by: Christoph Lameter <cl@linux.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: <stable@vger.kernel.org> [2.6.32+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1642]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I7e1039d435b22261fa68ad5b5da121b2baa62daa

TRATS: fixed compiler errors

Change-Id: I0f8f2a23cc9a13baae30323aca924753d9121722
Signed-off-by: dh09.lee <dh09.lee@samsung.com>

igmp: Avoid zero delay when receiving odd mixture of IGMP queries

Commit 5b7c84066733c5dfb0e4016d939757b38de189e4 ('ipv4: correct IGMP
behavior on v3 query during v2-compatibility mode') added yet another
case for query parsing, which can result in max_delay = 0.  Substitute
a value of 1, as in the usual v3 case.

Reported-by: Simon McVittie <smcv@debian.org>
References: http://bugs.debian.org/654876
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-1625]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I867c7e918c38a1fa52dc82373ef720a8effbf97c

regset: Prevent null pointer reference on readonly regsets

The regset common infrastructure assumed that regsets would always
have .get and .set methods, but not necessarily .active methods.
Unfortunately people have since written regsets without .set methods.

Rather than putting in stub functions everywhere, handle regsets with
null .get or .set methods explicitly.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Roland McGrath <roland@hack.frob.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1627]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I48c4948b8c8f064513c350ca48ab1b9945419852

mm: memcg: Correct unregistring of events attached to the same eventfd

There is an issue when memcg unregisters events that were attached to
the same eventfd:

- On the first call mem_cgroup_usage_unregister_event() removes all
  events attached to a given eventfd, and if there were no events left,
  thresholds->primary would become NULL;

- Since there were several events registered, cgroups core will call
  mem_cgroup_usage_unregister_event() again, but now kernel will oops,
  as the function doesn't expect that threshold->primary may be NULL.

That's a good question whether mem_cgroup_usage_unregister_event()
should actually remove all events in one go, but nowadays it can't
do any better as cftype->unregister_event callback doesn't pass
any private event-associated cookie. So, let's fix the issue by
simply checking for threshold->primary.

FWIW, w/o the patch the following oops may be observed:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004
 IP: [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
 Pid: 574, comm: kworker/0:2 Not tainted 3.3.0-rc4+ #9 Bochs Bochs
 RIP: 0010:[<ffffffff810be32c>]  [<ffffffff810be32c>] mem_cgroup_usage_unregister_event+0x9c/0x1f0
 RSP: 0018:ffff88001d0b9d60  EFLAGS: 00010246
 Process kworker/0:2 (pid: 574, threadinfo ffff88001d0b8000, task ffff88001de91cc0)
 Call Trace:
  [<ffffffff8107092b>] cgroup_event_remove+0x2b/0x60
  [<ffffffff8103db94>] process_one_work+0x174/0x450
  [<ffffffff8103e413>] worker_thread+0x123/0x2d0

Cc: stable <stable@vger.kernel.org>
Signed-off-by: Anton Vorontsov <anton.vorontsov@linaro.org>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Kirill A. Shutemov <kirill@shutemov.name>
Cc: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1628]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I2bbbe2b43478599f373afb5a9fcdd980d16a9e05

ext4: fix undefined behavior in ext4_fill_flex_info()

Commit 503358ae01b70ce6909d19dd01287093f6b6271c ("ext4: avoid divide by
zero when trying to mount a corrupted file system") fixes CVE-2009-4307
by performing a sanity check on s_log_groups_per_flex, since it can be
set to a bogus value by an attacker.

sbi->s_log_groups_per_flex = sbi->s_es->s_log_groups_per_flex;
groups_per_flex = 1 << sbi->s_log_groups_per_flex;

if (groups_per_flex < 2) { ... }

This patch fixes two potential issues in the previous commit.

1) The sanity check might only work on architectures like PowerPC.
On x86, 5 bits are used for the shifting amount.  That means, given a
large s_log_groups_per_flex value like 36, groups_per_flex = 1 << 36
is essentially 1 << 4 = 16, rather than 0.  This will bypass the check,
leaving s_log_groups_per_flex and groups_per_flex inconsistent.

2) The sanity check relies on undefined behavior, i.e., oversized shift.
A standard-confirming C compiler could rewrite the check in unexpected
ways.  Consider the following equivalent form, assuming groups_per_flex
is unsigned for simplicity.

groups_per_flex = 1 << sbi->s_log_groups_per_flex;
if (groups_per_flex == 0 || groups_per_flex == 1) {

We compile the code snippet using Clang 3.0 and GCC 4.6.  Clang will
completely optimize away the check groups_per_flex == 0, leaving the
patched code as vulnerable as the original.  GCC keeps the check, but
there is no guarantee that future versions will do the same.

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
[Patch applied to resolve tizendev.org issue: TDIS-1631]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ib3f81dbcc385e11d999c4d2b3ecc834f5ff3f311

fcaps: clear the same personality flags as suid when fcaps are used

If a process increases permissions using fcaps all of the dangerous
personality flags which are cleared for suid apps should also be cleared.
Thus programs given priviledge with fcaps will continue to have address space
randomization enabled even if the parent tried to disable it to make it
easier to attack.

Signed-off-by: Eric Paris <eparis@redhat.com>
Reviewed-by: Serge Hallyn <serge.hallyn@canonical.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[Patch applied to resolve tizendev.org issue: TDIS-1633]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Icf697a5a7336f310ddcd40a7379af22e7d9872d5

procfs: fix a vfsmount longterm reference leak

kern_mount() doesn't pair with plain mntput()...
fs/proc/root.c in the procfs implementation in the Linux kernel before
3.2 does not properly interact with CLONE_NEWPID clone system calls,
which allows remote attackers to cause a denial of service (reference
leak and memory consumption) by making many connections to a daemon
that uses PID namespaces to isolate clients, as demonstrated by vsftpd."

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[Patch applied to resolve tizendev.org issue: TDIS-1634]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ib98fb053aced04adbb733357d35fa1705b556618

net: sock: validate data_len before allocating skb in sock_alloc_send_pskb()

We need to validate the number of pages consumed by data_len, otherwise frags
array could be overflowed by userspace. So this patch validate data_len and
return -EMSGSIZE when data_len may occupies more frags than MAX_SKB_FRAGS.

Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[Patch applied to resolve tizendev.org issue: TDIS-1636]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I23ff1dd134498bde200ee71b4e4813baf0e5dd4a

hfsplus: Fix potential buffer overflows

Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few
potential buffer overflows in the hfs filesystem.  But as Timo Warns
pointed out, these changes also need to be made on the hfsplus
filesystem as well.

Reported-by: Timo Warns <warns@pre-sense.de>
Acked-by: WANG Cong <amwang@redhat.com>
Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Cc: Sage Weil <sage@newdream.net>
Cc: Eugene Teo <eteo@redhat.com>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Dave Anderson <anderson@redhat.com>
Cc: stable <stable@vger.kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1637]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Idee1fb172e21c9507cad1c02fd86587673bf42a1

Fix length of buffer copied in __nfs4_get_acl_uncached

_copy_from_pages() used to copy data from the temporary buffer to the
user passed buffer is passed the wrong size parameter when copying
data. res.acl_len contains both the bitmap and acl lenghts while
acl_len contains the acl length after adjusting for the bitmap size.

Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[Patch applied to resolve tizendev.org issue: TDIS-1639]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: If7d858f5f7dae389a1ac561271c24af2ede9c432

drm/i915: fix integer overflow in i915_gem_execbuffer2()

On 32-bit systems, a large args->buffer_count from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.

This vulnerability was introduced in commit 8408c282 ("drm/i915:
First try a normal large kmalloc for the temporary exec buffers").

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Patch applied to resolve tizendev.org issue: TDIS-1640]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I5e29c4eb5557b9d30a4ddea260b3eed6c7dc884f

drm/i915: fix integer overflow in i915_gem_do_execbuffer()

On 32-bit systems, a large args->num_cliprects from userspace via ioctl
may overflow the allocation size, leading to out-of-bounds access.

This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
allocation for execbuffer object list").

Signed-off-by: Xi Wang <xi.wang@gmail.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Patch applied to resolve tizendev.org issue: TDIS-1641]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I73b04f9822f77ae1b09d23259a15d660075906c5

cred: copy_process() should clear child->replacement_session_keyring

keyctl_session_to_parent(task) sets ->replacement_session_keyring,
it should be processed and cleared by key_replace_session_keyring().

However, this task can fork before it notices TIF_NOTIFY_RESUME and
the new child gets the bogus ->replacement_session_keyring copied by
dup_task_struct(). This is obviously wrong and, if nothing else, this
leads to put_cred(already_freed_cred).

change copy_creds() to clear this member. If copy_process() fails
before this point the wrong ->replacement_session_keyring doesn't
matter, exit_creds() won't be called.

Cc: <stable@vger.kernel.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Patch applied to resolve tizendev.org issue: TDIS-1643]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: Ifce23ffa7e53d4a0fe43d47f55e43db8c6f8e1d0

NFSv4: include bitmap in nfsv4 get acl data

The NFSv4 bitmap size is unbounded: a server can return an arbitrary
sized bitmap in an FATTR4_WORD0_ACL request.  Replace using the
nfs4_fattr_bitmap_maxsz as a guess to the maximum bitmask returned by a server
with the inclusion of the bitmap (xdr length plus bitmasks) and the acl data
xdr length to the (cached) acl page data.

This is a general solution to commit e5012d1f "NFSv4.1: update
nfs4_fattr_bitmap_maxsz" and fixes hitting a BUG_ON in xdr_shrink_bufhead
when getting ACLs.

Fix a bug in decode_getacl that returned -EINVAL on ACLs > page when getxattr
was called with a NULL buffer, preventing ACL > PAGE_SIZE from being retrieved.

Cc: stable@kernel.org
Signed-off-by: Andy Adamson <andros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
[Patch applied to resolve tizendev.org issue: TDIS-1679]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I6928de41fef6e1892a8b300f08571b67aca8015c

jbd2: clear BH_Delay & BH_Unwritten in journal_unmap_buffer

journal_unmap_buffer()'s zap_buffer: code clears a lot of buffer head
state ala discard_buffer(), but does not touch _Delay or _Unwritten as
discard_buffer() does.

This can be problematic in some areas of the ext4 code which assume
that if they have found a buffer marked unwritten or delay, then it's
a live one.  Perhaps those spots should check whether it is mapped
as well, but if jbd2 is going to tear down a buffer, let's really
tear it down completely.

Without this I get some fsx failures on sub-page-block filesystems
up until v3.2, at which point 4e96b2dbbf1d7e81f22047a50f862555a6cb87cb
and 189e868fa8fdca702eb9db9d8afc46b5cb9144c9 make the failures go
away, because buried within that large change is some more flag
clearing.  I still think it's worth doing in jbd2, since
->invalidatepage leads here directly, and it's the right place
to clear away these flags.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: stable@vger.kernel.org
[Patch applied to resolve tizendev.org issue: TDIS-1621]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I311e1245249f5205284dca49b17a0b9606a23310

udf: Fortify loading of sparing table

Add sanity checks when loading sparing table from disk to avoid accessing
unallocated memory or writing to it.

Signed-off-by: Jan Kara <jack@suse.cz>
[Patch applied to resolve tizendev.org issue: TDIS-1588]
Signed-off-by: dh09.lee <dh09.lee@samsung.com>
Change-Id: I0e4412d74ca807a6cea2536b2057df71bc6cb7c1

TRATS: manually merge the latest 3.0-kernel

Synchronize the latest 3.0-kernel

Main change:
SLP: Camera: Enable Camera Flash for Trats
SLP: HDMI: Added power down state check routine for depence panic.
SLP: HDMI: Added audio control feature in hdmi
...

Change-Id: I7424ba9de695f9c353c3f4bbc65a9dde5e1c7df8
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

TRATS: haptic is enabled instead of haptic motor

Use the haptic instead of haptic motor.
(revert the haptic motor is enabled)

Change-Id: I263910edef17d7f2457f82809a6d835de2256f3d
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>

drm/exynos: fix x, y coordinates for right bottom pixel

The x, y coordinates of right bottom pixel cannot be negative numbers.

Change-Id: I898ada0036773d5b431db6c2ad21fbdd2dbbdce1
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

drm/exynos: fix fb offset calculation for plane

There is no any reason to change fb offset when CRTC is out of screen.
Also, this fixes a typing error.

Change-Id: Idcf65ffc1323afce385c16b54f8602a7549384d9
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

tmpfs: security xattr setting on inode creation

commit 6d9d88d07e132259c35f9493b15429e19198489c upstream

Adds to generic xattr support introduced in Linux 3.0 by implementing
initxattrs callback.  This enables consulting of security attributes from
LSM and EVM when inode is created.

[hughd@google.com: moved under CONFIG_TMPFS_XATTR, with memcpy in shmem_xattr_alloc]
Change-Id: I9d44b4aadbf4c673843b998ddfc149518adc93c1
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@intel.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

CIFS: remove local xattr definitions

commit f995e74087402c482c55c29bf11da8bcf631245a upstream

Local XATTR_TRUSTED_PREFIX_LEN and XATTR_SECURITY_PREFIX_LEN definitions
redefined ones in 'linux/xattr.h'. This was caused by commit 9d8f13ba3f48
("security: new security_inode_init_security API adds function callback")
including 'linux/xattr.h' in 'linux/security.h'.

In file included from include/linux/security.h:39,
                 from include/net/sock.h:54,
                 from fs/cifs/cifspdu.h:25,
                 from fs/cifs/xattr.c:26:

This patch removes the local definitions.

Change-Id: I924d7506cc15a0db0a2a6daafe4604f4b3a285f0
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

security: new security_inode_init_security API adds function callback

commit 9d8f13ba3f4833219e50767b022b82cd0da930eb upstream

This patch changes the security_inode_init_security API by adding a
filesystem specific callback to write security extended attributes.
This change is in preparation for supporting the initialization of
multiple LSM xattrs and the EVM xattr.  Initially the callback function
walks an array of xattrs, writing each xattr separately, but could be
optimized to write multiple xattrs at once.

For existing security_inode_init_security() calls, which have not yet
been converted to use the new callback function, such as those in
reiserfs and ocfs2, this patch defines security_old_inode_init_security().

Change-Id: I79cf7085808303580dcb5aba4bea323b35f7f0bd
Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
Signed-off-by: Rafal Krypa <r.krypa@samsung.com>

trats/trats2: fix modem configs to use AT mode

Change-Id: Ief4a852e26ab044079a932e4ecb964b23c862b13
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

modem: add xmm6262 modem control driver for tizen

Change-Id: I0219f381b9826f2fcda8e2abdff6d50bf70622f5
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>

USB/EHCI-S5P: Section mismatch removed

s5p_ehci_cpu_notifier cannot be _initdata because the data is used by
the remove function.

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Change-Id: Ib59ee51164f5ecb6d109751d1fa601852a134339

Linux 3.0.15 with TRATS/TRATS2 BSP and bugfixes

This is a squahed commit of the following commits, which
- update from the main branches
- remove codes not related with TRATS/TRATS2

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
----------------------------------------------------------------------------
Initial commit (2012-09-08)

Change-Id: I614d63154fb82e6095094fa45a1bf271775901ad
Signed-off-by: Dongsu Kim <dongsu17.kim@samsung.com>
----------------------------------------------------------------------------
Update source (2012-10-24)

Change-Id: Ie12f784c4e57744444db3652527243e6d74f86d0
Signed-off-by: Dongsu Kim <dongsu17.kim@samsung.com>
----------------------------------------------------------------------------
Manually merge the 3.0-kernel (2012-11-09)

In order to sync the latest 3.0-kernel, manually merge.

1) remove unused features.
2) remove the unused the config file.
3) remove the Wacom feature
4) remove the drm/exynos_tmp folder
5) remove the ktgrabber feature
6) Use the trats2 instead of m0
7) remove the unnecessary board/header file
8) remove NAPLES mipi dsi driver codes
9) remove machine dependent code of NAPLES
10) remove machine dependent codes of Px series
11) remove machine dependent codes of Q1
12) remove machine dependent codes of T0
13) remove m3 gpio configuration.
14) remove machine dependent codes of MIDAS
15) remove dynamic hotplug and custom cpufreq govs.
16) change file name from gpio-u1.h to gpio-trats1.h

Change-Id: I958af60395821f57f21483f727f7b32af1c5c6c8
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: leedonghwa <dh09.lee@samsung.com>
Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
----------------------------------------------------------------------------
fs: remove j4fs filesystem

This patch remove the j4fs filesystem. We don't need this file system anymore.

Change-Id: I869633cdda81529c5b77ed490f1cc5c86deb8338
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
----------------------------------------------------------------------------
driver: staging: remove ath6kl driver

This patch removes ath6kl staging driver that we don't need it anymore.

Change-Id: Ie91d90547dfea1f143c14f50aa2f825c4af9bb0f
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
----------------------------------------------------------------------------
media: video: remove unused mali driver

This patch removes vithar driver and mali_r2p3 driver. We don't use it anymore.
We only use mali_r3p0 driver.

Change-Id: I2dd1758825bb2c3574f5ef6fedbc438c6cb6f105
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
----------------------------------------------------------------------------
media: mali: GPL-ize some codes stating that they are proprietary

Change-Id: I7c057580261b3d127e828ec0a96aadbb06fe7e22
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
----------------------------------------------------------------------------
media: mali: remove mali_r2p3 directory in Makefile

This patch removes including directives mali_r2p3 directory from Makefile.
In previous patch(commit ace9b9b), I missed it when removed mali_r2p3.

Change-Id: I235fd3a25105dca28fd60a175eddf5e5a934357f
Signed-off-by: Chanho Park <chanho61.park@samsung.com>

Initial empty repository