- 09 Aug, 2016 18 commits
-
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1602724 This fixes a scenario where device is present and being reset, but a request to unbind the driver occurs. A previous patch series addressing a device failure removal scenario flushed reset_work after controller disable to unblock reset_work waiting on a completion that wouldn't occur. This isn't safe as-is. The broken scenario can potentially be induced with: modprobe nvme && modprobe -r nvme To fix, the reset work is flushed immediately after setting the controller removing flag, and any subsequent reset will not proceed with controller initialization if the flag is set. The controller status must be polled while active, so the watchdog timer is also left active until the controller is disabled to cleanup requests that may be stuck during namespace removal. [Fixes: ff23a2a1] Signed-off-by:
Keith Busch <keith.busch@intel.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from commit 9bf2b972) Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1602724 The only work left in the kthread is the periodic health check for each controller. There is no need to run this from process context or keep a thread context around for it, so replace it with a simpler timer. Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1602724 There is no reason to do unconditional polling of CQs per the NVMe spec. Signed-off-by:
-
Christoph Hellwig authored
BugLink: http://bugs.launchpad.net/bugs/1602724 Use a dedicated work item to submit async event requests instead of the global kthread. This simplifies the code and reduces the latencies to resubmit a request once an even notification happened. Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1602524 upstream commit 2d90c160 Using SEEK_DATA in a huge sparse file can easily lead to sotflockups as ext4_seek_data() iterates hole block-by-block. Fix the problem by using returned hole size from ext4_map_blocks() and thus skip the hole in one go. Update also SEEK_HOLE implementation to follow the same pattern as SEEK_DATA to make future maintenance easier. Furthermore we add cond_resched() to both ext4_seek_data() and ext4_seek_hole() to avoid softlockups in case evil user creates huge fragmented file and we have to go through lots of extents. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1602524 upstream commit facab4d9 Currently, ext4_map_blocks() just returns 0 when it finds a hole and allocation is not requested. However we have all the information available to tell how large the hole actually is and there are callers of ext4_map_blocks() which would save some block-by-block hole iteration if they knew this information. So fill in struct ext4_map_blocks even for holes with the information we have. We keep returning 0 for holes to maintain backward compatibility of the function. Signed-off-by:
-
Jan Kara authored
BugLink: http://bugs.launchpad.net/bugs/1602524 upstream commit 140a5250 ext4_ext_put_gap_in_cache() determines hole size in the extent tree, then trims this with possible delayed allocated blocks, and inserts the result into the extent status tree. Factor out determination of the size of the hole in the extent tree as we will need this information in ext4_ext_map_blocks() as well. Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1604344Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Gavin Shan authored
BugLink: http://bugs.launchpad.net/bugs/1603449 The PE primary bus cannot be got from its child devices when having full hotplug in error recovery. The PE primary bus is cached, which is done in commit <05ba75f8> ("powerpc/eeh: Fix stale cached primary bus"). In eeh_reset_device(), the flag (EEH_PE_PRI_BUS) is cleared before the PCI hot remove. eeh_pe_bus_get() then returns NULL as the PE primary bus in pnv_eeh_reset() and it crashes the kernel eventually. This fixes the issue by clearing the flag (EEH_PE_PRI_BUS) before the PCI hot add. With it, the PowerNV EEH reset backend (pnv_eeh_reset()) can get valid PE primary bus through eeh_pe_bus_get(). Fixes: 67086e32 ("powerpc/eeh: powerpc/eeh: Support error recovery for VF PE") Reported-by:
Pridhiviraj Paidipeddi <ppaiddipe@in.ibm.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> (backported from commit a3aa256b) Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1603574 The domain/PHB field of PCI addresses has its value obtained from a global variable, incremented each time a new domain (represented by struct pci_controller) is added on the system. The domain addition process happens during boot or due to PHB hotplug add. As recent kernels are using predictable naming for network interfaces, the network stack is more tied to PCI naming. This can be a problem in hotplug scenarios, because PCI addresses will change if devices are removed and then re-added. This situation seems unusual, but it can happen if a user wants to replace a NIC without rebooting the machine, for example. This patch changes the way PCI domain values are generated: now, we use device-tree properties to assign fixed PHB numbers to PCI addresses when available (meaning pSeries and PowerNV cases). We also use a bitmap to allow dynamic PHB numbering when device-tree properties are not used. This bitmap keeps track of used PHB numbers and if a PHB is released (by hotplug operations for example), it allows the reuse of this PHB number, avoiding PCI address to change in case of device remove and re-add soon after. No functional changes were introduced. Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Reviewed-by:
Ian Munsie <imunsie@au1.ibm.com> Acked-by:
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1602726 When disabling the controller, the specification says the register NVME_REG_CC should be written and then driver needs to wait the adapter to be ready, which is checked by reading another register bit (NVME_CSTS_RDY). There's a timeout validation in this checking, so in case this timeout is reached the driver gives up and removes the adapter from the system. After a firmware activation procedure, the PCI_DEVICE(0x1c58, 0x0003) (HGST adapter) end up being removed if we issue a reset_controller, because driver keeps verifying the NVME_REG_CSTS until the timeout is reached. This patch adds a necessary quirk for this adapter, by introducing a delay before nvme_wait_ready(), so the reset procedure is able to be completed. This quirk is needed because just increasing the timeout is not enough in case of this adapter - the driver must wait before start reading NVME_REG_CSTS register on this specific device. Signed-off-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1602726 The NVMe specification does not require discarded blocks return zeroes on read, but provides that behavior as a possibility. Some applications more efficiently use an SSD if reads on discarded blocks were deterministically zero, based on the "discard_zeroes_data" queue attribute. There is no specification defined way to determine device behavior on discarded blocks, so the driver always left the queue setting disabled. We can only know behavior based on individual device models, so this patch adds a flag to the NVMe "quirk" list that vendors may set if they know their controller works that way. The patch also sets the new flag for one such known device. Signed-off-by:
Artur Paszkiewicz <artur.paszkiewicz@intel.com> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
-
Samuel Gauthier authored
BugLink: http://bugs.launchpad.net/bugs/1603468 Only the first and last netlink message for a particular conntrack are actually sent. The first message is sent through nf_conntrack_confirm when the conntrack is committed. The last one is sent when the conntrack is destroyed on timeout. The other conntrack state change messages are not advertised. When the conntrack subsystem is used from netfilter, nf_conntrack_confirm is called for each packet, from the postrouting hook, which in turn calls nf_ct_deliver_cached_events to send the state change netlink messages. This commit fixes the problem by calling nf_ct_deliver_cached_events in the non-commit case as well. Fixes: 7f8a436e ("openvswitch: Add conntrack action") CC: Joe Stringer <joestringer@nicira.com> CC: Justin Pettit <jpettit@nicira.com> CC: Andy Zhou <azhou@nicira.com> CC: Thomas Graf <tgraf@suug.ch> Signed-off-by:
Samuel Gauthier <samuel.gauthier@6wind.com> Acked-by:
Joe Stringer <joe@ovn.org> Signed-off-by:
David S. Miller <davem@davemloft.net> (back ported from commit d913d3a7) Signed-off-by:
-
Philippe Bergheaud authored
BugLink: http://bugs.launchpad.net/bugs/1602785 One should not attempt to switch a PHB into CAPI mode if there is a switch between the PHB and the adapter. This patch modifies the cxl driver to ignore CAPI adapters misplaced in switched slots. Signed-off-by:
Philippe Bergheaud <felix@linux.vnet.ibm.com> Reviewed-by:
Frederic Barrat <fbarrat@linux.vnet.ibm.com> Acked-by:
-
Ashutosh Dixit authored
The MIC VOP driver does two successive reads from user space to read a variable length data structure. Kernel memory corruption can result if the data structure changes between the two reads. This patch disallows the chance of this happening. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116651 Reported by: Pengfei Wang <wpengfeinudt@gmail.com> Reviewed-by:
Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (backported from commit 9bf292bf) [ luis: apply changes to mic_copy_dp_entry(), in file drivers/misc/mic/host/mic_virtio.c; adjust context ] CVE-2016-5728 Signed-off-by:
-
Kangjie Lu authored
The last field "flags" of object "minfo" is not initialized. Copying this object out may leak kernel stack data. Assign 0 to it to avoid leak. Signed-off-by:
Kangjie Lu <kjlu@gatech.edu> Acked-by:
Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by: -
Stefan Bader authored
Ignore: yes Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
- 27 Jul, 2016 3 commits
-
-
Seth Forshee authored
Signed-off-by:Seth Forshee <seth.forshee@canonical.com>
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1606147 Monitored cached line may not wake up from mwait on certain Goldmont based CPUs. This patch will avoid calling current_set_polling_and_test() and thereby not set the TIF_ flag. The result is that we'll always send IPIs for wakeups. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Len Brown <lenb@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1468867270-18493-1-git-send-email-jacob.jun.pan@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> (backported from linux-next commit 08e237fa) Signed-off-by:
Phidias Chiang <phidias.chiang@canonical.com> Acked-by:
-
Dave Hansen authored
BugLink: http://bugs.launchpad.net/bugs/1606147 Problem: We have a boatload of open-coded family-6 model numbers. Half of them have these model numbers in hex and the other half in decimal. This makes grepping for them tons of fun, if you were to try. Solution: Consolidate all the magic numbers. Put all the definitions in one header. The names here are closely derived from the comments describing the models from arch/x86/events/intel/core.c. We could easily make them shorter by doing things like s/SANDYBRIDGE/SNB/, but they seemed fine even with the longer versions to me. Do not take any of these names too literally, like "DESKTOP" or "MOBILE". These are all colloquial names and not precise descriptions of everywhere a given model will show up. Signed-off-by:
Dave Hansen <dave.hansen@linux.intel.com> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Darren Hart <dvhart@infradead.org> Cc: Dave Hansen <dave@sr71.net> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Doug Thompson <dougthompson@xmission.com> Cc: Eduardo Valentin <edubezval@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Kan Liang <kan.liang@intel.com> Cc: Len Brown <lenb@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com> Cc: Souvik Kumar Chakravarty <souvik.k.chakravarty@intel.com> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Vishwanath Somayaji <vishwanath.somayaji@intel.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: jacob.jun.pan@intel.com Cc: linux-acpi@vger.kernel.org Cc: linux-edac@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: platform-driver-x86@vger.kernel.org Link: http://lkml.kernel.org/r/20160603001927.F2A7D828@viggo.jf.intel.comSigned-off-by:
-
- 25 Jul, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 22 Jul, 2016 3 commits
-
-
Seth Forshee authored
Signed-off-by: -
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1603719 302cabb7 "UBUNTU: SAUCE: (namespace) Sync with upstream s_user_ns patches" added a capability check to sget() which causes a regression for automatic submounts, which may happen in the context of an unprivileged user. The capability check is not necessary in this case. The check can be bypassed by using sget_userns() instead. init_user_namespace should be used for the user ns since nfs does not support unprivileged mounting. This change makes the nfs mount behavior in xenial functionally identical to upstream. Acked-by:
-
Andy Whitcroft authored
Ignore: yes Signed-off-by:
-
- 20 Jul, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 19 Jul, 2016 5 commits
-
-
Seth Forshee authored
Signed-off-by: -
Jason Gerecke authored
BugLink: http://bugs.launchpad.net/bugs/1603975 A tablet PC booted into Windows may have its pen/touch hardware switched into "Wacom mode" similar to what we do with explicitly-supported hardware. Some devices appear to maintain this state across reboots, preventing their use with the generic HID driver. This patch adds support for detecting the presence of the mode switch feature report used by devices based on the G9 and G11 chips and has the HID codepath always attempt to reset the device back to sending standard HID reports. Fixes: https://sourceforge.net/p/linuxwacom/bugs/307/ Fixes: https://sourceforge.net/p/linuxwacom/bugs/310/ Fixes: https://github.com/linuxwacom/input-wacom/issues/15Co-authored-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com> Reviewed-by:
Jiri Kosina <jkosina@suse.cz> (cherry picked from commit 326ea2a9) Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Acked-by:
-
Jason Gerecke authored
BugLink: http://bugs.launchpad.net/bugs/1603975 Commit 5ae6e89f introduced hid_data.inputmode with a comment that it would have the value -1 if undefined, but then forgot to actually perform the initialization. Although this doesn't appear to have caused any problems in practice, it should still be remedied. Signed-off-by:
-
Benjamin Tissoires authored
BugLink: http://bugs.launchpad.net/bugs/1603975 Simplifies the .probe() and will allow to reuse this path in the future. Few things are reshuffled in .probe(): - init wacom struct earlier - then retrieve the report descriptor - then parse it and allocate/register inputs. Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1604344Signed-off-by:
-
- 18 Jul, 2016 9 commits
-
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1603483Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1603483Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1603483Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1603483Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1603483Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1603483Signed-off-by:
-
Huawei SSD DEV Team authoredBugLink: http://bugs.launchpad.net/bugs/1603483 Source: http://support.huawei.com/enterprisesearch/ebgSearch#sp.keyword=HUAWEI%20ES3000%20V2%20Driver%20SRC Huawei SSD device driver Copyright (c) 2016, Huawei Technologies Co., Ltd. This program is free software; you can redistribute it and/or modify it under the terms and conditions of the GNU General Public License, version 2, as published by the Free Software Foundation. This program is distributed in the hope it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. Signed-off-by:
-
Richard Alpe authored
Fix incorrect use of nla_strlcpy() where the first NLA_HDRLEN bytes of the link name where left out. Making the output of tipc-config -ls look something like: Link statistics: dcast-link 1:data0-1.1.2:data0 1:data0-1.1.3:data0 Also, for the record, the patch that introduce this regression claims "Sending the whole object out can cause a leak". Which isn't very likely as this is a compat layer, where the data we are parsing is generated by us and we know the string to be NULL terminated. But you can of course never be to secure. Fixes: 5d2be142 (tipc: fix an infoleak in tipc_nl_compat_link_dump) Signed-off-by:
Richard Alpe <richard.alpe@ericsson.com> Signed-off-by:
-
Kangjie Lu authored
link_info.str is a char array of size 60. Memory after the NULL byte is not initialized. Sending the whole object out can cause a leak. Signed-off-by:
-
