- 09 Aug, 2016 32 commits
-
-
Jouni Malinen authored
BugLink: http://bugs.launchpad.net/bugs/1607404 commit 126e7557 upstream. If a user space program (e.g., wpa_supplicant) deletes a STA entry that is currently in NL80211_PLINK_ESTAB state, the number of established plinks counter was not decremented and this could result in rejecting new plink establishment before really hitting the real maximum plink limit. For !user_mpm case, this decrementation is handled by mesh_plink_deactive(). Fix this by decrementing estab_plinks on STA deletion (mesh_sta_cleanup() gets called from there) so that the counter has a correct value and the Beacon frame advertisement in Mesh Configuration element shows the proper value for capability to accept additional peers. Signed-off-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Martin Willi authored
BugLink: http://bugs.launchpad.net/bugs/1607404 commit 62397da5 upstream. A wmediumd that does not send this attribute causes a NULL pointer dereference, as the attribute is accessed even if it does not exist. The attribute was required but never checked ever since userspace frame forwarding has been introduced. The issue gets more problematic once we allow wmediumd registration from user namespaces. Fixes: 7882513b ("mac80211_hwsim driver support userspace frame tx/rx") Signed-off-by:
Martin Willi <martin@strongswan.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Bob Copeland authored
BugLink: http://bugs.launchpad.net/bugs/1607404 commit fe7a7c57 upstream. Currently, the mesh paths associated with a nexthop station are cleaned up in the following code path: __sta_info_destroy_part1 synchronize_net() __sta_info_destroy_part2 -> cleanup_single_sta -> mesh_sta_cleanup -> mesh_plink_deactivate -> mesh_path_flush_by_nexthop However, there are a couple of problems here: 1) the paths aren't flushed at all if the MPM is running in userspace (e.g. when using wpa_supplicant or authsae) 2) there is no synchronize_rcu between removing the path and readers accessing the nexthop, which means the following race is possible: CPU0 CPU1 ~~~~ ~~~~ sta_info_destroy_part1() synchronize_net() rcu_read_lock() mesh_nexthop_resolve() mpath = mesh_path_lookup() [...] -> mesh_path_flush_by_nexthop() sta = rcu_dereference( mpath->next_hop) kfree(sta) access sta <-- CRASH Fix both of these by unconditionally flushing paths before destroying the sta, and by adding a synchronize_net() after path flush to ensure no active readers can still dereference the sta. Fixes this crash: [ 348.529295] BUG: unable to handle kernel paging request at 00020040 [ 348.530014] IP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] *pde = 00000000 [ 348.530014] Oops: 0000 [#1] PREEMPT [ 348.530014] Modules linked in: drbg ansi_cprng ctr ccm ppp_generic slhc ipt_MASQUERADE nf_nat_masquerade_ipv4 8021q ] [ 348.530014] CPU: 0 PID: 20597 Comm: wget Tainted: G O 4.6.0-rc5-wt=V1 #1 [ 348.530014] Hardware name: To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080016 11/07/2014 [ 348.530014] task: f64fa280 ti: f4f9c000 task.ti: f4f9c000 [ 348.530014] EIP: 0060:[<f929245d>] EFLAGS: 00010246 CPU: 0 [ 348.530014] EIP is at ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] [ 348.530014] EAX: f4ce63e0 EBX: 00000088 ECX: f3788416 EDX: 00020008 [ 348.530014] ESI: 00000000 EDI: 00000088 EBP: f6409a4c ESP: f6409a40 [ 348.530014] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 [ 348.530014] CR0: 80050033 CR2: 00020040 CR3: 33190000 CR4: 00000690 [ 348.530014] Stack: [ 348.530014] 00000000 f4ce63e0 f5f9bd80 f6409a64 f9291d80 0000ce67 f5d51e00 f4ce63e0 [ 348.530014] f3788416 f6409a80 f9291dc1 f4ce8320 f4ce63e0 f5d51e00 f4ce63e0 f4ce8320 [ 348.530014] f6409a98 f9277f6f 00000000 00000000 0000007c 00000000 f6409b2c f9278dd1 [ 348.530014] Call Trace: [ 348.530014] [<f9291d80>] mesh_nexthop_lookup+0xbb/0xc8 [mac80211] [ 348.530014] [<f9291dc1>] mesh_nexthop_resolve+0x34/0xd8 [mac80211] [ 348.530014] [<f9277f6f>] ieee80211_xmit+0x92/0xc1 [mac80211] [ 348.530014] [<f9278dd1>] __ieee80211_subif_start_xmit+0x807/0x83c [mac80211] [ 348.530014] [<c04df012>] ? sch_direct_xmit+0xd7/0x1b3 [ 348.530014] [<c022a8c6>] ? __local_bh_enable_ip+0x5d/0x7b [ 348.530014] [<f956870c>] ? nf_nat_ipv4_out+0x4c/0xd0 [nf_nat_ipv4] [ 348.530014] [<f957e036>] ? iptable_nat_ipv4_fn+0xf/0xf [iptable_nat] [ 348.530014] [<c04c6f45>] ? netif_skb_features+0x14d/0x30a [ 348.530014] [<f9278e10>] ieee80211_subif_start_xmit+0xa/0xe [mac80211] [ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc [ 348.530014] [<f91bfc7a>] batadv_send_skb_packet+0xd6/0xec [batman_adv] [ 348.530014] [<f91bfdc4>] batadv_send_unicast_skb+0x15/0x4a [batman_adv] [ 348.530014] [<f91b5938>] batadv_dat_send_data+0x27e/0x310 [batman_adv] [ 348.530014] [<f91c30b5>] ? batadv_tt_global_hash_find.isra.11+0x8/0xa [batman_adv] [ 348.530014] [<f91b63f3>] batadv_dat_snoop_outgoing_arp_request+0x208/0x23d [batman_adv] [ 348.530014] [<f91c0cd9>] batadv_interface_tx+0x206/0x385 [batman_adv] [ 348.530014] [<c04c769c>] dev_hard_start_xmit+0x1f8/0x267 [ 348.530014] [<c04c7261>] ? validate_xmit_skb.isra.120.part.121+0x10/0x253 [ 348.530014] [<c04defc6>] sch_direct_xmit+0x8b/0x1b3 [ 348.530014] [<c04c7a9c>] __dev_queue_xmit+0x2c8/0x513 [ 348.530014] [<f80cbd2a>] ? igb_xmit_frame+0x57/0x72 [igb] [ 348.530014] [<c04c7cfb>] dev_queue_xmit+0xa/0xc [ 348.530014] [<f843a326>] br_dev_queue_push_xmit+0xeb/0xfb [bridge] [ 348.530014] [<f843a35f>] br_forward_finish+0x29/0x74 [bridge] [ 348.530014] [<f843a23b>] ? deliver_clone+0x3b/0x3b [bridge] [ 348.530014] [<f843a714>] __br_forward+0x89/0xe7 [bridge] [ 348.530014] [<f843a336>] ? br_dev_queue_push_xmit+0xfb/0xfb [bridge] [ 348.530014] [<f843a234>] deliver_clone+0x34/0x3b [bridge] [ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [<f843a66d>] br_flood+0x77/0x95 [bridge] [ 348.530014] [<f843a809>] br_flood_forward+0x13/0x1a [bridge] [ 348.530014] [<f843a68b>] ? br_flood+0x95/0x95 [bridge] [ 348.530014] [<f843b877>] br_handle_frame_finish+0x392/0x3db [bridge] [ 348.530014] [<c04e9b2b>] ? nf_iterate+0x2b/0x6b [ 348.530014] [<f843baa6>] br_handle_frame+0x1e6/0x240 [bridge] [ 348.530014] [<f843b4e5>] ? br_handle_local_finish+0x6a/0x6a [bridge] [ 348.530014] [<c04c4ba0>] __netif_receive_skb_core+0x43a/0x66b [ 348.530014] [<f843b8c0>] ? br_handle_frame_finish+0x3db/0x3db [bridge] [ 348.530014] [<c023cea4>] ? resched_curr+0x19/0x37 [ 348.530014] [<c0240707>] ? check_preempt_wakeup+0xbf/0xfe [ 348.530014] [<c0255dec>] ? ktime_get_with_offset+0x5c/0xfc [ 348.530014] [<c04c4fc1>] __netif_receive_skb+0x47/0x55 [ 348.530014] [<c04c57ba>] netif_receive_skb_internal+0x40/0x5a [ 348.530014] [<c04c61ef>] napi_gro_receive+0x3a/0x94 [ 348.530014] [<f80ce8d5>] igb_poll+0x6fd/0x9ad [igb] [ 348.530014] [<c0242bd8>] ? swake_up_locked+0x14/0x26 [ 348.530014] [<c04c5d29>] net_rx_action+0xde/0x250 [ 348.530014] [<c022a743>] __do_softirq+0x8a/0x163 [ 348.530014] [<c022a6b9>] ? __hrtimer_tasklet_trampoline+0x19/0x19 [ 348.530014] [<c021100f>] do_softirq_own_stack+0x26/0x2c [ 348.530014] <IRQ> [ 348.530014] [<c022a957>] irq_exit+0x31/0x6f [ 348.530014] [<c0210eb2>] do_IRQ+0x8d/0xa0 [ 348.530014] [<c058152c>] common_interrupt+0x2c/0x40 [ 348.530014] Code: e7 8c 00 66 81 ff 88 00 75 12 85 d2 75 0e b2 c3 b8 83 e9 29 f9 e8 a7 5f f9 c6 eb 74 66 81 e3 8c 005 [ 348.530014] EIP: [<f929245d>] ieee80211_mps_set_frame_flags+0x40/0xaa [mac80211] SS:ESP 0068:f6409a40 [ 348.530014] CR2: 0000000000020040 [ 348.530014] ---[ end trace 48556ac26779732e ]--- [ 348.530014] Kernel panic - not syncing: Fatal exception in interrupt [ 348.530014] Kernel Offset: disabled Reported-by:
Fred Veldini <fred.veldini@gmail.com> Tested-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Felix Fietkau authored
BugLink: http://bugs.launchpad.net/bugs/1607404 commit 6fe04128 upstream. The header field is defined as u8[] but also accessed as struct ieee80211_hdr. Enforce an alignment of 2 to prevent unnecessary unaligned accesses, which can be very harmful for performance on many platforms. Fixes: e495c247 ("mac80211: extend fast-xmit for more ciphers") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
-
Paolo Pisati authored
1) the branch name is only useful when distributing the snapcraft.yaml alone - when it is part of a git tree, the branch name should be omitted if the intention is to snap the branch containing the snapcraft.yaml file itself 2) SQUASHFs is not a separate module anymore (see da89f0b2) 3) d101m_ucode.bin, d101s_ucode.bin and d102e_ucode.bin are only necessary when using an Intel(R) PRO/100 nic, while the main amd64 target is kvm (and that uses an Intel e1000 firmware-less nic) Signed-off-by:
Paolo Pisati <paolo.pisati@canonical.com> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1605344 As a precaution, the pid namespace support in fuse was written to refuse to send requests from processes whose pid has no mapping into the pid namespace of the userspace fuse process. This has caused a regression for at least one user, who is mounting a fuse filesystem within a container and exporting a file within the fuse fs to the host via a loop device. Change this to send the request when the pid has no mapping and fill in the pid field in the fuse request with 0. This behavior was settled on in consultation with upstream. The risk of doing this is that a fuse fs which receives this invalid pid might not be prepared to handle it, but it would already be receiving pids not valid in its namespace if used in this manner. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
James Patrick-Evans authored
Fix a memory leak on probe error of the airspy usb device driver. The problem is triggered when more than 64 usb devices register with v4l2 of type VFL_TYPE_SDR or VFL_TYPE_SUBDEV. The memory leak is caused by the probe function of the airspy driver mishandeling errors and not freeing the corresponding control structures when an error occours registering the device to v4l2 core. A badusb device can emulate 64 of these devices, and then through continual emulated connect/disconnect of the 65th device, cause the kernel to run out of RAM and crash the kernel, thus causing a local DOS vulnerability. Fixes CVE-2016-5400 Signed-off-by:
James Patrick-Evans <james@jmp-e.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org # 3.17+ Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit aa93d1fe) CVE-2016-5400 Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1607374 Mounting proc in user namespace containers fails if the xenbus filesystem is mounted on /proc/xen because this directory fails the "permanently empty" test. proc_create_mount_point() exists specifically to create such mountpoints in proc but is currently proc-internal. Export this interface to modules, then use it in xenbus when creating /proc/xen. Signed-off-by:
-
Alex Hung authored
BugLink: http://bugs.launchpad.net/bugs/1607153 Newer ideapads support a new mic hotkey implemented via an ACPI interface. This patch converts the mic mute event to a keycode KEY_MICMUTE. Signed-off-by:
Alex Hung <alex.hung@canonical.com> Acked-by:
Ike Panhc <ike.pan@canonical.com> Signed-off-by:
Darren Hart <dvhart@linux.intel.com> (cherry picked from commit 48f67d62) Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1604995 For 4K LBA or very large disks, atari_partition can easily get tricked into thinking it has found an Atari partition table. Depending on the data in the disk, it ends up creating partitions with awkward lengths. We saw logs like this while playing with fio. [5.625867] nvme2n1: AHDI p2 [5.625872] nvme2n1: p2 size 2910030523 extends beyond EOD, truncated People has had issues with misinterpreted AHDI partition tables for a long time, see this BSD thread from 1995, for example. https://mail-index.netbsd.org/port-atari/1995/11/19/0001.html Since the atari partition, according to the spec, doesn't even support sector sizes with more than 512, a quick sanity check is reasonable to just bail out early, before even attempting to read sector 0. Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
Jens Axboe <axboe@fb.com> (cherry picked from linux-next commit 9c874716) Signed-off-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Tim Gardner authored
Signed-off-by: -
Stefan Bader authored
We had this setting from Oneiric to Saucy[1]. In Saucy it was part of the combined patch to make vesafb a module, which was unnessesary in Trusty as we moved back to built-in. Was added back in Trusty but again lost after Vivid. It will still be possible to disable mtrr by putting video=vesafb:nomtrr or video=vesafb:mtrr:<x> on the kernel command-line but without that knowledge the default will be noticably slower (especially on higher resolutions). [1] https://lists.ubuntu.com/archives/kernel-team/2011-May/015600.html BugLink: http://bugs.launchpad.net/bugs/1605662 (forward-ported from trusty by adapting file location) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Keith Busch authored
BugLink: http://bugs.launchpad.net/bugs/1602724 Multiple users have reported device initialization failure due the driver not receiving legacy PCI interrupts. This is not unique to any particular controller, but has been observed on multiple platforms. There have been no issues reported or observed when with message signaled interrupts, so this patch attempts to use MSI-x during initialization, falling back to MSI. If that fails, legacy would become the default. The setup_io_queues error handling had to change as a result: the admin queue's msix_entry used to be initialized to the legacy IRQ. The case where nr_io_queues is 0 would fail request_irq when setting up the admin queue's interrupt since re-enabling MSI-x fails with 0 vectors, leaving the admin queue's msix_entry invalid. Instead, return success immediately. Reported-by:
Tim Muhlemmer <muhlemmer@gmail.com> Reported-by:
Jon Derrick <jonathan.derrick@intel.com> Signed-off-by:
Keith Busch <keith.busch@intel.com> Signed-off-by:
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1602724 This patch adds a check on nvme_watchdog_timer() function to avoid the call to reset_work() when an error recovery process is ongoing on controller. The check is made by looking at pci_channel_offline() result. If we don't check for this on nvme_watchdog_timer(), error recovery mechanism can't recover well, because reset_work() won't be able to do its job (since we're in the middle of an error) and so the controller is removed from the system before error recovery mechanism can perform slot reset (which would allow the adapter to recover). In this patch we also have split the huge condition expression on nvme_watchdog_timer() by introducing an auxiliary function to help make the code more readable. Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by:
-
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:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
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:
-
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:
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:
-
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:
-
- 27 Jul, 2016 3 commits
-
-
Seth Forshee authored
Signed-off-by: -
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:
-
