GitHub PushEvent at 2014-04-16 03:44:35
Repository: android_kernel_motorola_omap4-common
Actor: nx111
Payload: {"shas":[["59c4d9eb07ac871ca813aae1bb6af9e93e08cb89","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","Revert \"sched: better settings\"\n\nThis reverts commit c2e5370776e67f93da0761cfd261254b8296fb8b.","dtrail",true],["0a4f10ca864658a1411148d63cb4b4e9c07c4134","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","kernel: sched_features: use standard settings with ARCH power","dtrail",true],["9591c6a0d6fdeb77e062f071087e70f14a399ac2","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","omap: cpuidle: reconfigure idle params","dtrail",true],["341e3377d44df705a3152f4d28309788bd4fc676","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","defconfig: enable SCHED_SMT again","dtrail",true],["87afbb7e1bab2fa6f7a8f75ea79482c4eacf758e","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","omap: some corrections, small fixes, etc..","dtrail",true],["e464a4f0d6f6c6b9740f555013743f74e7425b1d","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","cpufreq: copy policy to sibling cpu on resume","dtrail",true],["c20ab6c6ff04a22b0454d051dbcb6070f67d005f","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","lmk: re-enable async memory compaction","dtrail",true],["39b0460fb867e5a8d18c4ba4fef24853bd6f36a2","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","staging: lowmemorykiller: backport patches from Codeaurora 3.4","dtrail",true],["f40de4ea0eaf229bb77ba00730d5cbb12bbc4826","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm: use aligned zone start for pfn_to_bitidx calculation\n\nThe current calculation in pfn_to_bitidx assumes that (pfn -\nzone->zone_start_pfn) >> pageblock_order will return the same bit for\nall pfn in a pageblock.  If zone_start_pfn is not aligned to\npageblock_nr_pages, this may not always be correct.\n\nConsider the following with pageblock order = 10, zone start 2MB:\n\n  pfn     | pfn - zone start | (pfn - zone start) >> page block order\n  ----------------------------------------------------------------\n  0x26000 | 0x25e00   |  0x97\n  0x26100 | 0x25f00   |  0x97\n  0x26200 | 0x26000   |  0x98\n  0x26300 | 0x26100   |  0x98\n\nThis means that calling {get,set}_pageblock_migratetype on a single page\nwill not set the migratetype for the full block.  Fix this by rounding\ndown zone_start_pfn when doing the bitidx calculation.\n\nFor our use case, the effects of this bug were mostly tied to the fact\nthat CMA allocations would either take a long time or fail to happen.\nDepending on the driver using CMA, this could result in anything from\nvisual glitches to application failures.","dtrail",true],["75154ad18bc33f87165e8ebf93369ff1ae7ef884","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","ARM: mm: use pteval_t to represent page protection values\n\nWhen updating the page protection map after calculating the user_pgprot\nvalue, the base protection map is temporarily stored in an unsigned long\ntype, causing truncation of the protection bits when LPAE is enabled.\nThis effectively means that calls to mprotect() will corrupt the upper\npage attributes, clearing the XN bit unconditionally.\n\nThis patch uses pteval_t to store the intermediate protection values,\npreserving the upper bits for 64-bit descriptors.","dtrail",true],["2646d9515f3365bc0f841a167b629fc6c92c52f5","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","ARM: missing ->mmap_sem around find_vma() in swp_emulate.c\n\nfind_vma() is *not* safe when somebody else is removing vmas.  Not just\nthe return value might get bogus just as you are getting it (this instance\ndoesn't try to dereference the resulting vma), the search itself can get\nbuggered in rather spectacular ways.  IOW, ->mmap_sem really, really is\nnot optional here.","dtrail",true],["95879de3d50836677e0f21bb4350579a8be79c8f","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm: Fix PageHead when [NOT]CONFIG_PAGEFLAGS_EXTENDED #\n\n(PageHead) is true, for tail pages.  If this is indeed the intended\nbehavior, which I doubt because it breaks cache cleaning on some ARM\nsystems, then the nomenclature is highly problematic.\n\nThis patch makes sure PageHead is only true for head pages and PageTail\nis only true for tail pages, and neither is true for non-compound pages.\n\n[ This buglet seems ancient - seems to have been introduced back in Apr\n  2008 in commit 6a1e7f7: 'pageflags: convert to the use of new macros'.  And the reason nobody noticed is because the PageHead() tests are almost all about just sanity-checking, and only used on\n  pages that are actual page heads.  The fact that the old code returned\n  true for tail pages too was thus not really noticeable.   - Linus ]","dtrail",true],["875385ee4304801b40745adf2faeeb95ac8daffb","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls\n\ndmapool always calls dma_alloc_coherent() with GFP_ATOMIC flag,\nregardless the flags provided by the caller. This causes excessive\npruning of emergency memory pools without any good reason. Additionaly,\non ARM architecture any driver which is using dmapools will sooner or\nlater  trigger the following error:\n'ERROR: 256 KiB atomic DMA coherent pool is too small! Please increase it with coherent_pool= kernel parameter!'. Increasing the coherent pool size usually doesn't help much and only delays such error, because all GFP_ATOMIC DMA allocations are always served from the special, very limited memory pool.\n\nThis patch changes the dmapool code to correctly use gfp flags provided\nby the dmapool caller.","dtrail",true],["0818be42976e0707ca64c817015ae070e43f08ab","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm/vmemmap: fix wrong use of virt_to_page","dtrail",true],["45d1b9d7b443a80b28c3a628a328d5ff7b329d38","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm: soft offline: split thp at the beginning of soft_offline_page()\n\nWhen we try to soft-offline a thp tail page, put_page() is called on the\ntail page unthinkingly and VM_BUG_ON is triggered in put_compound_page().\n\nThis patch splits thp before going into the main body of soft-offlining.","dtrail",true],["83a4d8c1927f3e6a0e8579cec68449abb0e44c95","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm: bugfix: set current->reclaim_state to NULL while returning from kswapd()\n\nIn kswapd(), set current->reclaim_state to NULL before returning, as\ncurrent->reclaim_state holds reference to variable on kswapd()'s stack.\n\nIn rare cases, while returning from kswapd() during memory offlining,\n__free_slab() and freepages() can access the dangling pointer of\ncurrent->reclaim_state.","dtrail",true],["885d42d0dfbe5334038efd4ef790828683519456","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","mm: compaction: fix echo 1 > compact_memory return error issue\n\nThis tells system return 3(COMPACT_COMPLETE) after write data to\ncompact_memory.\n\nThe fix is to make the system just return 0 instead 3(COMPACT_COMPLETE)\nfrom sysctl_compaction_handler after compaction_nodes finished.","dtrail",true],["03afafd3d32096f61d59de43e6b2ad46f9c1c7d2","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","ext4: do not try to write superblock on ro remount w/o journal\n\nWhen a journal-less ext4 filesystem is mounted on a read-only block\ndevice (blockdev --setro will do), each remount (for other, unrelated,\nflags, like suid=>nosuid etc) results in a series of scary messages\nfrom kernel telling about I/O errors on the device.\n\nThis is becauese of the following code ext4_remount():\n\n       if (sbi->s_journal == NULL)\n                ext4_commit_super(sb, 1);\n\nat the end of remount procedure, which forces writing (flushing) of\na superblock regardless whenever it is dirty or not, if the filesystem\nis readonly or not, and whenever the device itself is readonly or not.\n\nWe only need call ext4_commit_super when the file system had been\npreviously mounted read/write.\n\nThanks to Eric Sandeen for help in diagnosing this issue.","dtrail",true],["28ffcabd0418bcef00a4fb5d089bb062e8c30584","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","regulator: Correct voltage value used in regulator_set_voltage_complete\n\nThe voltage value specified in the tracepoint function\ntrace_regulator_set_voltage_complete() inside of the function\n_regulator_do_set_voltage() is erroneously set to -1 if a\nlist_voltage() callback is not specified by a regulator device\neven if a get_voltage() callback is present.\n\nAdd a check for the get_voltage() callback function and call it\nin order to determine the voltage that was chosen from the min_uV\nto max_uV range.","dtrail",true],["42d0f7492dc3699870b98c55fad759842ee0bc48","85d8de42040fe3241ad88ac6b1c543b888c625df@gmail.com","Staging: android: binder: Don't call dump_stack in binder_vma_open\n\nIf user-space partially unmaps the driver, binder_vma_open\nwould dump the kernel stack. This is not a kernel bug however\nand will be treated as if the whole area was unmapped once\nbinder_vma_close gets called.","dtrail",true]],"size":52,"ref":"refs/heads/JBX_30X","head":"9ca4b73a232b198300235aa671ef9336e5d86b8e"}