{"push_id":623158984,"size":24,"distinct_size":24,"ref":"refs/heads/lollipop","head":"377c5e59170d20e7d176fe5caa725e5a5a5b167e","before":"e88be3e706f5d3805c02fb03373eec5aa238f677","commits":[{"sha":"77c4c31fff7a3340bb66026c8d817771dd84c10f","author":{"email":"1efac8fcaddebe669cb35e498dd211e17e274493@samsung.com","name":"Weijie Yang"},"message":"mm: frontswap: invalidate expired data on a dup-store failure\n\ncommit fb993fa1a2f669215fa03a09eed7848f2663e336 upstream.\n\nIf a frontswap dup-store failed, it should invalidate the expired page\nin the backend, or it could trigger some data corruption issue.\nSuch as:\n 1. use zswap as the frontswap backend with writeback feature\n 2. store a swap page(version_1) to entry A, success\n 3. dup-store a newer page(version_2) to the same entry A, fail\n 4. use __swap_writepage() write version_2 page to swapfile, success\n 5. zswap do shrink, writeback version_1 page to swapfile\n 6. version_2 page is overwrited by version_1, data corrupt.\n\nThis patch fixes this issue by invalidating expired data immediately\nwhen meet a dup-store failure.\n\nSigned-off-by: Weijie Yang <weijie.yang@samsung.com>\nCc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nCc: Seth Jennings <sjennings@variantweb.net>\nCc: Dan Streetman <ddstreet@ieee.org>\nCc: Minchan Kim <minchan@kernel.org>\nCc: Bob Liu <bob.liu@oracle.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/77c4c31fff7a3340bb66026c8d817771dd84c10f"},{"sha":"47db3431face1d5e67fa6d4550ff6bab79b75e7d","author":{"email":"d3abdf3e2800e6cb849f11b81e6eb50b34d96431@google.com","name":"Hugh Dickins"},"message":"mm: fix swapoff hang after page migration and fork\n\ncommit 2022b4d18a491a578218ce7a4eca8666db895a73 upstream.\n\nI've been seeing swapoff hangs in recent testing: it's cycling around\ntrying unsuccessfully to find an mm for some remaining pages of swap.\n\nI have been exercising swap and page migration more heavily recently,\nand now notice a long-standing error in copy_one_pte(): it's trying to\nadd dst_mm to swapoff's mmlist when it finds a swap entry, but is doing\nso even when it's a migration entry or an hwpoison entry.\n\nWhich wouldn't matter much, except it adds dst_mm next to src_mm,\nassuming src_mm is already on the mmlist: which may not be so.  Then if\npages are later swapped out from dst_mm, swapoff won't be able to find\nwhere to replace them.\n\nThere's already a !non_swap_entry() test for stats: move that up before\nthe swap_duplicate() and the addition to mmlist.\n\nSigned-off-by: Hugh Dickins <hughd@google.com>\nCc: Kelley Nielsen <kelleynnn@gmail.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/47db3431face1d5e67fa6d4550ff6bab79b75e7d"},{"sha":"9343af6e30fc9defab92697087ee62614e898d4b","author":{"email":"ead5052bef9b6b56b51f87cdc5b831be775ee6fb@canonical.com","name":"Seth Forshee"},"message":"xen-netfront: Remove BUGs on paged skb data which crosses a page boundary\n\ncommit 8d609725d4357f499e2103e46011308b32f53513 upstream.\n\nThese BUGs can be erroneously triggered by frags which refer to\ntail pages within a compound page. The data in these pages may\noverrun the hardware page while still being contained within the\ncompound page, but since compound_order() evaluates to 0 for tail\npages the assertion fails. The code already iterates through\nsubsequent pages correctly in this scenario, so the BUGs are\nunnecessary and can be removed.\n\nFixes: f36c374782e4 (\"xen/netfront: handle compound page fragments on transmit\")\nSigned-off-by: Seth Forshee <seth.forshee@canonical.com>\nReviewed-by: David Vrabel <david.vrabel@citrix.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/9343af6e30fc9defab92697087ee62614e898d4b"},{"sha":"bdc32a879232b360c52e6d6186e54bac7976561e","author":{"email":"ff34906ef668000e36b2844349d7f337a2f4d1d5@gmail.com","name":"Alexander Kochetkov"},"message":"i2c: omap: fix NACK and Arbitration Lost irq handling\n\ncommit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream.\n\ncommit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts)\nchanged the interrupt handler to complete transfers without clearing\nXRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be\nfired again. As a result, ISR keep processing transfer after it was already\ncomplete (from the driver code point of view).\n\nA didn't see real impacts of the 1d7afc9, but it is really bad idea to\nhave ISR running on user data after transfer was complete.\n\nIt looks, what 1d7afc9 violate TI specs in what how AL and NACK should be\nhandled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).\n\nAccording to specs (if I understood correctly), in case of NACK and AL driver\nmust reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and\nNACK, AL, ARDY, and XDR (Master Transmitter Mode).\n\nAll that is done down the code under the if condition:\nif (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...\n\nThe patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so\nno interrupts is fired after ISR informs the rest of driver what transfer\ncomplete.\n\nNote: instead of removing break under NACK case, we could just replace 'break'\nwith 'continue' and allow NACK transfer to finish using ARDY event. I found\nthat NACK and ARDY bits usually set together. That case confirm TI wiki:\nhttp://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK\n\nIn order if someone interested in the event traces for NACK and AL cases,\nI sent them to mailing list.\n\nTested on Beagleboard XM C.\n\nSigned-off-by: Alexander Kochetkov <al.kochet@gmail.com>\nFixes: 1d7afc9 i2c: omap: ack IRQ in parts\nAcked-by: Felipe Balbi <balbi@ti.com>\nTested-by: Aaro Koskinen <aaro.koskinen@iki.fi>\nSigned-off-by: Wolfram Sang <wsa@the-dreams.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/bdc32a879232b360c52e6d6186e54bac7976561e"},{"sha":"45dfe43f066089fe1c66076fe505a22dae400674","author":{"email":"ff34906ef668000e36b2844349d7f337a2f4d1d5@gmail.com","name":"Alexander Kochetkov"},"message":"i2c: omap: fix i207 errata handling\n\ncommit ccfc866356674cb3a61829d239c685af6e85f197 upstream.\n\ncommit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR\nand [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly\nSet) get handled. 6d9939f6514 code doesn't correspond to workaround provided by\nerrata.\n\nAccording to errata ISR must filter out spurious RDR before data read not after.\nISR must read RXSTAT to get number of bytes available to read. Because RDR\ncould be set while there could no data in the receive FIFO.\n\nRestored pre 6d9939f6514 way of handling errata.\n\nFound by code review. Real impact haven't seen.\nTested on Beagleboard XM C.\n\nSigned-off-by: Alexander Kochetkov <al.kochet@gmail.com>\nFixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY\nTested-by: Felipe Balbi <balbi@ti.com>\nReviewed-by: Felipe Balbi <balbi@ti.com>\nSigned-off-by: Wolfram Sang <wsa@the-dreams.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/45dfe43f066089fe1c66076fe505a22dae400674"},{"sha":"adafa5027075c1683602ef2341c774a219fe58e3","author":{"email":"bfa0a1520768723a1c60e18250fb841c342eb8d8@ti.com","name":"Grygorii Strashko"},"message":"i2c: davinci: generate STP always when NACK is received\n\ncommit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream.\n\nAccording to I2C specification the NACK should be handled as follows:\n\"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not\nAcknowledge signal. The master can then generate either a STOP condition to\nabort the transfer, or a repeated START condition to start a new transfer.\"\n[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]\n\nCurrently the Davinci i2c driver interrupts the transfer on receipt of a\nNACK but fails to send a STOP in some situations and so makes the bus\nstuck until next I2C IP reset (idle/enable).\n\nFor example, the issue will happen during SMBus read transfer which\nconsists from two i2c messages write command/address and read data:\n\nS Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P\n<--- write -----------------------> <--- read --------------------->\n\nThe I2C client device will send NACK if it can't recognize \"Command Code\"\nand it's expected from I2C master to generate STP in this case.\nBut now, Davinci i2C driver will just exit with -EREMOTEIO and STP will\nnot be generated.\n\nHence, fix it by generating Stop condition (STP) always when NACK is received.\n\nThis patch fixes Davinci I2C in the same way it was done for OMAP I2C\ncommit cda2109a26eb (\"i2c: omap: query STP always when NACK is received\").\n\nReviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>\nReported-by: Hein Tibosch <hein_tibosch@yahoo.es>\nSigned-off-by: Grygorii Strashko <grygorii.strashko@ti.com>\nSigned-off-by: Wolfram Sang <wsa@the-dreams.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/adafa5027075c1683602ef2341c774a219fe58e3"},{"sha":"86c760c8cdbfe69938a981f6bfb7abd0e0ba13dc","author":{"email":"9cbcfb1260d253e26a699647bd9cbee55818ea4a@suse.cz","name":"Petr Mladek"},"message":"drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6\n\ncommit f5475cc43c899e33098d4db44b7c5e710f16589d upstream.\n\nI was unable too boot 3.18.0-rc6 because of the following kernel\npanic in drm_calc_vbltimestamp_from_scanoutpos():\n\n    [drm] Initialized drm 1.1.0 20060810\n    [drm] radeon kernel modesetting enabled.\n    [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).\n    [drm] register mmio base: 0xC8400000\n    [drm] register mmio size: 65536\n    radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)\n    radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF\n    [drm] Detected VRAM RAM=128M, BAR=128M\n    [drm] RAM width 16bits DDR\n    [TTM] Zone  kernel: Available graphics memory: 3829346 kiB\n    [TTM] Zone   dma32: Available graphics memory: 2097152 kiB\n    [TTM] Initializing pool allocator\n    [TTM] Initializing DMA pool allocator\n    [drm] radeon: 16M of VRAM memory ready\n    [drm] radeon: 512M of GTT memory ready.\n    [drm] GART: num cpu pages 131072, num gpu pages 131072\n    [drm] PCI GART of 512M enabled (table at 0x0000000037880000).\n    radeon 0000:0b:01.0: WB disabled\n    radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000\n    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).\n    [drm] Driver supports precise vblank timestamp query.\n    [drm] radeon: irq initialized.\n    [drm] Loading R100 Microcode\n    radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2\n    radeon_cp: Failed to load firmware \"radeon/R100_cp.bin\"\n    [drm:r100_cp_init] *ERROR* Failed to load firmware!\n    radeon 0000:0b:01.0: failed initializing CP (-2).\n    radeon 0000:0b:01.0: Disabling GPU acceleration\n    [drm] radeon: cp finalized\n    BUG: unable to handle kernel NULL pointer dereference at 000000000000025c\n    IP: [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320\n    PGD 0\n    Oops: 0000 [#1] SMP\n    Modules linked in:\n    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649\n    Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006\n    task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000\n    RIP: 0010:[<ffffffff8150423b>]  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320\n    RSP: 0000:ffff880234da7918  EFLAGS: 00010086\n    RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48\n    RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000\n    RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000\n    R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0\n    R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000\n    FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b\n    CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0\n    Stack:\n     ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480\n     ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d\n     ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58\n    Call Trace:\n     [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110\n     [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60\n     [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180\n     [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70\n     [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0\n     [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70\n     [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0\n     [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70\n     [<ffffffff8156c07e>] r100_init+0x26e/0x410\n     [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50\n     [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210\n     [<ffffffff81506965>] drm_dev_register+0xb5/0x110\n     [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200\n     [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0\n     [<ffffffff8141a365>] local_pci_probe+0x45/0xa0\n     [<ffffffff8141b741>] pci_device_probe+0xd1/0x130\n     [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0\n     [<ffffffff8163413b>] __driver_attach+0x9b/0xa0\n     [<ffffffff816340a0>] ? __device_attach+0x40/0x40\n     [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0\n     [<ffffffff8163378e>] driver_attach+0x1e/0x20\n     [<ffffffff81633390>] bus_add_driver+0x180/0x240\n     [<ffffffff81634914>] driver_register+0x64/0xf0\n     [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50\n     [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120\n     [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a\n     [<ffffffff821dc908>] radeon_init+0x97/0xb5\n     [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0\n     [<ffffffff810e3278>] ? __wake_up+0x48/0x60\n     [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215\n     [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0\n     [<ffffffff818a78f0>] ? rest_init+0x80/0x80\n     [<ffffffff818a78fe>] kernel_init+0xe/0xf0\n     [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0\n     [<ffffffff818a78f0>] ? rest_init+0x80/0x80\n    Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60\n    RIP  [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320\n     RSP <ffff880234da7918>\n    CR2: 000000000000025c\n    ---[ end trace ad2c0aadf48e2032 ]---\n    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009\n\nIt has helped me to add a NULL pointer check that was suggested at\nhttp://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html\n\nI am not familiar with the code. But the change looks sane\nand we need something fast at this stage of 3.18 development.\n\nSuggested-by: Helge Deller <deller@gmx.de>\nSigned-off-by: Petr Mladek <pmladek@suse.cz>\nTested-by: Petr Mladek <pmladek@suse.cz>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/86c760c8cdbfe69938a981f6bfb7abd0e0ba13dc"},{"sha":"3a2e2a3e9fa720dc44b654ea915d60a4fe19750b","author":{"email":"c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","name":"Daniel Vetter"},"message":"drm/i915: Unlock panel even when LVDS is disabled\n\ncommit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.\n\nOtherwise we'll have backtraces in assert_panel_unlocked because the\nBIOS locks the register. In the reporter's case this regression was\nintroduced in\n\ncommit c31407a3672aaebb4acddf90944a114fa5c8af7b\nAuthor: Chris Wilson <chris@chris-wilson.co.uk>\nDate:   Thu Oct 18 21:07:01 2012 +0100\n\n    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H\n\nReported-by: Alexey Orishko <alexey.orishko@gmail.com>\nCc: Alexey Orishko <alexey.orishko@gmail.com>\nCc: Chris Wilson <chris@chris-wilson.co.uk>\nCc: Francois Tigeot <ftigeot@wolfpond.org>\nSigned-off-by: Daniel Vetter <daniel.vetter@intel.com>\nTested-by: Alexey Orishko <alexey.orishko@gmail.com>\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/3a2e2a3e9fa720dc44b654ea915d60a4fe19750b"},{"sha":"3dcc6f5231033347e96019ddcfb0ce7904cd6046","author":{"email":"8d98c2be02a446df653daa2c00496b87f3f016e4@iki.fi","name":"Sakari Ailus"},"message":"media: smiapp: Only some selection targets are settable\n\ncommit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream.\n\nSetting a non-settable selection target caused BUG() to be called. The check\nfor valid selections only takes the selection target into account, but does\nnot tell whether it may be set, or only get. Fix the issue by simply\nreturning an error to the user.\n\nSigned-off-by: Sakari Ailus <sakari.ailus@iki.fi>\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/nychitman1/android_kernel_htc_flounder/commits/3dcc6f5231033347e96019ddcfb0ce7904cd6046"},{"sha":"2de6f2b9c1c97dc1f6d1403f187b647f7a221a81","author":{"email":"6b0a8a7e4bcdc440f873e738e2b237be71f09177@intel.com","name":"Devin Ryles"},"message":"AHCI: Add DeviceIDs for Sunrise Point-LP SATA controller\n\ncommit 249cd0a187ed4ef1d0af7f74362cc2791ec5581b upstream.\n\nThis patch adds DeviceIDs for Sunrise Point-LP.\n\nSigned-off-by: Devin Ryles <devin.ryles@intel.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/2de6f2b9c1c97dc1f6d1403f187b647f7a221a81"},{"sha":"791f183de7f59ffa89679ea86781e06fe8dc47d0","author":{"email":"546b05909706652891a87f7bfe385ae147f61f91@kernel.org","name":"Tejun Heo"},"message":"ahci: disable MSI on SAMSUNG 0xa800 SSD\n\ncommit 2b21ef0aae65f22f5ba86b13c4588f6f0c2dbefb upstream.\n\nJust like 0x1600 which got blacklisted by 66a7cbc303f4 (\"ahci: disable\nMSI instead of NCQ on Samsung pci-e SSDs on macbooks\"), 0xa800 chokes\non NCQ commands if MSI is enabled.  Disable MSI.\n\nSigned-off-by: Tejun Heo <tj@kernel.org>\nReported-by: Dominik Mierzejewski <dominik@greysector.net>\nLink: https://bugzilla.kernel.org/show_bug.cgi?id=89171\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/791f183de7f59ffa89679ea86781e06fe8dc47d0"},{"sha":"f5eac8973fc7fe9fbed50c9a914ca5171e93b148","author":{"email":"10a8c465cefc9bdd6c925e26964d23c90f1141cc@chromium.org","name":"Dmitry Torokhov"},"message":"sata_fsl: fix error handling of irq_of_parse_and_map\n\ncommit aad0b624129709c94c2e19e583b6053520353fa8 upstream.\n\nirq_of_parse_and_map() returns 0 on error (the result is unsigned int),\nso testing for negative result never works.\n\nSigned-off-by: Dmitry Torokhov <dtor@chromium.org>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/f5eac8973fc7fe9fbed50c9a914ca5171e93b148"},{"sha":"227e3a3bed9e396ed096eb43e0642ca4a76e12a9","author":{"email":"1f7f115be12bd6a7d0ce4e981a8b6a6d375fca3a@gmail.com","name":"Yuri Chislov"},"message":"ipv6: gre: fix wrong skb->protocol in WCCP\n\n[ Upstream commit be6572fdb1bfbe23b2624d477de50af50b02f5d6 ]\n\nWhen using GRE redirection in WCCP, it sets the wrong skb->protocol,\nthat is, ETH_P_IP instead of ETH_P_IPV6 for the encapuslated traffic.\n\nFixes: c12b395a4664 (\"gre: Support GRE over IPv6\")\nCc: Dmitry Kozlov <xeb@mail.ru>\nSigned-off-by: Yuri Chislov <yuri.chislov@gmail.com>\nTested-by: Yuri Chislov <yuri.chislov@gmail.com>\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/227e3a3bed9e396ed096eb43e0642ca4a76e12a9"},{"sha":"aeccd1b5356d8f450c6834533a399962f633bcef","author":{"email":"c8883472cb5fbead63941b41bccc869c7deaf90f@linux.vnet.ibm.com","name":"Thadeu Lima de Souza Cascardo"},"message":"tg3: fix ring init when there are more TX than RX channels\n\n[ Upstream commit a620a6bc1c94c22d6c312892be1e0ae171523125 ]\n\nIf TX channels are set to 4 and RX channels are set to less than 4,\nusing ethtool -L, the driver will try to initialize more RX channels\nthan it has allocated, causing an oops.\n\nThis fix only initializes the RX ring if it has been allocated.\n\nSigned-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/aeccd1b5356d8f450c6834533a399962f633bcef"},{"sha":"b8526d15f38b06edb560ab82d5db678f5c017cdf","author":{"email":"067deeb0d1a5180729b0e79bbb5b609fc5bbbab4@dev.mellanox.co.il","name":"Jack Morgenstein"},"message":"net/mlx4_core: Limit count field to 24 bits in qp_alloc_res\n\n[ Upstream commit 2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ]\n\nSome VF drivers use the upper byte of \"param1\" (the qp count field)\nin mlx4_qp_reserve_range() to pass flags which are used to optimize\nthe range allocation.\n\nUnder the current code, if any of these flags are set, the 32-bit\ncount field yields a count greater than 2^24, which is out of range,\nand this VF fails.\n\nAs these flags represent a \"best-effort\" allocation hint anyway, they may\nsafely be ignored. Therefore, the PF driver may simply mask out the bits.\n\nFixes: c82e9aa0a8 \"mlx4_core: resource tracking for HCA resources used by guests\"\nSigned-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>\nSigned-off-by: Or Gerlitz <ogerlitz@mellanox.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/b8526d15f38b06edb560ab82d5db678f5c017cdf"},{"sha":"80d031d1c14820406d05a445f376f8cf6e681365","author":{"email":"7864bb1e0e12322ea18ea731d051b95b75140567@6wind.com","name":"Nicolas Dichtel"},"message":"rtnetlink: release net refcnt on error in do_setlink()\n\n[ Upstream commit e0ebde0e131b529fd721b24f62872def5ec3718c ]\n\nrtnl_link_get_net() holds a reference on the 'struct net', we need to release\nit in case of error.\n\nCC: Eric W. Biederman <ebiederm@xmission.com>\nFixes: b51642f6d77b (\"net: Enable a userns root rtnl calls that are safe for unprivilged users\")\nSigned-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>\nReviewed-by: \"Eric W. Biederman\" <ebiederm@xmission.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/80d031d1c14820406d05a445f376f8cf6e681365"},{"sha":"54bdc7a2c24dba8faa35d50f7089d49133984bd6","author":{"email":"aff024fe4ab0fece4091de044c58c9ae4233383a@1wt.eu","name":"willy tarreau"},"message":"net: mvneta: fix Tx interrupt delay\n\n[ Upstream commit aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ]\n\nThe mvneta driver sets the amount of Tx coalesce packets to 16 by\ndefault. Normally that does not cause any trouble since the driver\nuses a much larger Tx ring size (532 packets). But some sockets\nmight run with very small buffers, much smaller than the equivalent\nof 16 packets. This is what ping is doing for example, by setting\nSNDBUF to 324 bytes rounded up to 2kB by the kernel.\n\nThe problem is that there is no documented method to force a specific\npacket to emit an interrupt (eg: the last of the ring) nor is it\npossible to make the NIC emit an interrupt after a given delay.\n\nIn this case, it causes trouble, because when ping sends packets over\nits raw socket, the few first packets leave the system, and the first\n15 packets will be emitted without an IRQ being generated, so without\nthe skbs being freed. And since the socket's buffer is small, there's\nno way to reach that amount of packets, and the ping ends up with\n\"send: no buffer available\" after sending 6 packets. Running with 3\ninstances of ping in parallel is enough to hide the problem, because\nwith 6 packets per instance, that's 18 packets total, which is enough\nto grant a Tx interrupt before all are sent.\n\nThe original driver in the LSP kernel worked around this design flaw\nby using a software timer to clean up the Tx descriptors. This timer\nwas slow and caused terrible network performance on some Tx-bound\nworkloads (such as routing) but was enough to make tools like ping\nwork correctly.\n\nInstead here, we simply set the packet counts before interrupt to 1.\nThis ensures that each packet sent will produce an interrupt. NAPI\ntakes care of coalescing interrupts since the interrupt is disabled\nonce generated.\n\nNo measurable performance impact nor CPU usage were observed on small\nnor large packets, including when saturating the link on Tx, and this\nfixes tools like ping which rely on too small a send buffer. If one\nwants to increase this value for certain workloads where it is safe\nto do so, \"ethtool -C $dev tx-frames\" will override this default\nsetting.\n\nThis fix needs to be applied to stable kernels starting with 3.10.\n\nTested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>\nSigned-off-by: Willy Tarreau <w@1wt.eu>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/54bdc7a2c24dba8faa35d50f7089d49133984bd6"},{"sha":"e2754d159c222d9dea58518c96bd781f8b353496","author":{"email":"9ff04a02a69f376b2b9aeec27187017cbf3cf5f9@redhat.com","name":"Daniel Borkmann"},"message":"net: sctp: use MAX_HEADER for headroom reserve in output path\n\n[ Upstream commit 9772b54c55266ce80c639a80aa68eeb908f8ecf5 ]\n\nTo accomodate for enough headroom for tunnels, use MAX_HEADER instead\nof LL_MAX_HEADER. Robert reported that he has hit after roughly 40hrs\nof trinity an skb_under_panic() via SCTP output path (see reference).\nI couldn't reproduce it from here, but not using MAX_HEADER as elsewhere\nin other protocols might be one possible cause for this.\n\nIn any case, it looks like accounting on chunks themself seems to look\ngood as the skb already passed the SCTP output path and did not hit\nany skb_over_panic(). Given tunneling was enabled in his .config, the\nheadroom would have been expanded by MAX_HEADER in this case.\n\nReported-by: Robert Święcki <robert@swiecki.net>\nReference: https://lkml.org/lkml/2014/12/1/507\nFixes: 594ccc14dfe4d (\"[SCTP] Replace incorrect use of dev_alloc_skb with alloc_skb in sctp_packet_transmit().\")\nSigned-off-by: Daniel Borkmann <dborkman@redhat.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nAcked-by: Neil Horman <nhorman@tuxdriver.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/e2754d159c222d9dea58518c96bd781f8b353496"},{"sha":"86d4987f13bf8eb92a112ba390e1b91f7713f07a","author":{"email":"625169824b719df98706d88646d0aae6f368ae4d@il.ibm.com","name":"Nadav Har'El"},"message":"nEPT: Nested INVEPT\n\ncommit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream.\n\nIf we let L1 use EPT, we should probably also support the INVEPT instruction.\n\nIn our current nested EPT implementation, when L1 changes its EPT table\nfor L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in\nthe course of this modification already calls INVEPT. But if last level\nof shadow page is unsync not all L1's changes to EPT12 are intercepted,\nwhich means roots need to be synced when L1 calls INVEPT. Global INVEPT\nshould not be different since roots are synced by kvm_mmu_load() each\ntime EPTP02 changes.\n\nReviewed-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>\nSigned-off-by: Nadav Har'El <nyh@il.ibm.com>\nSigned-off-by: Jun Nakajima <jun.nakajima@intel.com>\nSigned-off-by: Xinhao Xu <xinhao.xu@intel.com>\nSigned-off-by: Yang Zhang <yang.z.zhang@Intel.com>\nSigned-off-by: Gleb Natapov <gleb@redhat.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\n[bwh: Backported to 3.2:\n - Adjust context, filename\n - Simplify handle_invept() as recommended by Paolo - nEPT is not\n   supported so we always raise #UD]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>\nCc: Vinson Lee <vlee@twopensource.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/86d4987f13bf8eb92a112ba390e1b91f7713f07a"},{"sha":"5499f77eb6aa76047736d4f39d895594b60e61cf","author":{"email":"596727c8a0ea4db3ba2ceceedccbacd3d7b371b8@suse.cz","name":"Jan Kara"},"message":"ext2: Fix oops in ext2_get_block() called from ext2_quota_write()\n\ncommit df4e7ac0bb70abc97fbfd9ef09671fc084b3f9db upstream.\n\next2_quota_write() doesn't properly setup bh it passes to\next2_get_block() and thus we hit assertion BUG_ON(maxblocks == 0) in\next2_get_blocks() (or we could actually ask for mapping arbitrary number\nof blocks depending on whatever value was on stack).\n\nFix ext2_quota_write() to properly fill in number of blocks to map.\n\nReviewed-by: \"Theodore Ts'o\" <tytso@mit.edu>\nReviewed-by: Christoph Hellwig <hch@lst.de>\nReported-by: Christoph Hellwig <hch@infradead.org>\nSigned-off-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/nychitman1/android_kernel_htc_flounder/commits/5499f77eb6aa76047736d4f39d895594b60e61cf"}]}