GitHub PushEvent at 2014-08-10 21:20:11
Repository: linux-stephan
Actor: baerwolf
Payload: {"shas":[["8bbfe822fbadf05ff84a057bde1e59c198e24aa0","73675debcd8a436be48ec22211dcf44fe0df0a64@decadent.org.uk","Revert \"net: ipv4: ip_forward: fix inverted local_df test\"\n\nThis reverts commit 59d9f389df3cdf72833d5ee17c3fe959b6bdc792, which\nwas commit ca6c5d4ad216d5942ae544bbf02503041bd802aa upstream.  It is a\nvalid fix, but depends on sk_buff::local_df being set in all the right\ncases, which it wasn't in 3.2.  We need to defer it unless and until\nthe other fixes are also backported to 3.2.y.\n\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Ben Hutchings",true],["3d4a1eea8aac05f347bbfbf41b9e2f8d6f116926","73675debcd8a436be48ec22211dcf44fe0df0a64@decadent.org.uk","Revert \"net: ip, ipv6: handle gso skbs in forwarding path\"\n\nThis reverts commit caa5344994778a2b4725b2d75c74430f76925e4a, which\nwas commit fe6cc55f3a9a053482a76f5a6b2257cee51b4663 upstream.  In 3.2,\nthe transport header length is not calculated in the forwarding path,\nso skb_gso_network_seglen() returns an incorrect result.  We also have\nproblems due to the local_df flag not being set correctly.\n\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Ben Hutchings",true],["d7a3e3ec5f4396517d6548abb03f07bdf915674f","e75153c795ef6a5a250816f5790445793ba60e94@p23q.org","ARM: OMAP2+: Fix parser-bug in platform muxing code\n\ncommit c021f241f4fab2bb4fc4120a38a828a03dd3f970 upstream.\n\nFix a parser-bug in the omap2 muxing code where muxtable-entries will be\nwrongly selected if the requested muxname is a *prefix* of their\nm0-entry and they have a matching mN-entry. Fix by additionally checking\nthat the length of the m0_entry is equal.\n\nFor example muxing of \"dss_data2.dss_data2\" on omap32xx will fail\nbecause the prefix \"dss_data2\" will match the mux-entries \"dss_data2\" as\nwell as \"dss_data20\", with the suffix \"dss_data2\" matching m0 (for\ndss_data2) and m4 (for dss_data20). Thus both are recognized as signal\npath candidates:\n\nRelevant muxentries from mux34xx.c:\n        _OMAP3_MUXENTRY(DSS_DATA20, 90,\n                \"dss_data20\", NULL, \"mcspi3_somi\", \"dss_data2\",\n                \"gpio_90\", NULL, NULL, \"safe_mode\"),\n        _OMAP3_MUXENTRY(DSS_DATA2, 72,\n                \"dss_data2\", NULL, NULL, NULL,\n                \"gpio_72\", NULL, NULL, \"safe_mode\"),\n\nThis will result in a failure to mux the pin at all:\n\n _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2\n\nPatch should apply to linus' latest master down to rather old linux-2.6\ntrees.\n\nSigned-off-by: David R. Piegdon <lkml@p23q.org>\n[tony@atomide.com: updated description to include full description]\nSigned-off-by: Tony Lindgren <tony@atomide.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","David R. Piegdon",true],["4314612cfd22219e631a31aaed491b040b686562","592678034eb0a2c8d7d04a06101ed8b7dc7101dd@cs.technion.ac.il","KVM: x86: Increase the number of fixed MTRR regs to 10\n\ncommit 682367c494869008eb89ef733f196e99415ae862 upstream.\n\nRecent Intel CPUs have 10 variable range MTRRs. Since operating systems\nsometime make assumptions on CPUs while they ignore capability MSRs, it is\nbetter for KVM to be consistent with recent CPUs. Reporting more MTRRs than\nactually supported has no functional implications.\n\nSigned-off-by: Nadav Amit <namit@cs.technion.ac.il>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Nadav Amit",true],["23f2204d5d91dc5c383fbc3707cc0694688e04c2","69d3ebcf5ee4e7f05a50dc23cd96655b730804b4@redhat.com","KVM: x86: preserve the high 32-bits of the PAT register\n\ncommit 7cb060a91c0efc5ff94f83c6df3ed705e143cdb9 upstream.\n\nKVM does not really do much with the PAT, so this went unnoticed for a\nlong time.  It is exposed however if you try to do rdmsr on the PAT\nregister.\n\nReported-by: Valentine Sinitsyn <valentine.sinitsyn@gmail.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Paolo Bonzini",true],["9919dc4b14683d1edefac5d13503046920776e72","605208d9b4c769ca62e9f9f8b592c9cd465fe6d7@mina86.com","usb: gadget: f_fs: fix NULL pointer dereference when there are no strings\n\ncommit f0688c8b81d2ea239c3fb0b848f623b579238d99 upstream.\n\nIf the descriptors do not need any strings and user space sends empty\nset of strings, the ffs->stringtabs field remains NULL.  Thus\n*ffs->stringtabs in functionfs_bind leads to a NULL pointer\ndereferenece.\n\nThe bug was introduced by commit [fd7c9a007f: “use usb_string_ids_n()”].\n\nWhile at it, remove double initialisation of lang local variable in\nthat function.\n\nffs->strings_count does not need to be checked in any way since in\nthe above scenario it will remain zero and usb_string_ids_n() is\na no-operation when colled with 0 argument.\n\nSigned-off-by: Michal Nazarewicz <mina86@mina86.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Michal Nazarewicz",true],["a4518ea13630be9dee5a1721e011ce61191e0d9e","759412786bc533369b22377bf83fb9056c5b25b2@kernel.org","USB: ftdi_sio: fix null deref at port probe\n\ncommit aea1ae8760314e072bf1b773521e9de5d5dda10d upstream.\n\nFix NULL-pointer dereference when probing an interface with no\nendpoints.\n\nThese devices have two bulk endpoints per interface, but this avoids\ncrashing the kernel if a user forces a non-FTDI device to be probed.\n\nNote that the iterator variable was made unsigned in order to avoid\na maybe-uninitialized compiler warning for ep_desc after the loop.\n\nFixes: 895f28badce9 (\"USB: ftdi_sio: fix hi-speed device packet size\ncalculation\")\n\nReported-by: Mike Remski <mremski@mutualink.net>\nTested-by: Mike Remski <mremski@mutualink.net>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Johan Hovold",true],["31f8e87fc4a58d5207142b2108c22f39f4b9d147","8a2957e0063f2abf61bd145b6236a74a3708ac54@mork.no","usb: option: add/modify Olivetti Olicard modems\n\ncommit b0ebef36e93703e59003ad6a1a20227e47714417 upstream.\n\nAdding a couple of Olivetti modems and blacklisting the net\nfunction on a couple which are already supported.\n\nReported-by: Lars Melin <larsm17@gmail.com>\nSigned-off-by: Bjørn Mork <bjorn@mork.no>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Bjørn Mork",true],["b85631abb6d4fa4d70ee223c3c4a65c5bf7e1709","2d4473c5e67eb83655334d4e9a7757f781607241@linux.intel.com","xhci: correct burst count field for isoc transfers on 1.0 xhci hosts\n\ncommit 3213b151387df0b95f4eada104f68eb1c1409cb3 upstream.\n\nThe transfer burst count (TBC) field in xhci 1.0 hosts should be set\nto the number of bursts needed to transfer all packets in a isoc TD.\nSupported values are 0-2 (1 to 3 bursts per service interval).\n\nFormula for TBC calculation is given in xhci spec section 4.11.2.3:\nTBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1\n\nThis patch should be applied to stable kernels since 3.0 that contain\nthe commit 5cd43e33b9519143f06f507dd7cbee6b7a621885\n\"xhci 1.0: Set transfer burst count field.\"\n\nSuggested-by: ShiChun Ma <masc2008@qq.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Mathias Nyman",true],["6833fc8599e2eaad3b5bf2aef0a07468379cc43b","0e8503a5d55e00d5d2190cff62ef5fd449aa2247@linux.intel.com","xhci: clear root port wake on bits if controller isn't wake-up capable\n\ncommit ff8cbf250b448aac35589f6075082c3fcad8a8fe upstream.\n\nWhen xHCI PCI host is suspended, if do_wakeup is false in xhci_pci_suspend,\nxhci_bus_suspend needs to clear all root port wake on bits. Otherwise some Intel\nplatforms may get a spurious wakeup, even if PCI PME# is disabled.\n\nThis patch should be back-ported to kernels as old as 2.6.37, that\ncontains the commit 9777e3ce907d4cb5a513902a87ecd03b52499569\n\"USB: xHCI: bus power management implementation\".\n\nSigned-off-by: Lu Baolu <baolu.lu@linux.intel.com>\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Lu Baolu",true],["54f216e45c7926999ba53d324ce7c207b07f5bae","c4705e48abd5088318b447f8eff764356f4b2fc8@intel.com","xhci: Fix runtime suspended xhci from blocking system suspend.\n\ncommit d6236f6d1d885aa19d1cd7317346fe795227a3cc upstream.\n\nThe system suspend flow as following:\n1, Freeze all user processes and kenrel threads.\n\n2, Try to suspend all devices.\n\n2.1, If pci device is in RPM suspended state, then pci driver will try\nto resume it to RPM active state in the prepare stage.\n\n2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two\nworkqueue items to resume usb2&usb3 roothub devices.\n\n2.3, Call suspend callbacks of devices.\n\n2.3.1, All suspend callbacks of all hcd's children, including\nroothub devices are called.\n\n2.3.2, Finally, hcd_pci_suspend callback is called.\n\nDue to workqueue threads were already frozen in step 1, the workqueue\nitems can't be scheduled, and the roothub devices can't be resumed in\nthis flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in\nusb_hcd_resume_root_hub won't be cleared. Finally,\nhcd_pci_suspend will return -EBUSY, and system suspend fails.\n\nThe reason why this issue doesn't show up very often is due to that\nchoose_wakeup will be called in step 2.3.1. In step 2.3.1, if\nudev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then\nudev will resume to RPM active for changing the wakeup settings. This\nhas been a lucky hit which hides this issue.\n\nFor some special xHCI controllers which have no USB2 port, then roothub\nwill not match hub driver due to probe failed. Then its\ndo_remote_wakeup will be set to zero, and we won't be as lucky.\n\nxhci driver doesn't need to resume roothub devices everytime like in\nthe above case. It's only needed when there are pending event TRBs.\n\nThis patch should be back-ported to kernels as old as 3.2, that\ncontains the commit f69e3120df82391a0ee8118e0a156239a06b2afb\n\"USB: XHCI: resume root hubs when the controller resumes\"\n\nSigned-off-by: Wang, Yu <yu.y.wang@intel.com>\nAcked-by: Alan Stern <stern@rowland.harvard.edu>\n[use readl() instead of removed xhci_readl(), reword commit message -Mathias]\nSigned-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Wang, Yu",true],["d9916e33837bcb661d0faad19641eca425c1a52d","bf668d4b220231d97fe248d4ae0ba63a1d887e4c@linux.vnet.ibm.com","ibmvscsi: Abort init sequence during error recovery\n\ncommit 9ee755974bea2f9880e517ec985dc9dede1b3a36 upstream.\n\nIf a CRQ reset is triggered for some reason while in the middle\nof performing VSCSI adapter initialization, we don't want to\ncall the done function for the initialization MAD commands as\nthis will only result in two threads attempting initialization\nat the same time, resulting in failures.\n\nSigned-off-by: Brian King <brking@linux.vnet.ibm.com>\nAcked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>\nSigned-off-by: Christoph Hellwig <hch@lst.de>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Brian King",true],["a89c6d3b6c9660ef09bc794135400b2f8f16db8f","bf668d4b220231d97fe248d4ae0ba63a1d887e4c@linux.vnet.ibm.com","ibmvscsi: Add memory barriers for send / receive\n\ncommit 7114aae02742d6b5c5a0d39a41deb61d415d3717 upstream.\n\nAdd a memory barrier prior to sending a new command to the VIOS\nto ensure the VIOS does not receive stale data in the command buffer.\nAlso add a memory barrier when processing the CRQ for completed commands.\n\nSigned-off-by: Brian King <brking@linux.vnet.ibm.com>\nAcked-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>\nSigned-off-by: Christoph Hellwig <hch@lst.de>\n[bwh: Backported to 3.2: as the iSeries code is still present, these\n functions have different names and live in rpa_vscsi.c.]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Brian King",true],["08c7de520767720580585c7d6b03a83f8cc694ee","9eae2d327ddc4c2ff66f290d0aa6288f14fc5928@cn.fujitsu.com","cpuset,mempolicy: fix sleeping function called from invalid context\n\ncommit 391acf970d21219a2a5446282d3b20eace0c0d7a upstream.\n\nWhen runing with the kernel(3.15-rc7+), the follow bug occurs:\n[ 9969.258987] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:586\n[ 9969.359906] in_atomic(): 1, irqs_disabled(): 0, pid: 160655, name: python\n[ 9969.441175] INFO: lockdep is turned off.\n[ 9969.488184] CPU: 26 PID: 160655 Comm: python Tainted: G       A      3.15.0-rc7+ #85\n[ 9969.581032] Hardware name: FUJITSU-SV PRIMEQUEST 1800E/SB, BIOS PRIMEQUEST 1000 Series BIOS Version 1.39 11/16/2012\n[ 9969.706052]  ffffffff81a20e60 ffff8803e941fbd0 ffffffff8162f523 ffff8803e941fd18\n[ 9969.795323]  ffff8803e941fbe0 ffffffff8109995a ffff8803e941fc58 ffffffff81633e6c\n[ 9969.884710]  ffffffff811ba5dc ffff880405c6b480 ffff88041fdd90a0 0000000000002000\n[ 9969.974071] Call Trace:\n[ 9970.003403]  [<ffffffff8162f523>] dump_stack+0x4d/0x66\n[ 9970.065074]  [<ffffffff8109995a>] __might_sleep+0xfa/0x130\n[ 9970.130743]  [<ffffffff81633e6c>] mutex_lock_nested+0x3c/0x4f0\n[ 9970.200638]  [<ffffffff811ba5dc>] ? kmem_cache_alloc+0x1bc/0x210\n[ 9970.272610]  [<ffffffff81105807>] cpuset_mems_allowed+0x27/0x140\n[ 9970.344584]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150\n[ 9970.409282]  [<ffffffff811b1385>] __mpol_dup+0xe5/0x150\n[ 9970.471897]  [<ffffffff811b1303>] ? __mpol_dup+0x63/0x150\n[ 9970.536585]  [<ffffffff81068c86>] ? copy_process.part.23+0x606/0x1d40\n[ 9970.613763]  [<ffffffff810bf28d>] ? trace_hardirqs_on+0xd/0x10\n[ 9970.683660]  [<ffffffff810ddddf>] ? monotonic_to_bootbased+0x2f/0x50\n[ 9970.759795]  [<ffffffff81068cf0>] copy_process.part.23+0x670/0x1d40\n[ 9970.834885]  [<ffffffff8106a598>] do_fork+0xd8/0x380\n[ 9970.894375]  [<ffffffff81110e4c>] ? __audit_syscall_entry+0x9c/0xf0\n[ 9970.969470]  [<ffffffff8106a8c6>] SyS_clone+0x16/0x20\n[ 9971.030011]  [<ffffffff81642009>] stub_clone+0x69/0x90\n[ 9971.091573]  [<ffffffff81641c29>] ? system_call_fastpath+0x16/0x1b\n\nThe cause is that cpuset_mems_allowed() try to take\nmutex_lock(&callback_mutex) under the rcu_read_lock(which was hold in\n__mpol_dup()). And in cpuset_mems_allowed(), the access to cpuset is\nunder rcu_read_lock, so in __mpol_dup, we can reduce the rcu_read_lock\nprotection region to protect the access to cpuset only in\ncurrent_cpuset_is_being_rebound(). So that we can avoid this bug.\n\nThis patch is a temporary solution that just addresses the bug\nmentioned above, can not fix the long-standing issue about cpuset.mems\nrebinding on fork():\n\n\"When the forker's task_struct is duplicated (which includes\n ->mems_allowed) and it races with an update to cpuset_being_rebound\n in update_tasks_nodemask() then the task's mems_allowed doesn't get\n updated. And the child task's mems_allowed can be wrong if the\n cpuset's nodemask changes before the child has been added to the\n cgroup's tasklist.\"\n\nSigned-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>\nAcked-by: Li Zefan <lizefan@huawei.com>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Gu Zheng",true],["e70acb57de1a6ae6dc930e5316a14e1ae60a99d2","7343c7ffb424bf4c3ebd1cd0c94117b3c12118ff@marvell.com","mwifiex: fix Tx timeout issue\n\ncommit d76744a93246eccdca1106037e8ee29debf48277 upstream.\n\nhttps://bugzilla.kernel.org/show_bug.cgi?id=70191\nhttps://bugzilla.kernel.org/show_bug.cgi?id=77581\n\nIt is observed that sometimes Tx packet is downloaded without\nadding driver's txpd header. This results in firmware parsing\ngarbage data as packet length. Sometimes firmware is unable\nto read the packet if length comes out as invalid. This stops\nfurther traffic and timeout occurs.\n\nThe root cause is uninitialized fields in tx_info(skb->cb) of\npacket used to get garbage values. In this case if\nMWIFIEX_BUF_FLAG_REQUEUED_PKT flag is mistakenly set, txpd\nheader was skipped. This patch makes sure that tx_info is\ncorrectly initialized to fix the problem.\n\nReported-by: Andrew Wiley <wiley.andrew.j@gmail.com>\nReported-by: Linus Gasser <list@markas-al-nour.org>\nReported-by: Michael Hirsch <hirsch@teufel.de>\nTested-by: Xinming Hu <huxm@marvell.com>\nSigned-off-by: Amitkumar Karwar <akarwar@marvell.com>\nSigned-off-by: Maithili Hinge <maithili@marvell.com>\nSigned-off-by: Avinash Patil <patila@marvell.com>\nSigned-off-by: Bing Zhao <bzhao@marvell.com>\nSigned-off-by: John W. Linville <linville@tuxdriver.com>\n[bwh: Backported to 3.2: adjust context]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Amitkumar Karwar",true],["fde2b7c55aa3a1a353288b1f62f06804416c19a6","51738506c1b2ccb0761f23bdc612c93babf738ea@redhat.com","nfsd: fix rare symlink decoding bug\n\ncommit 76f47128f9b33af1e96819746550d789054c9664 upstream.\n\nAn NFS operation that creates a new symlink includes the symlink data,\nwhich is xdr-encoded as a length followed by the data plus 0 to 3 bytes\nof zero-padding as required to reach a 4-byte boundary.\n\nThe vfs, on the other hand, wants null-terminated data.\n\nThe simple way to handle this would be by copying the data into a newly\nallocated buffer with space for the final null.\n\nThe current nfsd_symlink code tries to be more clever by skipping that\nstep in the (likely) case where the byte following the string is already\n0.\n\nBut that assumes that the byte following the string is ours to look at.\nIn fact, it might be the first byte of a page that we can't read, or of\nsome object that another task might modify.\n\nWorse, the NFSv4 code tries to fix the problem by actually writing to\nthat byte.\n\nIn the NFSv2/v3 cases this actually appears to be safe:\n\n\t- nfs3svc_decode_symlinkargs explicitly null-terminates the data\n\t  (after first checking its length and copying it to a new\n\t  page).\n\t- NFSv2 limits symlinks to 1k.  The buffer holding the rpc\n\t  request is always at least a page, and the link data (and\n\t  previous fields) have maximum lengths that prevent the request\n\t  from reaching the end of a page.\n\nIn the NFSv4 case the CREATE op is potentially just one part of a long\ncompound so can end up on the end of a page if you're unlucky.\n\nThe minimal fix here is to copy and null-terminate in the NFSv4 case.\nThe nfsd_symlink() interface here seems too fragile, though.  It should\nreally either do the copy itself every time or just require a\nnull-terminated string.\n\nReported-by: Jeff Layton <jlayton@primarydata.com>\nSigned-off-by: J. Bruce Fields <bfields@redhat.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","J. Bruce Fields",true],["949ff4d69cf2497e9a0b1302979818cd944af02b","605208d9b4c769ca62e9f9f8b592c9cd465fe6d7@mina86.com","tools: ffs-test: fix header values endianess\n\ncommit f35f71244da6e51db4e1f2c7e318581f498ececf upstream.\n\nIt appears that no one ever run ffs-test on a big-endian machine,\nsince it used cpu-endianess for fs_count and hs_count fields which\nshould be in little-endian format.  Fix by wrapping the numbers in\ncpu_to_le32.\n\nSigned-off-by: Michal Nazarewicz <mina86@mina86.com>\nSigned-off-by: Felipe Balbi <balbi@ti.com>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Michal Nazarewicz",true],["27bbd86f9319dbeeb588b8f43fe0ac241ad336ba","75ea6bb7bfc1186f92d26164de5f9268c9a45b59@rowland.harvard.edu","usb-storage/SCSI: Add broken_fua blacklist flag\n\ncommit b14bf2d0c0358140041d1c1805a674376964d0e0 upstream.\n\nSome buggy JMicron USB-ATA bridges don't know how to translate the FUA\nbit in READs or WRITEs.  This patch adds an entry in unusual_devs.h\nand a blacklist flag to tell the sd driver not to use FUA.\n\nSigned-off-by: Alan Stern <stern@rowland.harvard.edu>\nReported-by: Michael Büsch <m@bues.ch>\nTested-by: Michael Büsch <m@bues.ch>\nAcked-by: James Bottomley <James.Bottomley@HansenPartnership.com>\nCC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\n[bwh: Backported to 3.2:\n - Adjust context\n - Use sd_printk() not sd_first_printk()]\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","Alan Stern",true],["0fda305647fbf6894015df9b350aebdcf540d0cf","e293c7e13ecc029aa287dca4b8ecfdf8a10ea3b9@jp.fujitsu.com","perf/x86/intel: ignore CondChgd bit to avoid false NMI handling\n\ncommit b292d7a10487aee6e74b1c18b8d95b92f40d4a4f upstream.\n\nCurrently, any NMI is falsely handled by a NMI handler of NMI watchdog\nif CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set.\n\nFor example, we use external NMI to make system panic to get crash\ndump, but in this case, the external NMI is falsely handled do to the\nissue.\n\nThis commit deals with the issue simply by ignoring CondChgd bit.\n\nHere is explanation in detail.\n\nOn x86 NMI watchdog uses performance monitoring feature to\nperiodically signal NMI each time performance counter gets overflowed.\n\nintel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI\nhandler of NMI watchdog, perf_event_nmi_handler(). It identifies an\nowner of a given NMI by looking at overflow status bits in\nMSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it\nhandles the given NMI as its own NMI.\n\nThe problem is that the intel_pmu_handle_irq() doesn't distinguish\nCondChgd bit from other bits. Unlike the other status bits, CondChgd\nbit doesn't represent overflow status for performance counters. Thus,\nCondChgd bit cannot be thought of as a mark indicating a given NMI is\nNMI watchdog's.\n\nAs a result, if CondChgd bit is set, any NMI is falsely handled by the\nNMI handler of NMI watchdog. Also, if type of the falsely handled NMI\nis either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding\naction is never performed until CondChgd bit is cleared.\n\nI noticed this behavior on systems with Ivy Bridge processors: Intel\nXeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems,\nCondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set\nin the beginning at boot. Then the CondChgd bit is immediately cleared\nby next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain\n0.\n\nOn the other hand, on older processors such as Nehalem, Xeon E7540,\nCondChgd bit is not set in the beginning at boot.\n\nI'm not sure about exact behavior of CondChgd bit, in particular when\nthis bit is set. Although I read Intel System Programmer's Manual to\nfigure out that, the descriptions I found are:\n\n  In 18.9.1:\n\n  \"The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to\n   indicate changes to the state of performancmonitoring hardware\"\n\n  In Table 35-2 IA-32 Architectural MSRs\n\n  63 CondChg: status bits of this register has changed.\n\nThese are different from the bahviour I see on the actual system as I\nexplained above.\n\nAt least, I think ignoring CondChgd bit should be enough for NMI\nwatchdog perspective.\n\nSigned-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>\nAcked-by: Don Zickus <dzickus@redhat.com>\nSigned-off-by: Peter Zijlstra <peterz@infradead.org>\nCc: Arnaldo Carvalho de Melo <acme@kernel.org>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: linux-kernel@vger.kernel.org\nLink: http://lkml.kernel.org/r/20140625.103503.409316067.d.hatayama@jp.fujitsu.com\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","HATAYAMA Daisuke",true],["74d31de64a0bc7a37a0020e9ddb10af1047ddbbf","1c00aa603bb92d594c03cff60ecf8e63b2a5bcb1@suse.de","md: flush writes before starting a recovery.\n\ncommit 133d4527eab8d199a62eee6bd433f0776842df2e upstream.\n\nWhen we write to a degraded array which has a bitmap, we\nmake sure the relevant bit in the bitmap remains set when\nthe write completes (so a 're-add' can quickly rebuilt a\ntemporarily-missing device).\n\nIf, immediately after such a write starts, we incorporate a spare,\ncommence recovery, and skip over the region where the write is\nhappening (because the 'needs recovery' flag isn't set yet),\nthen that write will not get to the new device.\n\nOnce the recovery finishes the new device will be trusted, but will\nhave incorrect data, leading to possible corruption.\n\nWe cannot set the 'needs recovery' flag when we start the write as we\ndo not know easily if the write will be \"degraded\" or not.  That\ndepends on details of the particular raid level and particular write\nrequest.\n\nThis patch fixes a corruption issue of long standing and so it\nsuitable for any -stable kernel.  It applied correctly to 3.0 at\nleast and will minor editing to earlier kernels.\n\nReported-by: Bill <billstuff2001@sbcglobal.net>\nTested-by: Bill <billstuff2001@sbcglobal.net>\nLink: http://lkml.kernel.org/r/53A518BB.60709@sbcglobal.net\nSigned-off-by: NeilBrown <neilb@suse.de>\nSigned-off-by: Ben Hutchings <ben@decadent.org.uk>","NeilBrown",true]],"size":95,"ref":"refs/heads/master","head":"73886aa084e0c32293a609532b629f813eb42fdd"}