GitHub PushEvent at 2014-05-03 15:04:46
Repository: android_kernel_google_msm
Actor: BobZmotion
Payload: {"shas":[["8b5fec5ed0a9003a711647902d07e224e8d3dfa5","8dcf0f69152f32f23184f83357a3731522e56b9c@de.ibm.com","s390/compat: fix compat wrappers for process_vm system calls\n\ncommit 82aabdb6f1eb61e0034ec23901480f5dd23db7c4 upstream.\n\nThe compat wrappers incorrectly called the non compat versions of\nthe system process_vm system calls.\n\nSigned-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Heiko Carstens",true],["0b31f4063b4e1d983c6df9745695ba266ded2965","8dcf0f69152f32f23184f83357a3731522e56b9c@de.ibm.com","s390/compat: fix mmap compat system calls\n\ncommit e85871218513c54f7dfdb6009043cb638f2fecbe upstream.\n\nThe native 31 bit and the compat behaviour for the mmap system calls differ:\n\nIn native 31 bit mode the passed in address for the mmap system call will be\nunmodified passed to sys_mmap_pgoff().\nIn compat mode however the passed in address will be modified with\ncompat_ptr() which masks out the most significant bit.\n\nThe result is that in native 31 bit mode each mmap request (with MAP_FIXED)\nwill fail where the most significat bit is set, while in compat mode it\nmay succeed.\n\nThis odd behaviour was introduced with d3815898 \"[S390] mmap: add missing\ncompat_ptr conversion to both mmap compat syscalls\".\n\nTo restore a consistent behaviour accross native and compat mode this\npatch functionally reverts the above mentioned commit.\n\nSigned-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>\nSigned-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Heiko Carstens",true],["394e0151bebb7a5d902dc5f345cde77d5bea752e","288a049a20dc4091188b72022d411ad1375e6737@gmail.com","dma: imx-dma: Fix kernel crash due to missing clock conversion\n\ncommit a2367db2ec5e7fc6fe93e221e0fcdee81b053daf upstream.\n\nWith the new i.MX clock infrastructure we need to request the dma clocks\nseperately: ahb and ipg clocks.\n\nThis fixes the following kernel crash and make audio to be functional again:\n\nroot@freescale /home$ aplay audio48k16S.wav\nPlaying WAVE 'audio48k16S.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo\nUnable to handle kernel NULL pointer dereference at virtual address 00000000\npgd = c7b74000\n[00000000] *pgd=a7bb5831, *pte=00000000, *ppte=00000000\nInternal error: Oops: 17 [#1] PREEMPT ARM\nModules linked in:\nCPU: 0    Not tainted  (3.5.0-rc5-next-20120702-00007-g3028b64 #1128)\nPC is at snd_dmaengine_pcm_get_chan+0x8/0x10\nLR is at snd_imx_pcm_hw_params+0x18/0xdc\npc : [<c02d3cf8>]    lr : [<c02e95ec>]    psr: a0000013\nsp : c7b45e30  ip : ffffffff  fp : c7ae58e0\nr10: 00000000  r9 : c7ae981c  r8 : c7b88800\nr7 : c7ae5a60  r6 : c7ae5b20  r5 : c7ae9810  r4 : c7afa060\nr3 : 00000000  r2 : 00000001  r1 : c7b88800  r0 : c7afa060\nFlags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 0005317f  Table: a7b74000  DAC: 00000015\nProcess aplay (pid: 701, stack limit = 0xc7b44270)\nStack: (0xc7b45e30 to 0xc7b46000)\n5e20:                                     00100000 00000029 c7b88800 c02db870\n5e40: c7ae5a60 c02d4594 00000010 01ae5a60 c7ae5a60 c7ae9810 c7ae9810 c7afa060\n5e60: c7ae5b20 c7ae5a60 c7b88800 c02e3ef0 c02e3e08 c7b1e400 c7afa060 c7b88800\n5e80: 00000000 c0014da8 c7b44000 00000000 bec566ac c02cd400 c7afa060 c7afa060\n5ea0: bec56800 c7b88800 c0014da8 c02cdd7c c04ee710 c04ee7b8 00000003 c005fc74\n5ec0: 00000000 7fffffff c7b45f00 c7afa060 c7b67420 c7ba3070 00000004 c0014da8\n5ee0: c7b44000 00000000 bec566ac c02ced88 c04e95f8 b6f5ab04 c7b45fb0 0145a468\n5f00: 0145a600 bec566bc bec56800 c7b67420 c7ba3070 c00d499c c7b45f18 c7b45f18\n5f20: 0000001a 00000004 00000001 c7b44000 c0527f40 00000009 00000008 00000000\n5f40: c7b44000 c002c9ec 00000001 c04f0ab0 c04ebec0 00000101 00000000 0000000a\n5f60: 60000093 c7b67420 bec56800 c25c4111 00000004 c0014da8 c7b44000 00000000\n5f80: bec566ac c00d4f38 b6ffb658 00000000 c0522d80 0145a468 b6fd5000 0145a418\n5fa0: 00000036 c0014c00 0145a468 b6fd5000 00000004 c25c4111 bec56800 00020001\n5fc0: 0145a468 b6fd5000 0145a418 00000036 0145a468 0145a600 bec566bc bec566ac\n5fe0: 0145a468 bec56388 b6f65ce4 b6dcebec 20000010 00000004 00000000 00000000\n[<c02d3cf8>] (snd_dmaengine_pcm_get_chan+0x8/0x10) from [<c02e95ec>] (snd_imx_pcm_hw_params+0x18/0xdc)\n[<c02e95ec>] (snd_imx_pcm_hw_params+0x18/0xdc) from [<c02e3ef0>] (soc_pcm_hw_params+0xe8/0x1f0)\n[<c02e3ef0>] (soc_pcm_hw_params+0xe8/0x1f0) from [<c02cd400>] (snd_pcm_hw_params+0x124/0x474)\n[<c02cd400>] (snd_pcm_hw_params+0x124/0x474) from [<c02cdd7c>] (snd_pcm_common_ioctl1+0x4b4/0xf74)\n[<c02cdd7c>] (snd_pcm_common_ioctl1+0x4b4/0xf74) from [<c02ced88>] (snd_pcm_playback_ioctl1+0x30/0x510)\n[<c02ced88>] (snd_pcm_playback_ioctl1+0x30/0x510) from [<c00d499c>] (do_vfs_ioctl+0x80/0x5e4)\n[<c00d499c>] (do_vfs_ioctl+0x80/0x5e4) from [<c00d4f38>] (sys_ioctl+0x38/0x60)\n[<c00d4f38>] (sys_ioctl+0x38/0x60) from [<c0014c00>] (ret_fast_syscall+0x0/0x2c)\nCode: e593000c e12fff1e e59030a0 e59330bc (e5930000)\n---[ end trace fa518c8ba3a74e97 ]--\n\nReported-by: Javier Martin <javier.martin@vista-silicon.com>\nSigned-off-by: Fabio Estevam <fabio.estevam@freescale.com>\nAcked-by: Sascha Hauer <s.hauer@pengutronix.de>\nSigned-off-by: Vinod Koul <vinod.koul@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Fabio Estevam",true],["f11de0c216e24a208faa9a2c4e085004e58a360b","bdd5a5f42152ba789e24c1ef8132eb16704ed8a4@redhat.com","fuse: verify all ioctl retry iov elements\n\ncommit fb6ccff667712c46b4501b920ea73a326e49626a upstream.\n\nCommit 7572777eef78ebdee1ecb7c258c0ef94d35bad16 attempted to verify that\nthe total iovec from the client doesn't overflow iov_length() but it\nonly checked the first element.  The iovec could still overflow by\nstarting with a small element.  The obvious fix is to check all the\nelements.\n\nThe overflow case doesn't look dangerous to the kernel as the copy is\nlimited by the length after the overflow.  This fix restores the\nintention of returning an error instead of successfully copying less\nthan the iovec represented.\n\nI found this by code inspection.  I built it but don't have a test case.\nI'm cc:ing stable because the initial commit did as well.\n\nSigned-off-by: Zach Brown <zab@redhat.com>\nSigned-off-by: Miklos Szeredi <mszeredi@suse.cz>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Zach Brown",true],["b38552e195bea43b6ee93b2dc53038a616f99305","22a0c6385d750d07aa383c9f813cf6f0228657d8@eu.citrix.com","xen: mark local pages as FOREIGN in the m2p_override\n\ncommit b9e0d95c041ca2d7ad297ee37c2e9cfab67a188f upstream.\n\nWhen the frontend and the backend reside on the same domain, even if we\nadd pages to the m2p_override, these pages will never be returned by\nmfn_to_pfn because the check \"get_phys_to_machine(pfn) != mfn\" will\nalways fail, so the pfn of the frontend will be returned instead\n(resulting in a deadlock because the frontend pages are already locked).\n\nINFO: task qemu-system-i38:1085 blocked for more than 120 seconds.\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\nqemu-system-i38 D ffff8800cfc137c0     0  1085      1 0x00000000\n ffff8800c47ed898 0000000000000282 ffff8800be4596b0 00000000000137c0\n ffff8800c47edfd8 ffff8800c47ec010 00000000000137c0 00000000000137c0\n ffff8800c47edfd8 00000000000137c0 ffffffff82213020 ffff8800be4596b0\nCall Trace:\n [<ffffffff81101ee0>] ? __lock_page+0x70/0x70\n [<ffffffff81a0fdd9>] schedule+0x29/0x70\n [<ffffffff81a0fe80>] io_schedule+0x60/0x80\n [<ffffffff81101eee>] sleep_on_page+0xe/0x20\n [<ffffffff81a0e1ca>] __wait_on_bit_lock+0x5a/0xc0\n [<ffffffff81101ed7>] __lock_page+0x67/0x70\n [<ffffffff8106f750>] ? autoremove_wake_function+0x40/0x40\n [<ffffffff811867e6>] ? bio_add_page+0x36/0x40\n [<ffffffff8110b692>] set_page_dirty_lock+0x52/0x60\n [<ffffffff81186021>] bio_set_pages_dirty+0x51/0x70\n [<ffffffff8118c6b4>] do_blockdev_direct_IO+0xb24/0xeb0\n [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00\n [<ffffffff8118ca95>] __blockdev_direct_IO+0x55/0x60\n [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00\n [<ffffffff811e91c8>] ext3_direct_IO+0xf8/0x390\n [<ffffffff811e71a0>] ? ext3_get_blocks_handle+0xe00/0xe00\n [<ffffffff81004b60>] ? xen_mc_flush+0xb0/0x1b0\n [<ffffffff81104027>] generic_file_aio_read+0x737/0x780\n [<ffffffff813bedeb>] ? gnttab_map_refs+0x15b/0x1e0\n [<ffffffff811038f0>] ? find_get_pages+0x150/0x150\n [<ffffffff8119736c>] aio_rw_vect_retry+0x7c/0x1d0\n [<ffffffff811972f0>] ? lookup_ioctx+0x90/0x90\n [<ffffffff81198856>] aio_run_iocb+0x66/0x1a0\n [<ffffffff811998b8>] do_io_submit+0x708/0xb90\n [<ffffffff81199d50>] sys_io_submit+0x10/0x20\n [<ffffffff81a18d69>] system_call_fastpath+0x16/0x1b\n\nThe explanation is in the comment within the code:\n\nWe need to do this because the pages shared by the frontend\n(xen-blkfront) can be already locked (lock_page, called by\ndo_read_cache_page); when the userspace backend tries to use them\nwith direct_IO, mfn_to_pfn returns the pfn of the frontend, so\ndo_blockdev_direct_IO is going to try to lock the same pages\nagain resulting in a deadlock.\n\nA simplified call graph looks like this:\n\npygrub                          QEMU\n-----------------------------------------------\ndo_read_cache_page              io_submit\n  |                              |\nlock_page                       ext3_direct_IO\n                                 |\n                                bio_add_page\n                                 |\n                                lock_page\n\nInternally the xen-blkback uses m2p_add_override to swizzle (temporarily)\na 'struct page' to have a different MFN (so that it can point to another\nguest). It also can easily find out whether another pfn corresponding\nto the mfn exists in the m2p, and can set the FOREIGN bit\nin the p2m, making sure that mfn_to_pfn returns the pfn of the backend.\n\nThis allows the backend to perform direct_IO on these pages, but as a\nside effect prevents the frontend from using get_user_pages_fast on\nthem while they are being shared with the backend.\n\nSigned-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>\nSigned-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Stefano Stabellini",true],["8f6bfe1b62d33ba7223194b03689aa634c730e8d","bc7add126c2dbb8382bf1c28ac262b9363a32706@virtuousgeek.org","drm/i915: prefer wide & slow to fast & narrow in DP configs\n\ncommit 2514bc510d0c3aadcc5204056bb440fa36845147 upstream.\n\nHigh frequency link configurations have the potential to cause trouble\nwith long and/or cheap cables, so prefer slow and wide configurations\ninstead.  This patch has the potential to cause trouble for eDP\nconfigurations that lie about available lanes, so if we run into that we\ncan make it conditional on eDP.\n\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45801\nTested-by: peter@colberg.org\nSigned-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nCc: Jonathan Nieder <jrnieder@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jesse Barnes",true],["0e8864181f8dc108f6514da15e19c96c2d47a364","8384a109bf3dfa1b795fc2fbc8917dda6eac4e39@student.tuwien.ac.at","drm/nvd0/disp: mask off high 16 bit of negative cursor x-coordinate\n\ncommit af5e7d84b0ec45b2b614b0d6e3657cbdceaa21f9 upstream.\n\nSigned-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>\nSigned-off-by: Ben Skeggs <bskeggs@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Christoph Bumiller",true],["491bdad22a78a32507ffaad038bdb0e97e2b8123","c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","drm/i915: correctly order the ring init sequence\n\ncommit 0d8957c8a90bbb5d34fab9a304459448a5131e06 upstream.\n\nWe may only start to set up the new register values after having\nconfirmed that the ring is truely off. Otherwise the hw might lose the\nnewly written register values. This is caught later on in the init\nsequence, when we check whether the register writes have stuck.\n\nReviewed-by: Jani Nikula <jani.nikula@intel.com>\nBugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50522\nTested-by: Yang Guang <guang.a.yang@intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Daniel Vetter",true],["17552339cc87aaf7dfa81706127821060c1e887e","c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","drm/i915: ignore eDP bpc settings from vbt\n\ncommit 4344b813f105a19f793f1fd93ad775b784648b95 upstream.\n\nThis has originally been introduced to not oversubscribe the dp links\nin\n\ncommit 885a5fb5b120a5c7e0b3baad7b0feb5a89f76c18\nAuthor: Zhenyu Wang <zhenyuw@linux.intel.com>\nDate:   Tue Jan 12 05:38:31 2010 +0800\n\n    drm/i915: fix pixel color depth setting on eDP\n\nSince then we've fixed up the dp link bandwidth calculation code and\nshould now automatically fall back to 6bpc dithering. So this is\nunnecessary.\n\nFurthermore it seems to break the new MacbookPro with retina display,\nhence let's just rip this out.\n\nReported-by: Benoit Gschwind <gschwind@gnu-log.net>\nCc: Benoit Gschwind <gschwind@gnu-log.net>\nCc: Francois Rigaut <frigaut@gmail.com>\nTested-by: Benoit Gschwind <gschwind@gnu-log.net>\nTested-by: Bernhard Froemel <froemel at vmars tuwien.ac.at>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n\n--\n\nTesting feedback highgly welcome, and thanks for Benoit for finding\nout that the bpc computations are busted.\n-Daniel","Daniel Vetter",true],["d7edd347dc3783db4936941b25ffdbd91e872396","c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","drm/i915: reorder edp disabling to fix ivb MacBook Air\n\ncommit 35a38556d900b9cb5dfa2529c93944b847f8a8a4 upstream.\n\neDP is tons of fun. It turns out that at least the new MacBook Air 5,1\nmodel absolutely doesn't like the new force vdd dance we've introduced\nin\n\ncommit 6cb49835da0426f69a2931bc2a0a8156344b0e41\nAuthor: Daniel Vetter <daniel.vetter@ffwll.ch>\nDate:   Sun May 20 17:14:50 2012 +0200\n\n    drm/i915: enable vdd when switching off the eDP panel\n\nBut that patch also tried to fix some neat edp sequence issue with the\nforce_vdd timings. Closer inspection reveals that we've raised\nforce_vdd only to do the aux channel communication dp_sink_dpms. If we\nmove the edp_panel_off below that, we don't need any force_vdd for the\ndisable sequence, which makes the Air happy.\n\nUnfortunately the reporter of the original bug that the above commit\nfixed is travelling, so we can't test whether this regresses things.\nBut my theory is that since we don't check for any power-off ->\nforce_vdd-on delays in edp_panel_vdd_on, this was the actual\nroot-cause of this failure. With that force_vdd dance completely\neliminated, I'm hopeful the original bug stays fixed, too.\n\nFor reference the old bug, which hopefully doesn't get broken by this:\n\nhttps://bugzilla.kernel.org/show_bug.cgi?id=43163\n\nIn any case, regression fixers win over plain bugfixes, so this needs\nto go in asap.\n\nv2: The crucial pieces seems to be to clear the force_vdd flag\nuncoditionally, too, in edp_panel_off. Looks like this is left behind\nby the firmware somehow.\n\nv3: The Apple firmware seems to switch off the panel on it's own, hence\nwe still need to keep force_vdd on, but properly clear it when switching\nthe panel off.\n\nBugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=45671\nTested-by: Roberto Romer <sildurin@gmail.com>\nTested-by: Daniel Wagner <wagi@monom.org>\nTested-by: Keith Packard <keithp@keithp.com>\nCc: Keith Packard <keithp@keithp.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Daniel Vetter",true],["692c996798bf0c30ec908ea02643afc3d3cd58e5","08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","drm/radeon: properly handle crtc powergating\n\ncommit 6c0ae2ab85fc4a95cae82047a7db1f688a7737ab upstream.\n\nNeed to make sure the crtc is gated on before modesetting.\nExplicitly gate the crtc on in prepare() and set a flag\nso that the dpms functions don't gate it off during\nmode set.\n\nNoticed by sylware on IRC.\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alex Deucher",true],["06658834171058d47cade42fc206f7a59296691d","0620d428a1bd3756b1319066bf466b3b8be0b2b2@redhat.com","drm/radeon: do not reenable crtc after moving vram start address\n\ncommit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream.\n\nIt seems we can not update the crtc scanout address. After disabling\ncrtc, update to base address do not take effect after crtc being\nreenable leading to at least frame being scanout from the old crtc\nbase address. Disabling crtc display request lead to same behavior.\n\nSo after changing the vram address if we don't keep crtc disabled\nwe will have the GPU trying to read some random system memory address\nwith some iommu this will broke the crtc engine and will lead to\nbroken display and iommu error message.\n\nSo to avoid this, disable crtc. For flicker less boot we will need\nto avoid moving the vram start address.\n\nThis patch should also fix :\n\nhttps://bugs.freedesktop.org/show_bug.cgi?id=42373\n\nSigned-off-by: Jerome Glisse <jglisse@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Jerome Glisse",true],["065c16abd827f3966f1e8511d0aa71884b3cbd10","08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","drm/radeon: add some new SI pci ids\n\ncommit 2f292004dd1fb005788dc0a9cdd5559812ed866e upstream.\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alex Deucher",true],["25fc6d82d6f1bbb98bdbc495ded8fa4ee254a6fb","08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","drm/radeon: fix bank tiling parameters on cayman\n\ncommit 5b23c9045a8b61352986270b2d109edf5085e113 upstream.\n\nHandle the 16 bank case.\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alex Deucher",true],["e01774cb717834b5888cf7bab9af08ecbf9f9657","08dc22c6156113f2deff178e35e3ed9b24d6af9e@amd.com","drm/radeon: fix bank tiling parameters on evergreen\n\ncommit c8d15edc17d836686d1f071e564800e1a2724fa6 upstream.\n\nHandle the 16 bank case.\n\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Alex Deucher",true],["348b19d5c556cf8e6baed4ccf54164a0b06dba9c","4ed386e0495d3e109932df055831d9ec2f824927@mit.edu","ext4: make sure the journal sb is written in ext4_clear_journal_err()\n\ncommit d796c52ef0b71a988364f6109aeb63d79c5b116b upstream.\n\nAfter we transfer set the EXT4_ERROR_FS bit in the file system\nsuperblock, it's not enough to call jbd2_journal_clear_err() to clear\nthe error indication from journal superblock --- we need to call\njbd2_journal_update_sb_errno() as well.  Otherwise, when the root file\nsystem is mounted read-only, the journal is replayed, and the error\nindicator is transferred to the superblock --- but the s_errno field\nin the jbd2 superblock is left set (since although we cleared it in\nmemory, we never flushed it out to disk).\n\nThis can end up confusing e2fsck.  We should make e2fsck more robust\nin this case, but the kernel shouldn't be leaving things in this\nconfused state, either.\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Theodore Ts'o",true],["4d33574ecd1e50de7e11bdf9e0e32ff243a0d59c","4ed386e0495d3e109932df055831d9ec2f824927@mit.edu","ext4: avoid kmemcheck complaint from reading uninitialized memory\n\ncommit 7e731bc9a12339f344cddf82166b82633d99dd86 upstream.\n\nCommit 03179fe923 introduced a kmemcheck complaint in\next4_da_get_block_prep() because we save and restore\nei->i_da_metadata_calc_last_lblock even though it is left\nuninitialized in the case where i_da_metadata_calc_len is zero.\n\nThis doesn't hurt anything, but silencing the kmemcheck complaint\nmakes it easier for people to find real bugs.\n\nAddresses https://bugzilla.kernel.org/show_bug.cgi?id=45631\n(which is marked as a regression).\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Theodore Ts'o",true],["3b54eef10128b5bf77ff6463884c5727a8d765bb","4ed386e0495d3e109932df055831d9ec2f824927@mit.edu","ext4: fix long mount times on very big file systems\n\ncommit 0548bbb85337e532ca2ed697c3e9b227ff2ed4b4 upstream.\n\nCommit 8aeb00ff85a: \"ext4: fix overhead calculation used by\next4_statfs()\" introduced a O(n**2) calculation which makes very large\nfile systems take forever to mount.  Fix this with an optimization for\nnon-bigalloc file systems.  (For bigalloc file systems the overhead\nneeds to be set in the the superblock.)\n\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Theodore Ts'o",true],["0c6648a098460659bf88160abdbd9cf4a2b41fbd","4ed386e0495d3e109932df055831d9ec2f824927@mit.edu","ext4: fix kernel BUG on large-scale rm -rf commands\n\ncommit 89a4e48f8479f8145eca9698f39fe188c982212f upstream.\n\nCommit 968dee7722: \"ext4: fix hole punch failure when depth is greater\nthan 0\" introduced a regression in v3.5.1/v3.6-rc1 which caused kernel\ncrashes when users ran run \"rm -rf\" on large directory hierarchy on\next4 filesystems on RAID devices:\n\n    BUG: unable to handle kernel NULL pointer dereference at 0000000000000028\n\n    Process rm (pid: 18229, threadinfo ffff8801276bc000, task ffff880123631710)\n    Call Trace:\n     [<ffffffff81236483>] ? __ext4_handle_dirty_metadata+0x83/0x110\n     [<ffffffff812353d3>] ext4_ext_truncate+0x193/0x1d0\n     [<ffffffff8120a8cf>] ? ext4_mark_inode_dirty+0x7f/0x1f0\n     [<ffffffff81207e05>] ext4_truncate+0xf5/0x100\n     [<ffffffff8120cd51>] ext4_evict_inode+0x461/0x490\n     [<ffffffff811a1312>] evict+0xa2/0x1a0\n     [<ffffffff811a1513>] iput+0x103/0x1f0\n     [<ffffffff81196d84>] do_unlinkat+0x154/0x1c0\n     [<ffffffff8118cc3a>] ? sys_newfstatat+0x2a/0x40\n     [<ffffffff81197b0b>] sys_unlinkat+0x1b/0x50\n     [<ffffffff816135e9>] system_call_fastpath+0x16/0x1b\n    Code: 8b 4d 20 0f b7 41 02 48 8d 04 40 48 8d 04 81 49 89 45 18 0f b7 49 02 48 83 c1 01 49 89 4d 00 e9 ae f8 ff ff 0f 1f 00 49 8b 45 28 <48> 8b 40 28 49 89 45 20 e9 85 f8 ff ff 0f 1f 80 00 00 00\n\n    RIP  [<ffffffff81233164>] ext4_ext_remove_space+0xa34/0xdf0\n\nThis could be reproduced as follows:\n\nThe problem in commit 968dee7722 was that caused the variable 'i' to\nbe left uninitialized if the truncate required more space than was\navailable in the journal.  This resulted in the function\next4_ext_truncate_extend_restart() returning -EAGAIN, which caused\next4_ext_remove_space() to restart the truncate operation after\nstarting a new jbd2 handle.\n\nReported-by: Maciej Żenczykowski <maze@google.com>\nReported-by: Marti Raudsepp <marti@juffo.org>\nTested-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: \"Theodore Ts'o\" <tytso@mit.edu>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Theodore Ts'o",true],["9fff5269855ff0dc33e8c54cbe7ec78a14bc7071","d4c4fc5069677be84f589aa6e14eedffef9ba12f@linux.intel.com","xhci: Add Etron XHCI_TRUST_TX_LENGTH quirk.\n\ncommit 5cb7df2b2d3afee7638b3ef23a5bcb89c6f07bd9 upstream.\n\nGary reports that with recent kernels, he notices more xHCI driver\nwarnings:\n\nxhci_hcd 0000:03:00.0: WARN Successful completion on short TX: needs XHCI_TRUST_TX_LENGTH quirk?\n\nWe think his Etron xHCI host controller may have the same buggy behavior\nas the Fresco Logic xHCI host.  When a short transfer is received, the\nhost will mark the transfer as successfully completed when it should be\nmarking it with a short completion.\n\nFix this by turning on the XHCI_TRUST_TX_LENGTH quirk when the Etron\nhost is discovered.  Note that Gary has revision 1, but if Etron fixes\nthis bug in future revisions, the quirk will have no effect.\n\nThis patch should be backported to kernels as old as 2.6.36, that\ncontain a backported version of commit\n1530bbc6272d9da1e39ef8e06190d42c13a02733 \"xhci: Add new short TX quirk\nfor Fresco Logic host.\"\n\nSigned-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>\nReported-by: Gary E. Miller <gem@rellim.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","Sarah Sharp",true]],"size":116,"ref":"refs/heads/cm-11.0","head":"c71c3d2f8ddc7ad4eca3ea119ac1fba839441190"}