drivers: Squash update vt.c for linux 3.0.67
Linux 3.0.68
display: CPUFreq LCDFreq capability & state accounting
kernel: power: prevent DVFS_LOCK_ID_USER lock for min and max frequency levels
kernel: power: allow removing of DVFS_LOCK_ID_USER and setting max freq limit only
Linux 3.0.69
Linux 3.0.70
Linux 3.0.71
Makefile: Add LDFLAGS_MODULE = --strip-debug
Fix derp - missing random.h
hashtable: introduce a small and naive hashtable This hashtable implementation is using hlist buckets to provide a simple hashtable to prevent it from getting reimplemented all over the kernel.

Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
[ Merging this now, so that subsystems can start applying Sasha's
  patches that use this   - Linus ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
block,elevator: use new hashtable implementation Switch elevator to use the new hashtable implementation. This reduces the amount of generic unrelated code in the elevator.

This also removes the dymanic allocation of the hash table. The size of the table is
constant so there's no point in paying the price of an extra dereference when accessing
it.

This patch depends on d9b482c ("hashtable: introduce a small and naive
hashtable") which was merged in v3.6.

Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Staging: android: binder: Fix memory leak on thread/process exit If a thread or process exited while a reply, one-way transaction or death notification was pending, the struct holding the pending work was leaked.

Change-Id: I2eaafaba1c0ecda3ec0872d449dc16d0721c21e7
Signed-off-by: Arve Hjønnevåg <arve@android.com>
usb-gadget: Booting from g_file_storage in cdrom mode

The g_file_storage gets upset by some non-zero bytes in the end of a
READ TOC command.

<7>00000000: 55 53 42 43 42 49 4f 53 0c 00 00 00 80 00 0a 43
<7>00000010: 00 00 00 00 00 00 00 0c 40 00 00 00 00 00 00
<7>g_file_storage gadget: SCSI command: READ TOC;  Dc=10, Di=12;  Hc=10, Hi=12
<7>g_file_storage gadget: bulk-in, length 12:
<7>00000000: 00 00 00 00 00 00 00 00 00 00 00 00
<7>g_file_storage gadget: sending command-failure status
<7>g_file_storage gadget:   sense data: SK x05, ASC x24, ASCQ x00;  info x0
<7>g_file_storage gadget: bulk-in, length 13:
<7>00000000: 55 53 42 53 42 49 4f 53 0c 00 00 00 01

And then a sector size of 2048 (instead of 512) as usual for cdrom
drives is assumed. The following should read the el torito info block,
but the BIOS gets the wrong data due to the wrong sector size (offsets
are wrong).

<7>g_file_storage gadget: bulk-out, length 31:
<7>00000000: 55 53 42 43 42 49 4f 53 00 08 00 00 80 00 0c 28
<7>00000010: 00 00 00 00 11 00 00 01 00 00 00 00 00 00 00
<7>SCSI CDB: 28 00 00 00 00 11 00 00 01 00 00 00
<7>g_file_storage gadget: SCSI command: READ(10);  Dc=10, Di=512;  Hc=12, Hi=2048
<7>g_file_storage gadget: READ(10) is buggy! Expected length 10 but we got 12
<7>g_file_storage gadget-lun0: file read 512 @ 8704 -> 512
<7>g_file_storage gadget: bulk-in, length 13:
<7>00000000: 55 53 42 53 42 49 4f 53 00 06 00 00 00

The following patch solves the problem for the BIOS. I am able to load
a kernel and an initrd with it correctly. Of course, it breaks everything
else but it can be considered as a proof of concept. I can boot from my
my g_file_storage cdrom drive with it on that thinkpad X31, on a mainboard with award
bios (with an AMD Geode 1700+ on it) and also on an INTEL D945GCLF board.
rwsem: steal writing sem for better performance

Commit 5a50508 changes to rwsem from mutex, caused aim7 fork_test
performance to dropped 50%. Yuanhan liu did an analysis, found it was
caused by strict sequential writing. Ingo suggest stealing sem writing from
front task in wait queue. https://lkml.org/lkml/2013/1/29/84

So does this patch.
In this patch, I just allow write stealing to happen when the first waiter
is also writer. The performance fully is now fully recovered.

Reported-by: lkp@linux.intel.com
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Alex Shi <alex.shi@intel.com>
Dynamic read-ahead
staging: android: Reduce logger RAM usage
modem: reduce wakelocks in modem drivers from 100 to 50
Allow CPU Based Alignment Handling
ext4: prevent kernel panic in case of uninitialized jinode

ext4: prevent kernel panic in case of uninitialized jinode

In some cases the kernel crash occurs during system suspend/resume:

[ 4095.041351] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 4095.050689] pgd = c0004000
[ 4095.053985] [00000000] *pgd=00000000
[ 4095.058807] Internal error: Oops: 5 [#1] PREEMPT SMP
[ 4095.064483] Modules linked in: wl12xx mac80211 pvrsrvkm_sgx540_120 cfg80211 compat [last unloaded: wl12xx_sdio]
[ 4095.064575] CPU: 1    Tainted: G    B        (3.0.31-01807-gfac16a0 #1)
[ 4095.064605] PC is at jbd2_journal_file_inode+0x38/0x118
[ 4095.064666] LR is at mpage_da_map_and_submit+0x48c/0x618
[ 4095.064697] pc : [<c01da5a8>]    lr : [<c01aeac0>]    psr: 60000013
[ 4095.064697] sp : c6e07c80  ip : c6e07ca0  fp : c6e07c9c
[ 4095.064727] r10: 00000001  r9 : c6e06000  r8 : 00000179
[ 4095.064758] r7 : c6e07ca0  r6 : c73b8400  r5 : 00000000  r4 : c59a7d80
[ 4095.064758] r3 : 00000038  r2 : 00000800  r1 : 00000000  r0 : c7754fc0
[ 4095.064788] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[ 4095.064819] Control: 10c5387d  Table: 86cc804a  DAC: 00000015
[ 4095.064849]
[ 4095.064849] PC: 0xc01da528:
[ 4095.064880] a528  0a000003 e3a05000 e1a00005 e24bd020 e89da9f0 e5951010 e3e06000 e14b22dc
.....
[ 4095.070373] 7fe0: c00a48ac 00000013 00000000 c6e07ff8 c00a48ac c00c0a94 84752f09 60772177
[ 4095.070404] Backtrace:
[ 4095.070465] [<c01da570>] (jbd2_journal_file_inode+0x0/0x118) from [<c01aeac0>] (mpage_da_map_and_submit+0x48c/0x618)
[ 4095.070495]  r7:c6e07ca0 r6:c6e07d00 r5:c6e07d90 r4:c7754fc0
[ 4095.070556] [<c01ae634>] (mpage_da_map_and_submit+0x0/0x618) from [<c01af40c>] (ext4_da_writepages+0x2a4/0x5c8)
[ 4095.070617] [<c01af168>] (ext4_da_writepages+0x0/0x5c8) from [<c0112af4>] (do_writepages+0x34/0x40)
[ 4095.070678] [<c0112ac0>] (do_writepages+0x0/0x40) from [<c01645a4>] (writeback_single_inode+0xd4/0x288)
[ 4095.070709] [<c01644d0>] (writeback_single_inode+0x0/0x288) from [<c0164ed4>] (writeback_sb_inodes+0xb4/0x184)
[ 4095.070770] [<c0164e20>] (writeback_sb_inodes+0x0/0x184) from [<c01655a0>] (writeback_inodes_wb+0xc4/0x13c)
[ 4095.070831] [<c01654dc>] (writeback_inodes_wb+0x0/0x13c) from [<c01658f0>] (wb_writeback+0x2d8/0x464)
[ 4095.070861] [<c0165618>] (wb_writeback+0x0/0x464) from [<c0165cb8>] (wb_do_writeback+0x23c/0x2c4)
[ 4095.070922] [<c0165a7c>] (wb_do_writeback+0x0/0x2c4) from [<c0165df4>] (bdi_writeback_thread+0xb4/0x2dc)
[ 4095.070953] [<c0165d40>] (bdi_writeback_thread+0x0/0x2dc) from [<c00c0b18>] (kthread+0x90/0x98)
[ 4095.071014] [<c00c0a88>] (kthread+0x0/0x98) from [<c00a48ac>] (do_exit+0x0/0x72c)
[ 4095.071044]  r7:00000013 r6:c00a48ac r5:c00c0a88 r4:c78c7ec4
[ 4095.071105] Code: e89da8f0 e5963000 e3130002 1afffffa (e5913000)
[ 4095.071166] ---[ end trace 7fe9f9b727e5cf78 ]---
[ 4095.071197] Kernel panic - not syncing: Fatal exception

The probably reason of such behaviour is an inode opened in READ mode
has been marked as 'dirty' somehow and written back by ext4_da_writepages.
Cause jinode == NULL it could lead to the kernel panic.

The patch prevents kernel panic and helps to investigate the problem
providing an inode number.

Change-Id: I1d77a011b580db682b8e2d122ef3d5e44e0ce5c7
Signed-off-by: Volodymyr Mieshkov <volodymyr.mieshkov@ti.com>