GitHub PushEvent at 2014-03-01 08:37:32
Repository: linux-Digilent-Dev
Actor: Digilent
Payload: {"shas":[["6c719faca2aceca72f1bf5b1645c1734ed3e9447","c1b6782c4af8f0673da8923a0702a1832e5940f4@ffwll.ch","drm/i915: don't update the dri1 breadcrumb with modesetting\n\nThe update is horribly racy since it doesn't protect at all against\nconcurrent closing of the master fd. And it can't really since that\nrequires us to grab a mutex.\n\nInstead of jumping through hoops and offloading this to a worker\nthread just block this bit of code for the modesetting driver.\n\nNote that the race is fairly easy to hit since we call the breadcrumb\nfunction for any interrupt. So the vblank interrupt (which usually\nkeeps going for a bit) is enough. But even if we'd block this and only\nupdate the breadcrumb for user interrupts from the CS we could hit\nthis race with kms/gem userspace: If a non-master is waiting somewhere\n(and hence has interrupts enabled) and the master closes its fd\n(probably due to crashing).\n\nv2: Add a code comment to explain why fixing this for real isn't\nreally worth it. Also improve the commit message a bit.\n\nv3: Fix the spelling in the comment.\n\nReported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>\nCc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>\nCc: stable@vger.kernel.org\nAcked-by: Chris Wilson <chris@chris-wilson.co.uk>\nTested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>","Daniel Vetter",true],["6f041e99fc7ba00e7e65a431527f9235d6b16463","547fa85bb3888a0222eed8ec39e36708605c6d53@imgtec.com","of: Fix NULL dereference in unflatten_and_copy()\n\nCheck whether initial_boot_params is NULL before dereferencing it in\nunflatten_and_copy_device_tree() for the case where no device tree is\navailable but the arch can still boot to a minimal usable system without\nit. In this case also log a warning for when the kernel log buffer is\nobtainable.\n\nSigned-off-by: James Hogan <james.hogan@imgtec.com>\nCc: Rob Herring <rob.herring@calxeda.com>\nSigned-off-by: Grant Likely <grant.likely@linaro.org>","James Hogan",true],["8e8339a3a1069141985daaa2521ba304509ddecd","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","sched: Initialize power_orig for overlapping groups\n\nYinghai reported that he saw a /0 in sg_capacity on his EX parts.\nMake sure to always initialize power_orig now that we actually use it.\n\nIdeally build_sched_domains() -> init_sched_groups_power() would also\ninitialize this; but for some yet unexplained reason some setups seem\nto miss updates there.\n\nReported-by: Yinghai Lu <yinghai@kernel.org>\nTested-by: Yinghai Lu <yinghai@kernel.org>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nLink: http://lkml.kernel.org/n/tip-l8ng2m9uml6fhibln8wqpom7@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","Peter Zijlstra",true],["ba1f14fbe70965ae0fb1655a5275a62723f65b77","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","sched: Remove PREEMPT_NEED_RESCHED from generic code\n\nWhile hunting a preemption issue with Alexander, Ben noticed that the\ncurrently generic PREEMPT_NEED_RESCHED stuff is horribly broken for\nload-store architectures.\n\nWe currently rely on the IPI to fold TIF_NEED_RESCHED into\nPREEMPT_NEED_RESCHED, but when this IPI lands while we already have\na load for the preempt-count but before the store, the store will erase\nthe PREEMPT_NEED_RESCHED change.\n\nThe current preempt-count only works on load-store archs because\ninterrupts are assumed to be completely balanced wrt their preempt_count\nfiddling; the previous preempt_count load will match the preempt_count\nstate after the interrupt and therefore nothing gets lost.\n\nThis patch removes the PREEMPT_NEED_RESCHED usage from generic code and\npushes it into x86 arch code; the generic code goes back to relying on\nTIF_NEED_RESCHED.\n\nBoot tested on x86_64 and compile tested on ppc64.\n\nReported-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>\nReported-and-Tested-by: Alexander Graf <agraf@suse.de>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/r/20131128132641.GP10022@twins.programming.kicks-ass.net\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","Peter Zijlstra",true],["be5e610c0fd6ef772cafb9e0bd4128134804aef3","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","math64: Add mul_u64_u32_shr()\n\nIntroduce mul_u64_u32_shr() as proposed by Andy a while back; it\nallows using 64x64->128 muls on 64bit archs and recent GCC\nwhich defines __SIZEOF_INT128__ and __int128.\n\n(This new method will be used by the scheduler.)\n\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nCc: fweisbec@gmail.com\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nLink: http://lkml.kernel.org/n/tip-hxjoeuzmrcaumR0uZwjpe2pv@git.kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","Peter Zijlstra",true],["9dbdb155532395ba000c5d5d187658b0e17e529f","3fddac958924aef220f202ca567388ddab3f14a8@infradead.org","sched/fair: Rework sched_fair time accounting\n\nChristian suffers from a bad BIOS that wrecks his i5's TSC sync. This\nresults in him occasionally seeing time going backwards - which\ncrashes the scheduler ...\n\nMost of our time accounting can actually handle that except the most\ncommon one; the tick time update of sched_fair.\n\nThere is a further problem with that code; previously we assumed that\nbecause we get a tick every TICK_NSEC our time delta could never\nexceed 32bits and math was simpler.\n\nHowever, ever since Frederic managed to get NO_HZ_FULL merged; this is\nno longer the case since now a task can run for a long time indeed\nwithout getting a tick. It only takes about ~4.2 seconds to overflow\nour u32 in nanoseconds.\n\nThis means we not only need to better deal with time going backwards;\nbut also means we need to be able to deal with large deltas.\n\nThis patch reworks the entire code and uses mul_u64_u32_shr() as\nproposed by Andy a long while ago.\n\nWe express our virtual time scale factor in a u32 multiplier and shift\nright and the 32bit mul_u64_u32_shr() implementation reduces to a\nsingle 32x32->64 multiply if the time delta is still short (common\ncase).\n\nFor 64bit a 64x64->128 multiply can be used if ARCH_SUPPORTS_INT128.\n\nReported-and-Tested-by: Christian Engelmayer <cengelma@gmx.at>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nCc: fweisbec@gmail.com\nCc: Paul Turner <pjt@google.com>\nCc: Stanislaw Gruszka <sgruszka@redhat.com>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Andrew Morton <akpm@linux-foundation.org>\nLink: http://lkml.kernel.org/r/20131118172706.GI3866@twins.programming.kicks-ass.net\nSigned-off-by: Ingo Molnar <mingo@kernel.org>","Peter Zijlstra",true],["33457ff7cdd48c54723ab8c550deec28dd904659","2a53bac7a5d324865ef46ec4c38b2c0fba1456b4@tuxdriver.com","Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem","John W. Linville",true],["02ab71cdae248533620abefa1d46097581457110","22a0c6385d750d07aa383c9f813cf6f0228657d8@eu.citrix.com","xen/arm64: do not call the swiotlb functions twice\n\nOn arm64 the dma_map_ops implementation is based on the swiotlb.\nswiotlb-xen, used by default in dom0 on Xen, is also based on the\nswiotlb.\n\nAvoid calling into the default arm64 dma_map_ops functions from\nxen_dma_map_page, xen_dma_unmap_page, xen_dma_sync_single_for_cpu, and\nxen_dma_sync_single_for_device otherwise we end up calling into the\nswiotlb twice.\n\nWhen arm64 gets a non-swiotlb based implementation of dma_map_ops, we'll\nprobably have to reintroduce dma_map_ops calls in page-coherent.h.\n\nSigned-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>\nCC: catalin.marinas@arm.com\nCC: Will.Deacon@arm.com\nCC: Ian.Campbell@citrix.com","Stefano Stabellini",true],["a7892f32cc3534d4cc0e64b245fbf47a8e364652","9be92b3dbbd6611e3e4c9209fb3d04b4919e7cca@citrix.com","arm: xen: foreign mapping PTEs are special.\n\nThese mappings are in fact special and require special handling in privcmd,\nwhich already exists. Failure to mark the PTE as special on arm64 causes all\nsorts of bad PTE fun. e.g.\n\ne.g.:\n\nBUG: Bad page map in process xl  pte:e0004077b33f53 pmd:4079575003\npage:ffffffbce1a2f328 count:1 mapcount:-1 mapping:          (null) index:0x0\npage flags: 0x4000000000000014(referenced|dirty)\naddr:0000007fb5259000 vm_flags:040644fa anon_vma:          (null) mapping:ffffffc03a6fda58 index:0\nvma->vm_ops->fault: privcmd_fault+0x0/0x38\nvma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x2c\nCPU: 0 PID: 2657 Comm: xl Not tainted 3.12.0+ #102\nCall trace:\n[<ffffffc0000880f8>] dump_backtrace+0x0/0x12c\n[<ffffffc000088238>] show_stack+0x14/0x1c\n[<ffffffc0004b67e0>] dump_stack+0x70/0x90\n[<ffffffc000125690>] print_bad_pte+0x12c/0x1bc\n[<ffffffc0001268f4>] unmap_single_vma+0x4cc/0x700\n[<ffffffc0001273b4>] unmap_vmas+0x68/0xb4\n[<ffffffc00012c050>] unmap_region+0xcc/0x1d4\n[<ffffffc00012df20>] do_munmap+0x218/0x314\n[<ffffffc00012e060>] vm_munmap+0x44/0x64\n[<ffffffc00012ed78>] SyS_munmap+0x24/0x34\n\nWhere unmap_single_vma contains inlined -> unmap_page_range -> zap_pud_range\n-> zap_pmd_range -> zap_pte_range -> print_bad_pte.\n\nOr:\n\nBUG: Bad page state in process xl  pfn:4077b4d\npage:ffffffbce1a2f8d8 count:0 mapcount:-1 mapping:          (null) index:0x0\npage flags: 0x4000000000000014(referenced|dirty)\nModules linked in:\nCPU: 0 PID: 2657 Comm: xl Tainted: G    B        3.12.0+ #102\nCall trace:\n[<ffffffc0000880f8>] dump_backtrace+0x0/0x12c\n[<ffffffc000088238>] show_stack+0x14/0x1c\n[<ffffffc0004b67e0>] dump_stack+0x70/0x90\n[<ffffffc00010f798>] bad_page+0xc4/0x110\n[<ffffffc00010f8b4>] free_pages_prepare+0xd0/0xd8\n[<ffffffc000110e94>] free_hot_cold_page+0x28/0x178\n[<ffffffc000111460>] free_hot_cold_page_list+0x38/0x60\n[<ffffffc000114cf0>] release_pages+0x190/0x1dc\n[<ffffffc00012c0e0>] unmap_region+0x15c/0x1d4\n[<ffffffc00012df20>] do_munmap+0x218/0x314\n[<ffffffc00012e060>] vm_munmap+0x44/0x64\n[<ffffffc00012ed78>] SyS_munmap+0x24/0x34\n\nx86 already gets this correct. 32-bit arm gets away with this because there is\nnot PTE_SPECIAL bit in the PTE there and the vm_normal_page fallback path does\nthe right thing.\n\nSigned-off-by: Ian Campbell <ian.campbell@citrix.com>\nSigned-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>","Ian Campbell",true],["f0b75693cbb26439ba959ba7d3b4f43e2fcf3da6","f10ec01be0c6b54271af5c550cd257810bdf3268@google.com","MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainers\n\nAdd entries for PCI host controller drivers in drivers/pci/host/.\n\nSigned-off-by: Mohit Kumar <mohit.kumar@st.com>             # DESIGNWARE\nSigned-off-by: Pratyush Anand <pratyush.anand@st.com>       # DESIGNWARE\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nAcked-by: Simon Horman <horms+renesas@verge.net.au>         # R-CAR\nDouble-Plus-Acked-by: Jason Cooper <jason@lakedaemon.net>   # MVEBU\nAcked-by: Jingoo Han <jg1.han@samsung.com>\nAcked-by: Thierry Reding <treding@nvidia.com>\nAcked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>\nAcked-by: Richard Zhu <r65037@freescale.com>                # IMX6","Bjorn Helgaas",true],["d0977e2b85ab7966d1f8cd85a19ac5aa80793638","fe08d3c717adf2ae63592e4c9aec6e3e404d8e3e@davemloft.net","Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless\n\nJohn W. Linville says:\n\n====================\nJust one patch this time -- a fix from Felix Fietkau to fix the\nduration calculation for non-aggregated packets in ath9k.  This is\na small change and it is obviously specific to ath9k.\n\nPlease let me know if there are problems!\n====================\n\nSigned-off-by: David S. Miller <davem@davemloft.net>","David S. Miller",true],["4bd7b5127bd02c12c1cc837a7a0b6ce295eb2505","d8c69075be49b0738b690ec4af0e9025b8c97c9e@cogentembedded.com","micrel: add support for KSZ8041RNLI\n\nRenesas R-Car development boards use KSZ8041RNLI PHY which for some reason has\nID of 0x00221537 that is not documented for KSZ8041-family PHYs and does not\nmatch the  documented ID of  0x0022151x (where 'x' is the revision).  We have\nto add the new #define PHY_ID_* and new ksphy_driver[] entry, almost the same\nas KSZ8041 one, differing only in the 'phy_id' and 'name' fields.\n\nSigned-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>\nTested-by: Geert Uytterhoeven <geert@linux-m68k.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Sergei Shtylyov",true],["2306bfb208b9c403592a0513b08f2e6ad53056d5","96f164ad4d9b2b0dacf8ebee2bb1eeb3aa69adf1@purestorage.com","iscsi-target: return -EINVAL on oversized configfs parameter\n\nThe iSCSI CHAP auth parameters are already copied with respect for\nthe destination buffer size.  Return -EINVAL instead of silently\ntruncating the input.\n\nSigned-off-by: Eric Seppanen <eric@purestorage.com>\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>","Eric Seppanen",true],["a51d5229d10dd3a337b674ce8603437d2996c5c3","0d270388f2f92757a5de0f4bd891d3b392c44c4f@purestorage.com","target: Remove write-only stats fields and lock from struct se_node_acl\n\nCommit 04f3b31bff72 (\"iscsi-target: Convert iscsi_session statistics to\natomic_long_t\") removed the updating of these fields in iscsi (the only\nfabric driver that ever touched these counters), and the core has no way\nto report or otherwise use the values.  Remove the last remnants of\nthese counters.\n\nSigned-off-by: Roland Dreier <roland@purestorage.com>\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>","Roland Dreier",true],["4454b66cb67f14c33cd70ddcf0ff4985b26324b7","978acd1567d5598152161fdf8bf3ca568f950c9b@linux-iscsi.org","iscsi-target: Fix-up all zero data-length CDBs with R/W_BIT set\n\nThis patch changes special case handling for ISCSI_OP_SCSI_CMD\nwhere an initiator sends a zero length Expected Data Transfer\nLength (EDTL), but still sets the WRITE and/or READ flag bits\nwhen no payload transfer is requested.\n\nMany, many moons ago two special cases where added for an ancient\nversion of ESX that has long since been fixed, so instead of adding\na new special case for the reported bug with a Broadcom 57800 NIC,\ngo ahead and always strip off the incorrect WRITE + READ flag bits.\n\nAlso, avoid sending a reject here, as RFC-3720 does mandate this\ncase be handled without protocol error.\n\nReported-by: Witold Bazakbal <865perl@wp.pl>\nTested-by: Witold Bazakbal <865perl@wp.pl>\nCc: <stable@vger.kernel.org> #3.1+\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>","Nicholas Bellinger",true],["94a7111043d99819cd0a72d9b3174c7054adb2a0","b8f9cab8be13de37b9588aedad10a20fc3a68783@trendmicro.com.cn","iser-target: fix error return code in isert_create_device_ib_res()\n\nFix to return a negative error code from the error handling\ncase instead of 0, as done elsewhere in this function.\n\nSigned-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>\nCc: <stable@vger.kernel.org> #3.10+\nSigned-off-by: Nicholas Bellinger <nab@linux-iscsi.org>","Wei Yongjun",true],["cc106e441a63bec3b1cb72948df82ea15945c449","f22095f1f23acd1984d9e486f10b3c59ac2a6546@huawei.com","net: sched: tbf: fix the calculation of max_size\n\nCurrent max_size is caluated from rate table. Now, the rate table\nhas been replaced and it's wrong to caculate max_size based on this\nrate table. It can lead wrong calculation of max_size.\n\nThe burst in kernel may be lower than user asked, because burst may gets\nsome loss when transform it to buffer(E.g. \"burst 40kb rate 30mbit/s\")\nand it seems we cannot avoid this loss. Burst's value(max_size) based on\nrate table may be equal user asked. If a packet's length is max_size, this\npacket will be stalled in tbf_dequeue() because its length is above the\nburst in kernel so that it cannot get enough tokens. The max_size guards\nagainst enqueuing packet sizes above q->buffer \"time\" in tbf_enqueue().\n\nTo make consistent with the calculation of tokens, this patch add a helper\npsched_ns_t2l() to calculate burst(max_size) directly to fix this problem.\n\nAfter this fix, we can support to using 64bit rates to calculate burst as well.\n\nSigned-off-by: Yang Yingliang <yangyingliang@huawei.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Yang Yingliang",true],["1598f7cb4745c40467decc91ee44ec615773eb45","f22095f1f23acd1984d9e486f10b3c59ac2a6546@huawei.com","net: sched: htb: fix the calculation of quantum\n\nNow, 32bit rates may be not the true rate.\nSo use rate_bytes_ps which is from\nmax(rate32, rate64) to calcualte quantum.\n\nSigned-off-by: Yang Yingliang <yangyingliang@huawei.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Yang Yingliang",true],["e6fd07c899cd719bb5517bc7f32ce03a62220351","808efd45667dbd241e4e026b5673172419ecb43e@redhat.com","tun: unbreak truncated packet signalling\n\nCommit 6680ec68eff47d36f67b4351bc9836fd6cba9532\n(tuntap: hardware vlan tx support) breaks the truncated packet signal by nev\nreturn a length greater than iov length in tun_put_user(). This patch fixes\nby always return the length of packet plus possible vlan header. Caller can\ndetect the truncated packet by comparing the return value and the size of io\nlength.\n\nCc: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>\nCc: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Vlad Yasevich <vyasevich@gmail.com>\nSigned-off-by: Jason Wang <jasowang@redhat.com>\nAcked-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Jason Wang",true],["ce232ce01d61b184202bb185103d119820e1260c","808efd45667dbd241e4e026b5673172419ecb43e@redhat.com","macvtap: signal truncated packets\n\nmacvtap_put_user() never return a value grater than iov length, this in fact\nbypasses the truncated checking in macvtap_recvmsg(). Fix this by always\nreturning the size of packet plus the possible vlan header to let the trunca\nchecking work.\n\nCc: Vlad Yasevich <vyasevich@gmail.com>\nCc: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>\nCc: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Jason Wang <jasowang@redhat.com>\nAcked-by: Vlad Yasevich <vyasevich@gmail.com>\nAcked-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","Jason Wang",true]],"size":1000,"ref":"refs/heads/master-next","head":"c95153391c7d8491a50a190d7f8d81daa2347c71"}