{"push_id":1350916928,"size":1000,"distinct_size":0,"ref":"refs/heads/linaro-landing-teams/release/qcomlt-4.4","head":"4fffd62d74b4db1163b32800976086771a1924ae","before":"39e4628ed229e152c1d2b252f28c73975a7962da","commits":[{"sha":"4185bd68ef40b275669efec624c0d792cd7a2acf","author":{"name":"Nitin Gupta","email":"13607b8368a47c13f452385a577ae5bc2f8e67a6@oracle.com"},"message":"sparc64: Fix numa node distance initialization\n\n[ Upstream commit 36beca6571c941b28b0798667608239731f9bc3a ]\n\nOrabug: 22495713\n\nCurrently, NUMA node distance matrix is initialized only\nwhen a machine descriptor (MD) exists. However, sun4u\nmachines (e.g. Sun Blade 2500) do not have an MD and thus\ndistance values were left uninitialized. The initialization\nis now moved such that it happens on both sun4u and sun4v.\n\nSigned-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>\nTested-by: Mikael Pettersson <mikpelinux@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/4185bd68ef40b275669efec624c0d792cd7a2acf"},{"sha":"b1206090828584bcb1caf4c850d175f297eb7bc8","author":{"name":"David S. Miller","email":"79caf591e37e1438a2d55ae59670d5cd0d717764@davemloft.net"},"message":"sparc64: Fix sparc64_set_context stack handling.\n\n[ Upstream commit 397d1533b6cce0ccb5379542e2e6d079f6936c46 ]\n\nLike a signal return, we should use synchronize_user_stack() rather\nthan flush_user_windows().\n\nReported-by: Ilya Malakhov <ilmalakhovthefirst@gmail.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/b1206090828584bcb1caf4c850d175f297eb7bc8"},{"sha":"ccd02310db44df820d1e8c54a97daf596dea1c9e","author":{"name":"Babu Moger","email":"15a2237ccdb53fe62f6746d1a8145deb535c49a8@oracle.com"},"message":"sparc/PCI: Fix for panic while enabling SR-IOV\n\n[ Upstream commit d0c31e02005764dae0aab130a57e9794d06b824d ]\n\nWe noticed this panic while enabling SR-IOV in sparc.\n\nmlx4_core: Mellanox ConnectX core driver v2.2-1 (Jan  1 2015)\nmlx4_core: Initializing 0007:01:00.0\nmlx4_core 0007:01:00.0: Enabling SR-IOV with 5 VFs\nmlx4_core: Initializing 0007:01:00.1\nUnable to handle kernel NULL pointer dereference\ninsmod(10010): Oops [#1]\nCPU: 391 PID: 10010 Comm: insmod Not tainted\n\t\t4.1.12-32.el6uek.kdump2.sparc64 #1\nTPC: <dma_supported+0x20/0x80>\nI7: <__mlx4_init_one+0x324/0x500 [mlx4_core]>\nCall Trace:\n [00000000104c5ea4] __mlx4_init_one+0x324/0x500 [mlx4_core]\n [00000000104c613c] mlx4_init_one+0xbc/0x120 [mlx4_core]\n [0000000000725f14] local_pci_probe+0x34/0xa0\n [0000000000726028] pci_call_probe+0xa8/0xe0\n [0000000000726310] pci_device_probe+0x50/0x80\n [000000000079f700] really_probe+0x140/0x420\n [000000000079fa24] driver_probe_device+0x44/0xa0\n [000000000079fb5c] __device_attach+0x3c/0x60\n [000000000079d85c] bus_for_each_drv+0x5c/0xa0\n [000000000079f588] device_attach+0x88/0xc0\n [000000000071acd0] pci_bus_add_device+0x30/0x80\n [0000000000736090] virtfn_add.clone.1+0x210/0x360\n [00000000007364a4] sriov_enable+0x2c4/0x520\n [000000000073672c] pci_enable_sriov+0x2c/0x40\n [00000000104c2d58] mlx4_enable_sriov+0xf8/0x180 [mlx4_core]\n [00000000104c49ac] mlx4_load_one+0x42c/0xd40 [mlx4_core]\nDisabling lock debugging due to kernel taint\nCaller[00000000104c5ea4]: __mlx4_init_one+0x324/0x500 [mlx4_core]\nCaller[00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core]\nCaller[0000000000725f14]: local_pci_probe+0x34/0xa0\nCaller[0000000000726028]: pci_call_probe+0xa8/0xe0\nCaller[0000000000726310]: pci_device_probe+0x50/0x80\nCaller[000000000079f700]: really_probe+0x140/0x420\nCaller[000000000079fa24]: driver_probe_device+0x44/0xa0\nCaller[000000000079fb5c]: __device_attach+0x3c/0x60\nCaller[000000000079d85c]: bus_for_each_drv+0x5c/0xa0\nCaller[000000000079f588]: device_attach+0x88/0xc0\nCaller[000000000071acd0]: pci_bus_add_device+0x30/0x80\nCaller[0000000000736090]: virtfn_add.clone.1+0x210/0x360\nCaller[00000000007364a4]: sriov_enable+0x2c4/0x520\nCaller[000000000073672c]: pci_enable_sriov+0x2c/0x40\nCaller[00000000104c2d58]: mlx4_enable_sriov+0xf8/0x180 [mlx4_core]\nCaller[00000000104c49ac]: mlx4_load_one+0x42c/0xd40 [mlx4_core]\nCaller[00000000104c5f90]: __mlx4_init_one+0x410/0x500 [mlx4_core]\nCaller[00000000104c613c]: mlx4_init_one+0xbc/0x120 [mlx4_core]\nCaller[0000000000725f14]: local_pci_probe+0x34/0xa0\nCaller[0000000000726028]: pci_call_probe+0xa8/0xe0\nCaller[0000000000726310]: pci_device_probe+0x50/0x80\nCaller[000000000079f700]: really_probe+0x140/0x420\nCaller[000000000079fa24]: driver_probe_device+0x44/0xa0\nCaller[000000000079fb08]: __driver_attach+0x88/0xa0\nCaller[000000000079d90c]: bus_for_each_dev+0x6c/0xa0\nCaller[000000000079f29c]: driver_attach+0x1c/0x40\nCaller[000000000079e35c]: bus_add_driver+0x17c/0x220\nCaller[00000000007a02d4]: driver_register+0x74/0x120\nCaller[00000000007263fc]: __pci_register_driver+0x3c/0x60\nCaller[00000000104f62bc]: mlx4_init+0x60/0xcc [mlx4_core]\nKernel panic - not syncing: Fatal exception\nPress Stop-A (L1-A) to return to the boot prom\n---[ end Kernel panic - not syncing: Fatal exception\n\nDetails:\nHere is the call sequence\nvirtfn_add->__mlx4_init_one->dma_set_mask->dma_supported\n\nThe panic happened at line 760(file arch/sparc/kernel/iommu.c)\n\n758 int dma_supported(struct device *dev, u64 device_mask)\n759 {\n760         struct iommu *iommu = dev->archdata.iommu;\n761         u64 dma_addr_mask = iommu->dma_addr_mask;\n762\n763         if (device_mask >= (1UL << 32UL))\n764                 return 0;\n765\n766         if ((device_mask & dma_addr_mask) == dma_addr_mask)\n767                 return 1;\n768\n769 #ifdef CONFIG_PCI\n770         if (dev_is_pci(dev))\n771\t\treturn pci64_dma_supported(to_pci_dev(dev), device_mask);\n772 #endif\n773\n774         return 0;\n775 }\n776 EXPORT_SYMBOL(dma_supported);\n\nSame panic happened with Intel ixgbe driver also.\n\nSR-IOV code looks for arch specific data while enabling\nVFs. When VF device is added, driver probe function makes set\nof calls to initialize the pci device. Because the VF device is\nadded different way than the normal PF device(which happens via\nof_create_pci_dev for sparc), some of the arch specific initialization\ndoes not happen for VF device.  That causes panic when archdata is\naccessed.\n\nTo fix this, I have used already defined weak function\npcibios_setup_device to copy archdata from PF to VF.\nAlso verified the fix.\n\nSigned-off-by: Babu Moger <babu.moger@oracle.com>\nSigned-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>\nReviewed-by: Ethan Zhao <ethan.zhao@oracle.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/ccd02310db44df820d1e8c54a97daf596dea1c9e"},{"sha":"87575e31be28afb08665f412ac269909c5911a33","author":{"name":"Nitin Gupta","email":"13607b8368a47c13f452385a577ae5bc2f8e67a6@oracle.com"},"message":"sparc64: Reduce TLB flushes during hugepte changes\n\n[ Upstream commit 24e49ee3d76b70853a96520e46b8837e5eae65b2 ]\n\nDuring hugepage map/unmap, TSB and TLB flushes are currently\nissued at every PAGE_SIZE'd boundary which is unnecessary.\nWe now issue the flush at REAL_HPAGE_SIZE boundaries only.\n\nWithout this patch workloads which unmap a large hugepage\nbacked VMA region get CPU lockups due to excessive TLB\nflush calls.\n\nOrabug: 22365539, 22643230, 22995196\n\nSigned-off-by: Nitin Gupta <nitin.m.gupta@oracle.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/87575e31be28afb08665f412ac269909c5911a33"},{"sha":"6bb3290ce9662055efcf13dc18c12bb62f6f39dc","author":{"name":"David S. Miller","email":"79caf591e37e1438a2d55ae59670d5cd0d717764@davemloft.net"},"message":"sparc64: Take ctx_alloc_lock properly in hugetlb_setup().\n\n[ Upstream commit 9ea46abe22550e3366ff7cee2f8391b35b12f730 ]\n\nOn cheetahplus chips we take the ctx_alloc_lock in order to\nmodify the TLB lookup parameters for the indexed TLBs, which\nare stored in the context register.\n\nThis is called with interrupts disabled, however ctx_alloc_lock\nis an IRQ safe lock, therefore we must take acquire/release it\nproperly with spin_{lock,unlock}_irq().\n\nReported-by: Meelis Roos <mroos@linux.ee>\nTested-by: Meelis Roos <mroos@linux.ee>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/6bb3290ce9662055efcf13dc18c12bb62f6f39dc"},{"sha":"1fda90c39d8ef6acbedfd3cd9bd710a5bcc490c3","author":{"name":"David S. Miller","email":"79caf591e37e1438a2d55ae59670d5cd0d717764@davemloft.net"},"message":"sparc: Harden signal return frame checks.\n\n[ Upstream commit d11c2a0de2824395656cf8ed15811580c9dd38aa ]\n\nAll signal frames must be at least 16-byte aligned, because that is\nthe alignment we explicitly create when we build signal return stack\nframes.\n\nAll stack pointers must be at least 8-byte aligned.\n\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/1fda90c39d8ef6acbedfd3cd9bd710a5bcc490c3"},{"sha":"561e4453dd06f56cd8a61ced33964189b3651558","author":{"name":"David S. Miller","email":"79caf591e37e1438a2d55ae59670d5cd0d717764@davemloft.net"},"message":"sparc64: Fix return from trap window fill crashes.\n\n[ Upstream commit 7cafc0b8bf130f038b0ec2dcdd6a9de6dc59b65a ]\n\nWe must handle data access exception as well as memory address unaligned\nexceptions from return from trap window fill faults, not just normal\nTLB misses.\n\nOtherwise we can get an OOPS that looks like this:\n\nld-linux.so.2(36808): Kernel bad sw trap 5 [#1]\nCPU: 1 PID: 36808 Comm: ld-linux.so.2 Not tainted 4.6.0 #34\ntask: fff8000303be5c60 ti: fff8000301344000 task.ti: fff8000301344000\nTSTATE: 0000004410001601 TPC: 0000000000a1a784 TNPC: 0000000000a1a788 Y: 00000002    Not tainted\nTPC: <do_sparc64_fault+0x5c4/0x700>\ng0: fff8000024fc8248 g1: 0000000000db04dc g2: 0000000000000000 g3: 0000000000000001\ng4: fff8000303be5c60 g5: fff800030e672000 g6: fff8000301344000 g7: 0000000000000001\no0: 0000000000b95ee8 o1: 000000000000012b o2: 0000000000000000 o3: 0000000200b9b358\no4: 0000000000000000 o5: fff8000301344040 sp: fff80003013475c1 ret_pc: 0000000000a1a77c\nRPC: <do_sparc64_fault+0x5bc/0x700>\nl0: 00000000000007ff l1: 0000000000000000 l2: 000000000000005f l3: 0000000000000000\nl4: fff8000301347e98 l5: fff8000024ff3060 l6: 0000000000000000 l7: 0000000000000000\ni0: fff8000301347f60 i1: 0000000000102400 i2: 0000000000000000 i3: 0000000000000000\ni4: 0000000000000000 i5: 0000000000000000 i6: fff80003013476a1 i7: 0000000000404d4c\nI7: <user_rtt_fill_fixup+0x6c/0x7c>\nCall Trace:\n [0000000000404d4c] user_rtt_fill_fixup+0x6c/0x7c\n\nThe window trap handlers are slightly clever, the trap table entries for them are\ncomposed of two pieces of code.  First comes the code that actually performs\nthe window fill or spill trap handling, and then there are three instructions at\nthe end which are for exception processing.\n\nThe userland register window fill handler is:\n\n\tadd\t%sp, STACK_BIAS + 0x00, %g1;\t\t\\\n\tldxa\t[%g1 + %g0] ASI, %l0;\t\t\t\\\n\tmov\t0x08, %g2;\t\t\t\t\\\n\tmov\t0x10, %g3;\t\t\t\t\\\n\tldxa\t[%g1 + %g2] ASI, %l1;\t\t\t\\\n\tmov\t0x18, %g5;\t\t\t\t\\\n\tldxa\t[%g1 + %g3] ASI, %l2;\t\t\t\\\n\tldxa\t[%g1 + %g5] ASI, %l3;\t\t\t\\\n\tadd\t%g1, 0x20, %g1;\t\t\t\t\\\n\tldxa\t[%g1 + %g0] ASI, %l4;\t\t\t\\\n\tldxa\t[%g1 + %g2] ASI, %l5;\t\t\t\\\n\tldxa\t[%g1 + %g3] ASI, %l6;\t\t\t\\\n\tldxa\t[%g1 + %g5] ASI, %l7;\t\t\t\\\n\tadd\t%g1, 0x20, %g1;\t\t\t\t\\\n\tldxa\t[%g1 + %g0] ASI, %i0;\t\t\t\\\n\tldxa\t[%g1 + %g2] ASI, %i1;\t\t\t\\\n\tldxa\t[%g1 + %g3] ASI, %i2;\t\t\t\\\n\tldxa\t[%g1 + %g5] ASI, %i3;\t\t\t\\\n\tadd\t%g1, 0x20, %g1;\t\t\t\t\\\n\tldxa\t[%g1 + %g0] ASI, %i4;\t\t\t\\\n\tldxa\t[%g1 + %g2] ASI, %i5;\t\t\t\\\n\tldxa\t[%g1 + %g3] ASI, %i6;\t\t\t\\\n\tldxa\t[%g1 + %g5] ASI, %i7;\t\t\t\\\n\trestored;\t\t\t\t\t\\\n\tretry; nop; nop; nop; nop;\t\t\t\\\n\tb,a,pt\t%xcc, fill_fixup_dax;\t\t\t\\\n\tb,a,pt\t%xcc, fill_fixup_mna;\t\t\t\\\n\tb,a,pt\t%xcc, fill_fixup;\n\nAnd the way this works is that if any of those memory accesses\ngenerate an exception, the exception handler can revector to one of\nthose final three branch instructions depending upon which kind of\nexception the memory access took.  In this way, the fault handler\ndoesn't have to know if it was a spill or a fill that it's handling\nthe fault for.  It just always branches to the last instruction in\nthe parent trap's handler.\n\nFor example, for a regular fault, the code goes:\n\nwinfix_trampoline:\n\trdpr\t%tpc, %g3\n\tor\t%g3, 0x7c, %g3\n\twrpr\t%g3, %tnpc\n\tdone\n\nAll window trap handlers are 0x80 aligned, so if we \"or\" 0x7c into the\ntrap time program counter, we'll get that final instruction in the\ntrap handler.\n\nOn return from trap, we have to pull the register window in but we do\nthis by hand instead of just executing a \"restore\" instruction for\nseveral reasons.  The largest being that from Niagara and onward we\nsimply don't have enough levels in the trap stack to fully resolve all\npossible exception cases of a window fault when we are already at\ntrap level 1 (which we enter to get ready to return from the original\ntrap).\n\nThis is executed inline via the FILL_*_RTRAP handlers.  rtrap_64.S's\ncode branches directly to these to do the window fill by hand if\nnecessary.  Now if you look at them, we'll see at the end:\n\n\t    ba,a,pt    %xcc, user_rtt_fill_fixup;\n\t    ba,a,pt    %xcc, user_rtt_fill_fixup;\n\t    ba,a,pt    %xcc, user_rtt_fill_fixup;\n\nAnd oops, all three cases are handled like a fault.\n\nThis doesn't work because each of these trap types (data access\nexception, memory address unaligned, and faults) store their auxiliary\ninfo in different registers to pass on to the C handler which does the\nreal work.\n\nSo in the case where the stack was unaligned, the unaligned trap\nhandler sets up the arg registers one way, and then we branched to\nthe fault handler which expects them setup another way.\n\nSo the FAULT_TYPE_* value ends up basically being garbage, and\nrandomly would generate the backtrace seen above.\n\nReported-by: Nick Alcock <nix@esperi.org.uk>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/561e4453dd06f56cd8a61ced33964189b3651558"},{"sha":"ccb85835a159923d7f79fd51cfd614962426ecf2","author":{"name":"Ralf Baechle","email":"e34dc0f431cfd5378400841df3658f4880373a71@linux-mips.org"},"message":"MIPS: Fix 64k page support for 32 bit kernels.\n\ncommit d7de413475f443957a0c1d256e405d19b3a2cb22 upstream.\n\nTASK_SIZE was defined as 0x7fff8000UL which for 64k pages is not a\nmultiple of the page size.  Somewhere further down the math fails\nsuch that executing an ELF binary fails.\n\nSigned-off-by: Ralf Baechle <ralf@linux-mips.org>\nTested-by: Joshua Henderson <joshua.henderson@microchip.com>\nCc: James Hogan <james.hogan@imgtec.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/ccb85835a159923d7f79fd51cfd614962426ecf2"},{"sha":"59ff9f9b38b39afeb167fdc16c52976587b2c45a","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: validate e->target_offset early\n\ncommit bdf533de6968e9686df777dc178486f600c6e617 upstream.\n\nWe should check that e->target_offset is sane before\nmark_source_chains gets called since it will fetch the target entry\nfor loop detection.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/59ff9f9b38b39afeb167fdc16c52976587b2c45a"},{"sha":"868fe2536f8741ebf807ed717734e6c321c478e9","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: make sure e->next_offset covers remaining blob size\n\ncommit 6e94e0cfb0887e4013b3b930fa6ab1fe6bb6ba91 upstream.\n\nOtherwise this function may read data beyond the ruleset blob.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/868fe2536f8741ebf807ed717734e6c321c478e9"},{"sha":"5ebdccd7685f1c0b451c516f99082642d8d49003","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: fix unconditional helper\n\ncommit 54d83fc74aa9ec72794373cb47432c5f7fb1a309 upstream.\n\nBen Hawkes says:\n\n In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it\n is possible for a user-supplied ipt_entry structure to have a large\n next_offset field. This field is not bounds checked prior to writing a\n counter value at the supplied offset.\n\nProblem is that mark_source_chains should not have been called --\nthe rule doesn't have a next entry, so its supposed to return\nan absolute verdict of either ACCEPT or DROP.\n\nHowever, the function conditional() doesn't work as the name implies.\nIt only checks that the rule is using wildcard address matching.\n\nHowever, an unconditional rule must also not be using any matches\n(no -m args).\n\nThe underflow validator only checked the addresses, therefore\npassing the 'unconditional absolute verdict' test, while\nmark_source_chains also tested for presence of matches, and thus\nproceeeded to the next (not-existent) rule.\n\nUnify this so that all the callers have same idea of 'unconditional rule'.\n\nReported-by: Ben Hawkes <hawkes@google.com>\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/5ebdccd7685f1c0b451c516f99082642d8d49003"},{"sha":"dbea3ce55ad13ddccf519a95ce0d77a5064e9ccc","author":{"name":"Tadeusz Struk","email":"9997d90c95a862f0fc920aa9e8ef7146113dda98@intel.com"},"message":"crypto: qat - fix adf_ctl_drv.c:undefined reference to adf_init_pf_wq\n\ncommit 6dc5df71ee5c8b44607928bfe27be50314dcf848 upstream.\n\nFix undefined reference issue reported by kbuild test robot.\n\nReported-by: kbuild test robot <fengguang.wu@intel.com>\nSigned-off-by: Tadeusz Struk <tadeusz.struk@intel.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/dbea3ce55ad13ddccf519a95ce0d77a5064e9ccc"},{"sha":"0d6ad54b74fd66ca016076900da97e96272ff83e","author":{"name":"Maarten Lankhorst","email":"31963d7fed19f3420ff638ec3d8fbadfee1a8e5f@linux.intel.com"},"message":"drm/core: Do not preserve framebuffer on rmfb, v4.\n\ncommit f2d580b9a8149735cbc4b59c4a8df60173658140 upstream.\n\nIt turns out that preserving framebuffers after the rmfb call breaks\nvmwgfx userspace. This was originally introduced because it was thought\nnobody relied on the behavior, but unfortunately it seems there are\nexceptions.\n\ndrm_framebuffer_remove may fail with -EINTR now, so a straight revert\nis impossible. There is no way to remove the framebuffer from the lists\nand active planes without introducing a race because of the different\nlocking requirements. Instead call drm_framebuffer_remove from a\nworkqueue, which is unaffected by signals.\n\nChanges since v1:\n- Add comment.\nChanges since v2:\n- Add fastpath for refcount = 1. (danvet)\nChanges since v3:\n- Rebased.\n- Restore lastclose framebuffer removal too.\n\nFixes: 13803132818c (\"drm/core: Preserve the framebuffer after removing it.\")\nTestcase: kms_rmfb_basic\nReferences: https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html\nCc: Thomas Hellstrom <thellstrom@vmware.com>\nCc: David Herrmann <dh.herrmann@gmail.com>\nReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nTested-by: Thomas Hellstrom <thellstrom@vmware.com> #v3\nTested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nLink: http://patchwork.freedesktop.org/patch/msgid/6c63ca37-0e7e-ac7f-a6d2-c7822e3d611f@linux.intel.com\nSigned-off-by: Hans de Goede <hdegoede@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/0d6ad54b74fd66ca016076900da97e96272ff83e"},{"sha":"d6f7cd1b21b9e797e09269ee16655f9c0e4a3fa1","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: don't move to non-existent next rule\n\ncommit f24e230d257af1ad7476c6e81a8dc3127a74204e upstream.\n\nBen Hawkes says:\n\n In the mark_source_chains function (net/ipv4/netfilter/ip_tables.c) it\n is possible for a user-supplied ipt_entry structure to have a large\n next_offset field. This field is not bounds checked prior to writing a\n counter value at the supplied offset.\n\nBase chains enforce absolute verdict.\n\nUser defined chains are supposed to end with an unconditional return,\nxtables userspace adds them automatically.\n\nBut if such return is missing we will move to non-existent next rule.\n\nReported-by: Ben Hawkes <hawkes@google.com>\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/d6f7cd1b21b9e797e09269ee16655f9c0e4a3fa1"},{"sha":"611d408a531fdbecf07e268ac87e37d71dd5cd8e","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: validate targets of jumps\n\ncommit 36472341017529e2b12573093cc0f68719300997 upstream.\n\nWhen we see a jump also check that the offset gets us to beginning of\na rule (an ipt_entry).\n\nThe extra overhead is negible, even with absurd cases.\n\n300k custom rules, 300k jumps to 'next' user chain:\n[ plus one jump from INPUT to first userchain ]:\n\nBefore:\nreal    0m24.874s\nuser    0m7.532s\nsys     0m16.076s\n\nAfter:\nreal    0m27.464s\nuser    0m7.436s\nsys     0m18.840s\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/611d408a531fdbecf07e268ac87e37d71dd5cd8e"},{"sha":"cfdca13028ff3aa8c5f4b63ba5abf878cd55ced5","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: add and use xt_check_entry_offsets\n\ncommit 7d35812c3214afa5b37a675113555259cfd67b98 upstream.\n\nCurrently arp/ip and ip6tables each implement a short helper to check that\nthe target offset is large enough to hold one xt_entry_target struct and\nthat t->u.target_size fits within the current rule.\n\nUnfortunately these checks are not sufficient.\n\nTo avoid adding new tests to all of ip/ip6/arptables move the current\nchecks into a helper, then extend this helper in followup patches.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/cfdca13028ff3aa8c5f4b63ba5abf878cd55ced5"},{"sha":"6bc803b795631cb14a6a3ea6d433589c8c666cc3","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: kill check_entry helper\n\ncommit aa412ba225dd3bc36d404c28cdc3d674850d80d0 upstream.\n\nOnce we add more sanity testing to xt_check_entry_offsets it\nbecomes relvant if we're expecting a 32bit 'config_compat' blob\nor a normal one.\n\nSince we already have a lot of similar-named functions (check_entry,\ncompat_check_entry, find_and_check_entry, etc.) and the current\nincarnation is short just fold its contents into the callers.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/6bc803b795631cb14a6a3ea6d433589c8c666cc3"},{"sha":"ed30e07de077354993122c5d88e535cbe0a03754","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: assert minimum target size\n\ncommit a08e4e190b866579896c09af59b3bdca821da2cd upstream.\n\nThe target size includes the size of the xt_entry_target struct.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/ed30e07de077354993122c5d88e535cbe0a03754"},{"sha":"2985d199e713c05eec2eaffeeeac40682aa2e5cc","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: add compat version of xt_check_entry_offsets\n\ncommit fc1221b3a163d1386d1052184202d5dc50d302d1 upstream.\n\n32bit rulesets have different layout and alignment requirements, so once\nmore integrity checks get added to xt_check_entry_offsets it will reject\nwell-formed 32bit rulesets.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/2985d199e713c05eec2eaffeeeac40682aa2e5cc"},{"sha":"2066499780e1455c43833b5b34858124047331ff","author":{"name":"Florian Westphal","email":"dbfaf6a80dfd937969ef4cfe4989863cfe354fce@strlen.de"},"message":"netfilter: x_tables: check standard target size too\n\ncommit 7ed2abddd20cf8f6bd27f65bd218f26fa5bf7f44 upstream.\n\nWe have targets and standard targets -- the latter carries a verdict.\n\nThe ip/ip6tables validation functions will access t->verdict for the\nstandard targets to fetch the jump offset or verdict for chainloop\ndetection, but this happens before the targets get checked/validated.\n\nThus we also need to check for verdict presence here, else t->verdict\ncan point right after a blob.\n\nSpotted with UBSAN while testing malformed blobs.\n\nSigned-off-by: Florian Westphal <fw@strlen.de>\nSigned-off-by: Pablo Neira Ayuso <pablo@netfilter.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/dianlujitao/CAF_kernel_msm-3.18/commits/2066499780e1455c43833b5b34858124047331ff"}]}
{"actor":{"display_login":"dianlujitao"}}