{"push_id":1170033431,"size":305,"distinct_size":6,"ref":"refs/heads/caf/aosp-common/android-3.10.y","head":"ed22006fa63c2e15726d7bdbce12d67c15213ad2","before":"0c9920135c36436975e6a64d0c4c411697a62eb7","commits":[{"sha":"a907d8a3929043f4544a4cffc0328c351bec4398","author":{"name":"Chen LinX","email":"5a37d5fca7f0b36619f991a82a26ae65ed400920@intel.com"},"message":"mm/pagewalk.c: fix walk_page_range() access of wrong PTEs\n\ncommit 3017f079efd6af199b0852b5c425364513db460e upstream.\n\nWhen walk_page_range walk a memory map's page tables, it'll skip\nVM_PFNMAP area, then variable 'next' will to assign to vma->vm_end, it\nmaybe larger than 'end'.  In next loop, 'addr' will be larger than\n'next'.  Then in /proc/XXXX/pagemap file reading procedure, the 'addr'\nwill growing forever in pagemap_pte_range, pte_to_pagemap_entry will\naccess the wrong pte.\n\n  BUG: Bad page map in process procrank  pte:8437526f pmd:785de067\n  addr:9108d000 vm_flags:00200073 anon_vma:f0d99020 mapping:  (null) index:9108d\n  CPU: 1 PID: 4974 Comm: procrank Tainted: G    B   W  O 3.10.1+ #1\n  Call Trace:\n    dump_stack+0x16/0x18\n    print_bad_pte+0x114/0x1b0\n    vm_normal_page+0x56/0x60\n    pagemap_pte_range+0x17a/0x1d0\n    walk_page_range+0x19e/0x2c0\n    pagemap_read+0x16e/0x200\n    vfs_read+0x84/0x150\n    SyS_read+0x4a/0x80\n    syscall_call+0x7/0xb\n\nSigned-off-by: Liu ShuoX <shuox.liu@intel.com>\nSigned-off-by: Chen LinX <linx.z.chen@intel.com>\nAcked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>\nReviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.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":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/a907d8a3929043f4544a4cffc0328c351bec4398"},{"sha":"231e2be621c3b5823f3f8bed6c10785df1b4a476","author":{"name":"Mark Salyzyn","email":"4814ffc71be21311f04ef34122c19152acc840c4@google.com"},"message":"android: recommended.cfg: enable taskstats\n\nCONFIG_TASKSTATS=y\nCONFIG_TASK_DELAY_ACCT=y\nCONFIG_TASK_XACCT=y\nCONFIG_TASK_IO_ACCOUNTING=y\n\nSigned-off-by: Mark Salyzyn <salyzyn@google.com>\nBug: 21334988\nBug: 26966375\nChange-Id: I17b097ae4ea6c63c2e9fddd9544e3f06d49b609d","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/231e2be621c3b5823f3f8bed6c10785df1b4a476"},{"sha":"c22e479e335628ce8766cfbf06e2ba17e8f9a1bb","author":{"name":"H. Peter Anvin","email":"2dad3f7077c675f93d9f139c5cc03297031ec6b0@linux.intel.com"},"message":"x86-32, espfix: Remove filter for espfix32 due to race\n\ncommit 246f2d2ee1d715e1077fc47d61c394569c8ee692 upstream.\n\nIt is not safe to use LAR to filter when to go down the espfix path,\nbecause the LDT is per-process (rather than per-thread) and another\nthread might change the descriptors behind our back.  Fortunately it\nis always *safe* (if a bit slow) to go down the espfix path, and a\n32-bit LDT stack segment is extremely rare.\n\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nLink: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/c22e479e335628ce8766cfbf06e2ba17e8f9a1bb"},{"sha":"1b627d4e5e61e89b840f77abb3ca6711ad6ffbeb","author":{"name":"H. Peter Anvin","email":"2dad3f7077c675f93d9f139c5cc03297031ec6b0@linux.intel.com"},"message":"x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack\n\ncommit 3891a04aafd668686239349ea58f3314ea2af86b upstream.\n\nThe IRET instruction, when returning to a 16-bit segment, only\nrestores the bottom 16 bits of the user space stack pointer.  This\ncauses some 16-bit software to break, but it also leaks kernel state\nto user space.  We have a software workaround for that (\"espfix\") for\nthe 32-bit kernel, but it relies on a nonzero stack segment base which\nis not available in 64-bit mode.\n\nIn checkin:\n\n    b3b42ac2cbae x86-64, modify_ldt: Ban 16-bit segments on 64-bit kernels\n\nwe \"solved\" this by forbidding 16-bit segments on 64-bit kernels, with\nthe logic that 16-bit support is crippled on 64-bit kernels anyway (no\nV86 support), but it turns out that people are doing stuff like\nrunning old Win16 binaries under Wine and expect it to work.\n\nThis works around this by creating percpu \"ministacks\", each of which\nis mapped 2^16 times 64K apart.  When we detect that the return SS is\non the LDT, we copy the IRET frame to the ministack and use the\nrelevant alias to return to userspace.  The ministacks are mapped\nreadonly, so if IRET faults we promote #GP to #DF which is an IST\nvector and thus has its own stack; we then do the fixup in the #DF\nhandler.\n\n(Making #GP an IST exception would make the msr_safe functions unsafe\nin NMI/MC context, and quite possibly have other effects.)\n\nSpecial thanks to:\n\n- Andy Lutomirski, for the suggestion of using very small stack slots\n  and copy (as opposed to map) the IRET frame there, and for the\n  suggestion to mark them readonly and let the fault promote to #DF.\n- Konrad Wilk for paravirt fixup and testing.\n- Borislav Petkov for testing help and useful comments.\n\nReported-by: Brian Gerst <brgerst@gmail.com>\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nLink: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com\nCc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nCc: Borislav Petkov <bp@alien8.de>\nCc: Andrew Lutomriski <amluto@gmail.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Dirk Hohndel <dirk@hohndel.org>\nCc: Arjan van de Ven <arjan.van.de.ven@intel.com>\nCc: comex <comexk@gmail.com>\nCc: Alexander van Heukelum <heukelum@fastmail.fm>\nCc: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/1b627d4e5e61e89b840f77abb3ca6711ad6ffbeb"},{"sha":"4c941665c7368a34b146929b31949555e680a4ee","author":{"name":"H. Peter Anvin","email":"2dad3f7077c675f93d9f139c5cc03297031ec6b0@linux.intel.com"},"message":"x86, espfix: Move espfix definitions into a separate header file\n\ncommit e1fe9ed8d2a4937510d0d60e20705035c2609aea upstream.\n\nSparse warns that the percpu variables aren't declared before they are\ndefined.  Rather than hacking around it, move espfix definitions into\na proper header file.\n\nReported-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/4c941665c7368a34b146929b31949555e680a4ee"},{"sha":"758f0dac9104b46016af98304656a0268ac3e105","author":{"name":"H. Peter Anvin","email":"2dad3f7077c675f93d9f139c5cc03297031ec6b0@linux.intel.com"},"message":"x86, espfix: Fix broken header guard\n\ncommit 20b68535cd27183ebd3651ff313afb2b97dac941 upstream.\n\nHeader guard is #ifndef, not #ifdef...\n\nReported-by: Fengguang Wu <fengguang.wu@intel.com>\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/758f0dac9104b46016af98304656a0268ac3e105"},{"sha":"44d057a37868a60bc2eb6e7d1dcea701f234d56a","author":{"name":"H. Peter Anvin","email":"2dad3f7077c675f93d9f139c5cc03297031ec6b0@zytor.com"},"message":"x86, espfix: Make espfix64 a Kconfig option, fix UML\n\ncommit 197725de65477bc8509b41388157c1a2283542bb upstream.\n\nMake espfix64 a hidden Kconfig option.  This fixes the x86-64 UML\nbuild which had broken due to the non-existence of init_espfix_bsp()\nin UML: since UML uses its own Kconfig, this option does not appear in\nthe UML build.\n\nThis also makes it possible to make support for 16-bit segments a\nconfiguration option, for the people who want to minimize the size of\nthe kernel.\n\nReported-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: H. Peter Anvin <hpa@zytor.com>\nCc: Richard Weinberger <richard@nod.at>\nLink: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/44d057a37868a60bc2eb6e7d1dcea701f234d56a"},{"sha":"b9b9f908c8ae82b73b9d75181982028b6bc06c2b","author":{"name":"H. Peter Anvin","email":"2dad3f7077c675f93d9f139c5cc03297031ec6b0@zytor.com"},"message":"x86, espfix: Make it possible to disable 16-bit support\n\ncommit 34273f41d57ee8d854dcd2a1d754cbb546cb548f upstream.\n\nEmbedded systems, which may be very memory-size-sensitive, are\nextremely unlikely to ever encounter any 16-bit software, so make it\na CONFIG_EXPERT option to turn off support for any 16-bit software\nwhatsoever.\n\nSigned-off-by: H. Peter Anvin <hpa@zytor.com>\nLink: http://lkml.kernel.org/r/1398816946-3351-1-git-send-email-hpa@linux.intel.com\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/b9b9f908c8ae82b73b9d75181982028b6bc06c2b"},{"sha":"e068734f9e7344997a61022629b92d142a985ab3","author":{"name":"Andy Lutomirski","email":"3cb7d5a8804519b67b2d7945dee31e85c91c02f9@amacapital.net"},"message":"x86_64/entry/xen: Do not invoke espfix64 on Xen\n\ncommit 7209a75d2009dbf7745e2fd354abf25c3deb3ca3 upstream.\n\nThis moves the espfix64 logic into native_iret.  To make this work,\nit gets rid of the native patch for INTERRUPT_RETURN:\nINTERRUPT_RETURN on native kernels is now 'jmp native_iret'.\n\nThis changes the 16-bit SS behavior on Xen from OOPSing to leaking\nsome bits of the Xen hypervisor's RSP (I think).\n\n[ hpa: this is a nonzero cost on native, but probably not enough to\n  measure. Xen needs to fix this in their own code, probably doing\n  something equivalent to espfix64. ]\n\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nLink: http://lkml.kernel.org/r/7b8f1d8ef6597cb16ae004a43c56980a7de3cf94.1406129132.git.luto@amacapital.net\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/e068734f9e7344997a61022629b92d142a985ab3"},{"sha":"fdc6c1052bc7d89a5826904fbb4318677e8442ce","author":{"name":"Boris Ostrovsky","email":"8d8eed10c3f35eaa3a548daad1882614e248ed99@oracle.com"},"message":"x86/espfix/xen: Fix allocation of pages for paravirt page tables\n\ncommit 8762e5092828c4dc0f49da5a47a644c670df77f3 upstream.\n\ninit_espfix_ap() is currently off by one level when informing hypervisor\nthat allocated pages will be used for ministacks' page tables.\n\nThe most immediate effect of this on a PV guest is that if\n'stack_page = __get_free_page()' returns a non-zeroed-out page the hypervisor\nwill refuse to use it for a page table (which it shouldn't be anyway). This will\nresult in warnings by both Xen and Linux.\n\nMore importantly, a subsequent write to that page (again, by a PV guest) is\nlikely to result in fatal page fault.\n\nSigned-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>\nLink: http://lkml.kernel.org/r/1404926298-5565-1-git-send-email-boris.ostrovsky@oracle.com\nReviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nSigned-off-by: H. Peter Anvin <hpa@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/fdc6c1052bc7d89a5826904fbb4318677e8442ce"},{"sha":"211d59c0034ec9d88690c750ccd6da27f6952dc5","author":{"name":"Andy Lutomirski","email":"3cb7d5a8804519b67b2d7945dee31e85c91c02f9@amacapital.net"},"message":"x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C\n\ncommit af726f21ed8af2cdaa4e93098dc211521218ae65 upstream.\n\nThere's nothing special enough about the espfix64 double fault fixup to\njustify writing it in assembly.  Move it to C.\n\nThis also fixes a bug: if the double fault came from an IST stack, the\nold asm code would return to a partially uninitialized stack frame.\n\nFixes: 3891a04aafd668686239349ea58f3314ea2af86b\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nReviewed-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/211d59c0034ec9d88690c750ccd6da27f6952dc5"},{"sha":"c9e31d5a4747e9967ace6d05896c78516c4c0850","author":{"name":"Andy Lutomirski","email":"3cb7d5a8804519b67b2d7945dee31e85c91c02f9@amacapital.net"},"message":"x86_64, traps: Stop using IST for #SS\n\ncommit 6f442be2fb22be02cafa606f1769fa1e6f894441 upstream.\n\nOn a 32-bit kernel, this has no effect, since there are no IST stacks.\n\nOn a 64-bit kernel, #SS can only happen in user code, on a failed iret\nto user space, a canonical violation on access via RSP or RBP, or a\ngenuine stack segment violation in 32-bit kernel code.  The first two\ncases don't need IST, and the latter two cases are unlikely fatal bugs,\nand promoting them to double faults would be fine.\n\nThis fixes a bug in which the espfix64 code mishandles a stack segment\nviolation.\n\nThis saves 4k of memory per CPU and a tiny bit of code.\n\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nReviewed-by: Thomas Gleixner <tglx@linutronix.de>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/c9e31d5a4747e9967ace6d05896c78516c4c0850"},{"sha":"e01834bfbafd25fd392bf10014451c4e5f34f829","author":{"name":"Andy Lutomirski","email":"3cb7d5a8804519b67b2d7945dee31e85c91c02f9@amacapital.net"},"message":"x86/tls: Validate TLS entries to protect espfix\n\ncommit 41bdc78544b8a93a9c6814b8bbbfef966272abbe upstream.\n\nInstalling a 16-bit RW data segment into the GDT defeats espfix.\nAFAICT this will not affect glibc, Wine, or dosemu at all.\n\nSigned-off-by: Andy Lutomirski <luto@amacapital.net>\nAcked-by: H. Peter Anvin <hpa@zytor.com>\nCc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Willy Tarreau <w@1wt.eu>\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/e01834bfbafd25fd392bf10014451c4e5f34f829"},{"sha":"1d0f72986958c2bf3528cadf7d7acf0771465fd1","author":{"name":"Mark Salyzyn","email":"4814ffc71be21311f04ef34122c19152acc840c4@google.com"},"message":"android: base-cfg: Add CONFIG_IP_MULTICAST\n\nSigned-off-by: Mark Salyzyn <salyzyn@google.com>\nBug: 19173869\nChange-Id: I882b4b8f44b62b668bb03dae0858739868bd953a","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/1d0f72986958c2bf3528cadf7d7acf0771465fd1"},{"sha":"5704b3088119471d57f78350f1dcbcd420ba0a73","author":{"name":"Mikulas Patocka","email":"a2da12c8268d5a95fc65964f0061e0e46206d68d@redhat.com"},"message":"UPSTREAM: dm crypt: fix cpu hotplug crash by removing per-cpu structure\n\n(cherry pick from commit 610f2de3559c383caf8fbbf91e9968102dff7ca0)\n\nThe DM crypt target used per-cpu structures to hold pointers to a\nablkcipher_request structure.  The code assumed that the work item keeps\nexecuting on a single CPU, so it didn't use synchronization when\naccessing this structure.\n\nIf a CPU is disabled by writing 0 to /sys/devices/system/cpu/cpu*/online,\nthe work item could be moved to another CPU.  This causes dm-crypt\ncrashes, like the following, because the code starts using an incorrect\nablkcipher_request:\n\n smpboot: CPU 7 is now offline\n BUG: unable to handle kernel NULL pointer dereference at 0000000000000130\n IP: [<ffffffffa1862b3d>] crypt_convert+0x12d/0x3c0 [dm_crypt]\n ...\n Call Trace:\n  [<ffffffffa1864415>] ? kcryptd_crypt+0x305/0x470 [dm_crypt]\n  [<ffffffff81062060>] ? finish_task_switch+0x40/0xc0\n  [<ffffffff81052a28>] ? process_one_work+0x168/0x470\n  [<ffffffff8105366b>] ? worker_thread+0x10b/0x390\n  [<ffffffff81053560>] ? manage_workers.isra.26+0x290/0x290\n  [<ffffffff81058d9f>] ? kthread+0xaf/0xc0\n  [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120\n  [<ffffffff813464ac>] ? ret_from_fork+0x7c/0xb0\n  [<ffffffff81058cf0>] ? kthread_create_on_node+0x120/0x120\n\nFix this bug by removing the per-cpu definition.  The structure\nablkcipher_request is accessed via a pointer from convert_context.\nConsequently, if the work item is rescheduled to a different CPU, the\nthread still uses the same ablkcipher_request.\n\nThis change may undermine performance improvements intended by commit\nc0297721 (\"dm crypt: scale to multiple cpus\") on select hardware.  In\npractice no performance difference was observed on recent hardware.  But\nregardless, correctness is more important than performance.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nCc: stable@vger.kernel.org\nBug: 25392275\nChange-Id: I71cdd048243e89048d21b51ce31ffaca9a090d1d","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/5704b3088119471d57f78350f1dcbcd420ba0a73"},{"sha":"62d579425b16cf21174e86d871f16ab576ab63f6","author":{"name":"Mikulas Patocka","email":"a2da12c8268d5a95fc65964f0061e0e46206d68d@redhat.com"},"message":"UPSTREAM: dm crypt: use per-bio data\n\n(cherry pick from commit 298a9fa08a1577211d42a75e8fc073baef61e0d9)\n\nChange dm-crypt so that it uses auxiliary data allocated with the bio.\n\nDm-crypt requires two allocations per request - struct dm_crypt_io and\nstruct ablkcipher_request (with other data appended to it).  It\npreviously only used mempool allocations.\n\nSome requests may require more dm_crypt_ios and ablkcipher_requests,\nhowever most requests need just one of each of these two structures to\ncomplete.\n\nThis patch changes it so that the first dm_crypt_io and ablkcipher_request\nare allocated with the bio (using target per_bio_data_size option).  If\nthe request needs additional values, they are allocated from the mempool.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nBug: 25392275\nChange-Id: I3cd958002f417ef6c6954aa2bd247b89b05109e3","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/62d579425b16cf21174e86d871f16ab576ab63f6"},{"sha":"63fa0d9fe5f9ade466e928fb52110e3419af29dd","author":{"name":"Mikulas Patocka","email":"a2da12c8268d5a95fc65964f0061e0e46206d68d@redhat.com"},"message":"UPSTREAM: dm crypt: fix access beyond the end of allocated space\n\n(cherry pick from commit d49ec52ff6ddcda178fc2476a109cf1bd1fa19ed)\n\nThe DM crypt target accesses memory beyond allocated space resulting in\na crash on 32 bit x86 systems.\n\nThis bug is very old (it dates back to 2.6.25 commit 3a7f6c990ad04 \"dm\ncrypt: use async crypto\").  However, this bug was masked by the fact\nthat kmalloc rounds the size up to the next power of two.  This bug\nwasn't exposed until 3.17-rc1 commit 298a9fa08a (\"dm crypt: use per-bio\ndata\").  By switching to using per-bio data there was no longer any\npadding beyond the end of a dm-crypt allocated memory block.\n\nTo minimize allocation overhead dm-crypt puts several structures into one\nblock allocated with kmalloc.  The block holds struct ablkcipher_request,\ncipher-specific scratch pad (crypto_ablkcipher_reqsize(any_tfm(cc))),\nstruct dm_crypt_request and an initialization vector.\n\nThe variable dmreq_start is set to offset of struct dm_crypt_request\nwithin this memory block.  dm-crypt allocates the block with this size:\ncc->dmreq_start + sizeof(struct dm_crypt_request) + cc->iv_size.\n\nWhen accessing the initialization vector, dm-crypt uses the function\niv_of_dmreq, which performs this calculation: ALIGN((unsigned long)(dmreq\n+ 1), crypto_ablkcipher_alignmask(any_tfm(cc)) + 1).\n\ndm-crypt allocated \"cc->iv_size\" bytes beyond the end of dm_crypt_request\nstructure.  However, when dm-crypt accesses the initialization vector, it\ntakes a pointer to the end of dm_crypt_request, aligns it, and then uses\nit as the initialization vector.  If the end of dm_crypt_request is not\naligned on a crypto_ablkcipher_alignmask(any_tfm(cc)) boundary the\nalignment causes the initialization vector to point beyond the allocated\nspace.\n\nFix this bug by calculating the variable iv_size_padding and adding it\nto the allocated size.\n\nAlso correct the alignment of dm_crypt_request.  struct dm_crypt_request\nis specific to dm-crypt (it isn't used by the crypto subsystem at all),\nso it is aligned on __alignof__(struct dm_crypt_request).\n\nAlso align per_bio_data_size on ARCH_KMALLOC_MINALIGN, so that it is\naligned as if the block was allocated with kmalloc.\n\nReported-by: Krzysztof Kolasa <kkolasa@winsoft.pl>\nTested-by: Milan Broz <gmazyland@gmail.com>\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nBug: 25392275\nChange-Id: I282c827d95a3913d56bbf3b14b583ef0b62e0890","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/63fa0d9fe5f9ade466e928fb52110e3419af29dd"},{"sha":"1715ace1f17282dc109d2bef30ade4a861b1b85d","author":{"name":"Mikulas Patocka","email":"a2da12c8268d5a95fc65964f0061e0e46206d68d@redhat.com"},"message":"BACKPORT: dm crypt: don't allocate pages for a partial request\n\n(cherry pick from commit cf2f1abfbd0dba701f7f16ef619e4d2485de3366)\n\nChange crypt_alloc_buffer so that it only ever allocates pages for a\nfull request.  This is a prerequisite for the commit \"dm crypt: offload\nwrites to thread\".\n\nThis change simplifies the dm-crypt code at the expense of reduced\nthroughput in low memory conditions (where allocation for a partial\nrequest is most useful).\n\nNote: the next commit (\"dm crypt: avoid deadlock in mempools\") is needed\nto fix a theoretical deadlock.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nBug: 25392275\nChange-Id: I4f2f7c5b7c85f119bf5cfd88505df31f6e39038c","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/1715ace1f17282dc109d2bef30ade4a861b1b85d"},{"sha":"4bf3a05314c3ef8fd93d648672ef740f7ed3ac35","author":{"name":"Mikulas Patocka","email":"a2da12c8268d5a95fc65964f0061e0e46206d68d@redhat.com"},"message":"UPSTREAM: dm crypt: avoid deadlock in mempools\n\n(cherry pick from commit 7145c241a1bf2841952c3e297c4080b357b3e52d)\n\nFix a theoretical deadlock introduced in the previous commit (\"dm crypt:\ndon't allocate pages for a partial request\").\n\nThe function crypt_alloc_buffer may be called concurrently.  If we allocate\nfrom the mempool concurrently, there is a possibility of deadlock.  For\nexample, if we have mempool of 256 pages, two processes, each wanting\n256, pages allocate from the mempool concurrently, it may deadlock in a\nsituation where both processes have allocated 128 pages and the mempool\nis exhausted.\n\nTo avoid such a scenario we allocate the pages under a mutex.  In order\nto not degrade performance with excessive locking, we try non-blocking\nallocations without a mutex first and if that fails, we fallback to a\nblocking allocations with a mutex.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nBug: 25392275\nChange-Id: I2e9c0f79ddf08e88854f5b8d6be61719e4e180a8","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/4bf3a05314c3ef8fd93d648672ef740f7ed3ac35"},{"sha":"d0349e35db0afad187f8ed330f57bb280ffce2fb","author":{"name":"Mikulas Patocka","email":"a2da12c8268d5a95fc65964f0061e0e46206d68d@redhat.com"},"message":"UPSTREAM: dm crypt: remove unused io_pool and _crypt_io_pool\n\n(cherry pick from commit 94f5e0243c48aa01441c987743dc468e2d6eaca2)\n\nThe previous commit (\"dm crypt: don't allocate pages for a partial\nrequest\") stopped using the io_pool slab mempool and backing\n_crypt_io_pool kmem cache.\n\nSigned-off-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nBug: 25392275\nChange-Id: Iec140bb5b032b2abfa30bef7d55978165e8df43d","distinct":false,"url":"https://api.github.com/repos/Rashed97/caf-kernel-msm-3.10/commits/d0349e35db0afad187f8ed330f57bb280ffce2fb"}]}
{"actor":{"display_login":"Rashed97"}}