{"push_id":542946790,"size":80,"distinct_size":80,"ref":"refs/heads/lollipop","head":"9ae6909bf7fbbbdcf523a2ef33af1dfe42b67f1f","before":"1ceeb453c503ea2c16258a3b6e64060f5fb9053a","commits":[{"sha":"8da3caa4e27190d7a2878c9e5f3a99478324424f","author":{"email":"d6e1285e1c84d3d5885c2124fdacc780e9fc0a94@tycho.nsa.gov","name":"Stephen Smalley"},"message":"selinux: fix inode security list corruption\n\ncommit 923190d32de4428afbea5e5773be86bea60a9925 upstream.\n\nsb_finish_set_opts() can race with inode_free_security()\nwhen initializing inode security structures for inodes\ncreated prior to initial policy load or by the filesystem\nduring ->mount().   This appears to have always been\na possible race, but commit 3dc91d4 (\"SELinux:  Fix possible\nNULL pointer dereference in selinux_inode_permission()\")\nmade it more evident by immediately reusing the unioned\nlist/rcu element  of the inode security structure for call_rcu()\nupon an inode_free_security().  But the underlying issue\nwas already present before that commit as a possible use-after-free\nof isec.\n\nShivnandan Kumar reported the list corruption and proposed\na patch to split the list and rcu elements out of the union\nas separate fields of the inode_security_struct so that setting\nthe rcu element would not affect the list element.  However,\nthis would merely hide the issue and not truly fix the code.\n\nThis patch instead moves up the deletion of the list entry\nprior to dropping the sbsec->isec_lock initially.  Then,\nif the inode is dropped subsequently, there will be no further\nreferences to the isec.\n\nReported-by: Shivnandan Kumar <shivnandan.k@samsung.com>\nSigned-off-by: Stephen Smalley <sds@tycho.nsa.gov>\nSigned-off-by: Paul Moore <pmoore@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/8da3caa4e27190d7a2878c9e5f3a99478324424f"},{"sha":"dddebb1a8c0ce15551528d6faffc420abd87427b","author":{"email":"255103e50249e3d658441816e0597170ebfc16ef@redhat.com","name":"Michael S. Tsirkin"},"message":"virtio_pci: fix virtio spec compliance on restore\n\ncommit 6fbc198cf623944ab60a1db6d306a4d55cdd820d upstream.\n\nOn restore, virtio pci does the following:\n+ set features\n+ init vqs etc - device can be used at this point!\n+ set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits\n\nThis is in violation of the virtio spec, which\nrequires the following order:\n- ACKNOWLEDGE\n- DRIVER\n- init vqs\n- DRIVER_OK\n\nThis behaviour will break with hypervisors that assume spec compliant\nbehaviour.  It seems like a good idea to have this patch applied to\nstable branches to reduce the support butden for the hypervisors.\n\nCc: Amit Shah <amit.shah@redhat.com>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Rusty Russell <rusty@rustcorp.com.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/dddebb1a8c0ce15551528d6faffc420abd87427b"},{"sha":"ed0cb4c20794badb4a7336929c5370d1010b974c","author":{"email":"61d5fad70554ae22d57a37634e04f12f58acc678@redhat.com","name":"Joe Thornber"},"message":"dm bufio: update last_accessed when relinking a buffer\n\ncommit eb76faf53b1ff7a77ce3f78cc98ad392ac70c2a0 upstream.\n\nThe 'last_accessed' member of the dm_buffer structure was only set when\nthe the buffer was created.  This led to each buffer being discarded\nafter dm_bufio_max_age time even if it was used recently.  In practice\nthis resulted in all thinp metadata being evicted soon after being read\n-- this is particularly problematic for metadata intensive workloads\nlike multithreaded small random IO.\n\n'last_accessed' is now updated each time the buffer is moved to the head\nof the LRU list, so the buffer is now properly discarded if it was not\nused in dm_bufio_max_age time.\n\nSigned-off-by: Joe Thornber <ejt@redhat.com>\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/ed0cb4c20794badb4a7336929c5370d1010b974c"},{"sha":"0cb86947f2f7515a98557f5c788520a75e8e6130","author":{"email":"4c9eb49378914b743bdd32292c04df29b820d73e@cn.fujitsu.com","name":"Lai Jiangshan"},"message":"drbd: compute the end before rb_insert_augmented()\n\ncommit 82cfb90bc99d7b7e0ec62d0505b9d4f06805d5db upstream.\n\nCommit 98683650 \"Merge branch 'drbd-8.4_ed6' into\nfor-3.8-drivers-drbd-8.4_ed6\" switches to the new augment API, but the\nnew API requires that the tree is augmented before rb_insert_augmented()\nis called, which is missing.\n\nSo we add the augment-code to drbd_insert_interval() when it travels the\ntree up to down before rb_insert_augmented().  See the example in\ninclude/linux/interval_tree_generic.h or Documentation/rbtree.txt.\n\ndrbd_insert_interval() may cancel the insertion when traveling, in this\ncase, the just added augment-code does nothing before cancel since the\n@this node is already in the subtrees in this case.\n\nCC: Michel Lespinasse <walken@google.com>\nSigned-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>\nSigned-off-by: Andreas Gruenbacher <agruen@linbit.com>\nSigned-off-by: Philipp Reisner <philipp.reisner@linbit.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/0cb86947f2f7515a98557f5c788520a75e8e6130"},{"sha":"20cdc087d41cabedecb5436625f976374c68155d","author":{"email":"85e533f2e78486213c4d69f71462342ec0c62734@redhat.com","name":"Mike Snitzer"},"message":"block: fix alignment_offset math that assumes io_min is a power-of-2\n\ncommit b8839b8c55f3fdd60dc36abcda7e0266aff7985c upstream.\n\nThe math in both blk_stack_limits() and queue_limit_alignment_offset()\nassume that a block device's io_min (aka minimum_io_size) is always a\npower-of-2.  Fix the math such that it works for non-power-of-2 io_min.\n\nThis issue (of alignment_offset != 0) became apparent when testing\ndm-thinp with a thinp blocksize that matches a RAID6 stripesize of\n1280K.  Commit fdfb4c8c1 (\"dm thin: set minimum_io_size to pool's data\nblock size\") unlocked the potential for alignment_offset != 0 due to\nthe dm-thin-pool's io_min possibly being a non-power-of-2.\n\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nAcked-by: Martin K. Petersen <martin.petersen@oracle.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/20cdc087d41cabedecb5436625f976374c68155d"},{"sha":"827e03528f47860768db1ddad50983da10302cbb","author":{"email":"a9985f635ca4eb5d7c64df6d16c76aa9811509c5@ispras.ru","name":"Alexey Khoroshilov"},"message":"dm log userspace: fix memory leak in dm_ulog_tfr_init failure path\n\ncommit 56ec16cb1e1ce46354de8511eef962a417c32c92 upstream.\n\nIf cn_add_callback() fails in dm_ulog_tfr_init(), it does not\ndeallocate prealloced memory but calls cn_del_callback().\n\nFound by Linux Driver Verification project (linuxtesting.org).\n\nSigned-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>\nReviewed-by: Jonathan Brassow <jbrassow@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/827e03528f47860768db1ddad50983da10302cbb"},{"sha":"72f509c6b5bd4958b9d8fa9741d6f5568006f2f5","author":{"email":"fe4655370dc87a32329d591d6e8472329333dfad@redhat.com","name":"Prarit Bhargava"},"message":"modules, lock around setting of MODULE_STATE_UNFORMED\n\ncommit d3051b489aa81ca9ba62af366149ef42b8dae97c upstream.\n\nA panic was seen in the following sitation.\n\nThere are two threads running on the system. The first thread is a system\nmonitoring thread that is reading /proc/modules. The second thread is\nloading and unloading a module (in this example I'm using my simple\ndummy-module.ko).  Note, in the \"real world\" this occurred with the qlogic\ndriver module.\n\nWhen doing this, the following panic occurred:\n\n ------------[ cut here ]------------\n kernel BUG at kernel/module.c:3739!\n invalid opcode: 0000 [#1] SMP\n Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module]\n CPU: 37 PID: 186343 Comm: cat Tainted: GF          O--------------   3.10.0+ #7\n Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013\n task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000\n RIP: 0010:[<ffffffff810d64c5>]  [<ffffffff810d64c5>] module_flags+0xb5/0xc0\n RSP: 0018:ffff88080fa7fe18  EFLAGS: 00010246\n RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000\n RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000\n RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000\n R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000\n R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000\n FS:  00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n Stack:\n  ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c\n  ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00\n  ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0\n Call Trace:\n  [<ffffffff810d666c>] m_show+0x19c/0x1e0\n  [<ffffffff811e4d7e>] seq_read+0x16e/0x3b0\n  [<ffffffff812281ed>] proc_reg_read+0x3d/0x80\n  [<ffffffff811c0f2c>] vfs_read+0x9c/0x170\n  [<ffffffff811c1a58>] SyS_read+0x58/0xb0\n  [<ffffffff81605829>] system_call_fastpath+0x16/0x1b\n Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41\n RIP  [<ffffffff810d64c5>] module_flags+0xb5/0xc0\n  RSP <ffff88080fa7fe18>\n\n    Consider the two processes running on the system.\n\n    CPU 0 (/proc/modules reader)\n    CPU 1 (loading/unloading module)\n\n    CPU 0 opens /proc/modules, and starts displaying data for each module by\n    traversing the modules list via fs/seq_file.c:seq_open() and\n    fs/seq_file.c:seq_read().  For each module in the modules list, seq_read\n    does\n\n            op->start()  <-- this is a pointer to m_start()\n            op->show()   <- this is a pointer to m_show()\n            op->stop()   <-- this is a pointer to m_stop()\n\n    The m_start(), m_show(), and m_stop() module functions are defined in\n    kernel/module.c. The m_start() and m_stop() functions acquire and release\n    the module_mutex respectively.\n\n    ie) When reading /proc/modules, the module_mutex is acquired and released\n    for each module.\n\n    m_show() is called with the module_mutex held.  It accesses the module\n    struct data and attempts to write out module data.  It is in this code\n    path that the above BUG_ON() warning is encountered, specifically m_show()\n    calls\n\n    static char *module_flags(struct module *mod, char *buf)\n    {\n            int bx = 0;\n\n            BUG_ON(mod->state == MODULE_STATE_UNFORMED);\n    ...\n\n    The other thread, CPU 1, in unloading the module calls the syscall\n    delete_module() defined in kernel/module.c.  The module_mutex is acquired\n    for a short time, and then released.  free_module() is called without the\n    module_mutex.  free_module() then sets mod->state = MODULE_STATE_UNFORMED,\n    also without the module_mutex.  Some additional code is called and then the\n    module_mutex is reacquired to remove the module from the modules list:\n\n        /* Now we can delete it from the lists */\n        mutex_lock(&module_mutex);\n        stop_machine(__unlink_module, mod, NULL);\n        mutex_unlock(&module_mutex);\n\nThis is the sequence of events that leads to the panic.\n\nCPU 1 is removing dummy_module via delete_module().  It acquires the\nmodule_mutex, and then releases it.  CPU 1 has NOT set dummy_module->state to\nMODULE_STATE_UNFORMED yet.\n\nCPU 0, which is reading the /proc/modules, acquires the module_mutex and\nacquires a pointer to the dummy_module which is still in the modules list.\nCPU 0 calls m_show for dummy_module.  The check in m_show() for\nMODULE_STATE_UNFORMED passed for dummy_module even though it is being\ntorn down.\n\nMeanwhile CPU 1, which has been continuing to remove dummy_module without\nholding the module_mutex, now calls free_module() and sets\ndummy_module->state to MODULE_STATE_UNFORMED.\n\nCPU 0 now calls module_flags() with dummy_module and ...\n\nstatic char *module_flags(struct module *mod, char *buf)\n{\n        int bx = 0;\n\n        BUG_ON(mod->state == MODULE_STATE_UNFORMED);\n\nand BOOM.\n\nAcquire and release the module_mutex lock around the setting of\nMODULE_STATE_UNFORMED in the teardown path, which should resolve the\nproblem.\n\nTesting: In the unpatched kernel I can panic the system within 1 minute by\ndoing\n\nwhile (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done\n\nand\n\nwhile (true) do cat /proc/modules; done\n\nin separate terminals.\n\nIn the patched kernel I was able to run just over one hour without seeing\nany issues.  I also verified the output of panic via sysrq-c and the output\nof /proc/modules looks correct for all three states for the dummy_module.\n\n        dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-)\n        dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE)\n        dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+)\n\nSigned-off-by: Prarit Bhargava <prarit@redhat.com>\nReviewed-by: Oleg Nesterov <oleg@redhat.com>\nSigned-off-by: Rusty Russell <rusty@rustcorp.com.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/72f509c6b5bd4958b9d8fa9741d6f5568006f2f5"},{"sha":"cbf67fa8afe95285bfeed5f859508c2426d318b0","author":{"email":"52f8f9962b7f38d8269c63c0859d68147c8d10f0@redhat.com","name":"Mikulas Patocka"},"message":"framebuffer: fix border color\n\ncommit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.\n\nThe framebuffer code uses the current background color to fill the border\nwhen switching consoles, however, this results in inconsistent behavior.\nFor example:\n- start Midnigh Commander\n- the border is black\n- switch to another console and switch back\n- the border is cyan\n- type something into the command line in mc\n- the border is cyan\n- switch to another console and switch back\n- the border is black\n- press F9 to go to menu\n- the border is black\n- switch to another console and switch back\n- the border is dark blue\n\nWhen switching to a console with Midnight Commander, the border is random\ncolor that was left selected by the slang subsystem.\n\nThis patch fixes this inconsistency by always using black as the\nbackground color when switching consoles.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/cbf67fa8afe95285bfeed5f859508c2426d318b0"},{"sha":"bc00570713724a999767e3fdf20282e754b2a56b","author":{"email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com","name":"Hans de Goede"},"message":"Input: i8042 - add noloop quirk for Asus X750LN\n\ncommit 9ff84a17302aeb8913ff244ecc0d8f9d219fecb5 upstream.\n\nWithout this the aux port does not get detected, and consequently the\ntouchpad will not work.\n\nhttps://bugzilla.redhat.com/show_bug.cgi?id=1110011\n\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/bc00570713724a999767e3fdf20282e754b2a56b"},{"sha":"9d596a209fda2d1d7d11f1008ddc4c86e284e402","author":{"email":"9fa1be1a5b5729e4c6b404f34c9ce49ff4882fd8@redhat.com","name":"Hans de Goede"},"message":"Input: i8042 - quirks for Fujitsu Lifebook A544 and Lifebook AH544\n\ncommit 993b3a3f80a7842a48cd46c2b41e1b3ef6302468 upstream.\n\nThese models need i8042.notimeout, otherwise the touchpad will not work.\n\nBugLink: https://bugzilla.kernel.org/show_bug.cgi?id=69731\nBugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1111138\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\nSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/9d596a209fda2d1d7d11f1008ddc4c86e284e402"},{"sha":"c26a2f8f75ade6deafbe4d2cdfe603ce9a10172a","author":{"email":"a7089bb6e7e92505d88aaff006cbdd60cc9120b6@kernel.crashing.org","name":"Benjamin Herrenschmidt"},"message":"drm/ast: Fix HW cursor image\n\ncommit 1e99cfa8de0f0879091e33cd65fd60418d006ad9 upstream.\n\nThe translation from the X driver to the KMS one typo'ed a couple\nof array indices, causing the HW cursor to look weird (blocky with\nleaking edge colors). This fixes it.\n\nSigned-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/c26a2f8f75ade6deafbe4d2cdfe603ce9a10172a"},{"sha":"8126cfe73741542ab0313790dae3f897093f87df","author":{"email":"eb6a2f962bb597f98b2c2b9c4698da19710ddfa3@vanguardiasur.com.ar","name":"Ezequiel Garcia"},"message":"drm/tilcdc: Fix the error path in tilcdc_load()\n\ncommit b478e336b3e75505707a11e78ef8b964ef0a03af upstream.\n\nThe current error path calls tilcdc_unload() in case of an error to release\nthe resources. However, this is wrong because not all resources have been\nallocated by the time an error occurs in tilcdc_load().\n\nTo fix it, this commit adds proper labels to bail out at the different\nstages in the load function, and release only the resources actually allocated.\n\nTested-by: Darren Etheridge <detheridge@ti.com>\nTested-by: Johannes Pointner <johannes.pointner@br-automation.com>\nSigned-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nFixes: 3a49012224ca (\"drm/tilcdc: panel: fix leak when unloading the module\")\nSigned-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/8126cfe73741542ab0313790dae3f897093f87df"},{"sha":"932030b49fd881d403d0151b2678629e74b07441","author":{"email":"d9f27fb07c1e9f131223ad827fa5179f3846c30b@redhat.com","name":"Ben Skeggs"},"message":"drm/nouveau/bios: memset dcb struct to zero before parsing\n\ncommit 595d373f1e9c9ce0fc946457fdb488e8a58972cd upstream.\n\nFixes type/mask calculation being based on uninitialised data for VGA\noutputs.\n\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/932030b49fd881d403d0151b2678629e74b07441"},{"sha":"6ac01ea2317a4615ecbdce1b9d6daa7a44333fa8","author":{"email":"daaac9c5cbf7f3dc8f0a3e52522458912a412925@samsung.com","name":"Maciej Matraszek"},"message":"media: v4l2-common: fix overflow in v4l_bound_align_image()\n\ncommit 3bacc10cd4a85bc70bc0b6c001d3bf995c7fe04c upstream.\n\nFix clamp_align() used in v4l_bound_align_image() to prevent overflow\nwhen passed large value like UINT32_MAX.\n\n In the current implementation:\n    clamp_align(UINT32_MAX, 8, 8192, 3)\n\nreturns 8, because in line:\n\n    x = (x + (1 << (align - 1))) & mask;\n\nx overflows to (-1 + 4) & 0x7 = 3, while expected value is 8192.\n\nv4l_bound_align_image() is heavily used in VIDIOC_S_FMT and\nVIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter\nexplicitly states that:\n\n\"The modified format should be as close as possible to the original\nrequest.\"\n  -- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html\n\nThus one would expect, that passing UINT32_MAX as format width and\nheight will result in setting maximum possible resolution for the\ndevice. Particularly, when the driver doesn't support\nVIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase.\n\nFixes changeset: b0d3159be9a3\n\nSigned-off-by: Maciej Matraszek <m.matraszek@samsung.com>\nAcked-by: Sakari Ailus <sakari.ailus@linux.intel.com>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/6ac01ea2317a4615ecbdce1b9d6daa7a44333fa8"},{"sha":"1c1c6b6435c8ff80d0dea4f074bc626932d6d50b","author":{"email":"27eadf8cc37a0b12407025a9e98c8c3dd8200904@googlemail.com","name":"Frank Schaefer"},"message":"media: em28xx-v4l: give back all active video buffers to the vb2 core properly on streaming stop\n\ncommit 627530c32a43283474e9dd3e954519410ffa033a upstream.\n\nWhen a new video frame is started, the driver takes the next video buffer from\nthe list of active buffers and moves it to dev->usb_ctl.vid_buf / dev->usb_ctl.vbi_buf\nfor further processing.\n\nOn streaming stop we currently only give back the pending buffers from the list\nbut not the ones which are currently processed.\n\nThis causes the following warning from the vb2 core since kernel 3.15:\n\n...\n ------------[ cut here ]------------\n WARNING: CPU: 1 PID: 2284 at drivers/media/v4l2-core/videobuf2-core.c:2115 __vb2_queue_cancel+0xed/0x150 [videobuf2_core]()\n [...]\n Call Trace:\n  [<c0769c46>] dump_stack+0x48/0x69\n  [<c0245b69>] warn_slowpath_common+0x79/0x90\n  [<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]\n  [<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]\n  [<c0245bfd>] warn_slowpath_null+0x1d/0x20\n  [<f925e4ad>] __vb2_queue_cancel+0xed/0x150 [videobuf2_core]\n  [<f925fa35>] vb2_internal_streamoff+0x35/0x90 [videobuf2_core]\n  [<f925fac5>] vb2_streamoff+0x35/0x60 [videobuf2_core]\n  [<f925fb27>] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core]\n  [<f8e45895>] v4l_streamoff+0x15/0x20 [videodev]\n  [<f8e4925d>] __video_do_ioctl+0x23d/0x2d0 [videodev]\n  [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]\n  [<f8e48c63>] video_usercopy+0x203/0x5a0 [videodev]\n  [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]\n  [<c039d0e7>] ? fsnotify+0x1e7/0x2b0\n  [<f8e49012>] video_ioctl2+0x12/0x20 [videodev]\n  [<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]\n  [<f8e4461e>] v4l2_ioctl+0xee/0x130 [videodev]\n  [<f8e44530>] ? v4l2_open+0xf0/0xf0 [videodev]\n  [<c0378de2>] do_vfs_ioctl+0x2e2/0x4d0\n  [<c0368eec>] ? vfs_write+0x13c/0x1c0\n  [<c0369a8f>] ? vfs_writev+0x2f/0x50\n  [<c0379028>] SyS_ioctl+0x58/0x80\n  [<c076fff3>] sysenter_do_call+0x12/0x12\n ---[ end trace 5545f934409f13f4 ]---\n...\n\nMany thanks to Hans Verkuil, whose recently added check in the vb2 core unveiled\nthis long standing issue and who has investigated it further.\n\nSigned-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>\nSigned-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/1c1c6b6435c8ff80d0dea4f074bc626932d6d50b"},{"sha":"cacec1f307e06e8c18a4ec4ab6a2136a35dbc6fb","author":{"email":"40c384bd5ea8471978797d2c5caeae5175553b46@uli-eckhardt.de","name":"Ulrich Eckhardt"},"message":"media: ds3000: fix LNB supply voltage on Tevii S480 on initialization\n\ncommit 8c5bcded11cb607b1bb5920de3b9c882136d27db upstream.\n\nThe Tevii S480 outputs 18V on startup for the LNB supply voltage and does not\nautomatically power down. This blocks other receivers connected\nto a satellite channel router (EN50494), since the receivers can not send the\nrequired DiSEqC sequences when the Tevii card is connected to a the same SCR.\n\nThis patch switches off the LNB supply voltage on initialization of the frontend.\n\n[mchehab@osg.samsung.com: add a comment about why we're explicitly\n turning off voltage at device init]\nSigned-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>\nSigned-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/cacec1f307e06e8c18a4ec4ab6a2136a35dbc6fb"},{"sha":"464f33486ab1d4674a2b622562ecd3587679e02d","author":{"email":"b6ffd6973e972cb999e8e535ab74da7fee0c035f@ingics.com","name":"Axel Lin"},"message":"media: tda7432: Fix setting TDA7432_MUTE bit for TDA7432_RF register\n\ncommit 91ba0e59babdb3c7aca836a65f1095b3eaff7b06 upstream.\n\nFix a copy-paste bug when converting to the control framework.\n\nFixes: commit 5d478e0de871 (\"[media] tda7432: convert to the control framework\")\n\nSigned-off-by: Axel Lin <axel.lin@ingics.com>\nSigned-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/464f33486ab1d4674a2b622562ecd3587679e02d"},{"sha":"ce37f434eb7c443953ec444ed20c4891a62d5152","author":{"email":"3f2200175a6bbbfba43d52ba938bedf5f63cd8af@oracle.com","name":"Quentin Casasnovas"},"message":"kvm: fix excessive pages un-pinning in kvm_iommu_map error path.\n\ncommit 3d32e4dbe71374a6780eaf51d719d76f9a9bf22f upstream.\n\nThe third parameter of kvm_unpin_pages() when called from\nkvm_iommu_map_pages() is wrong, it should be the number of pages to un-pin\nand not the page size.\n\nThis error was facilitated with an inconsistent API: kvm_pin_pages() takes\na size, but kvn_unpin_pages() takes a number of pages, so fix the problem\nby matching the two.\n\nThis was introduced by commit 350b8bd (\"kvm: iommu: fix the third parameter\nof kvm_iommu_put_pages (CVE-2014-3601)\"), which fixes the lack of\nun-pinning for pages intended to be un-pinned (i.e. memory leak) but\nunfortunately potentially aggravated the number of pages we un-pin that\nshould have stayed pinned. As far as I understand though, the same\npractical mitigations apply.\n\nThis issue was found during review of Red Hat 6.6 patches to prepare\nKsplice rebootless updates.\n\nThanks to Vegard for his time on a late Friday evening to help me in\nunderstanding this code.\n\nFixes: 350b8bd (\"kvm: iommu: fix the third parameter of... (CVE-2014-3601)\")\nSigned-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>\nSigned-off-by: Vegard Nossum <vegard.nossum@oracle.com>\nSigned-off-by: Jamie Iles <jamie.iles@oracle.com>\nReviewed-by: Sasha Levin <sasha.levin@oracle.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/ce37f434eb7c443953ec444ed20c4891a62d5152"},{"sha":"a7ae932dd9a0fd583ebc39d75cb7a74666d1b6e1","author":{"email":"bcabda073ed7d87908c47c148553c19de226e7ab@google.com","name":"Andy Honig"},"message":"KVM: x86: Prevent host from panicking on shared MSR writes.\n\ncommit 8b3c3104c3f4f706e99365c3e0d2aa61b95f969f upstream.\n\nThe previous patch blocked invalid writes directly when the MSR\nis written.  As a precaution, prevent future similar mistakes by\ngracefulling handle GPs caused by writes to shared MSRs.\n\nSigned-off-by: Andrew Honig <ahonig@google.com>\n[Remove parts obsoleted by Nadav's patch. - Paolo]\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/a7ae932dd9a0fd583ebc39d75cb7a74666d1b6e1"},{"sha":"41cc37b9ee0ca1263faed0dd59b531bf6667a41d","author":{"email":"bcabda073ed7d87908c47c148553c19de226e7ab@google.com","name":"Andy Honig"},"message":"KVM: x86: Improve thread safety in pit\n\ncommit 2febc839133280d5a5e8e1179c94ea674489dae2 upstream.\n\nThere's a race condition in the PIT emulation code in KVM.  In\n__kvm_migrate_pit_timer the pit_timer object is accessed without\nsynchronization.  If the race condition occurs at the wrong time this\ncan crash the host kernel.\n\nThis fixes CVE-2014-3611.\n\nSigned-off-by: Andrew Honig <ahonig@google.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/Ayysir/android_kernel_motorola_shamu/commits/41cc37b9ee0ca1263faed0dd59b531bf6667a41d"}]}