- 19 Oct, 2016 3 commits
-
-
Seth Forshee authored
Ignore: yes Signed-off-by:Seth Forshee <seth.forshee@canonical.com>
-
Stefan Bader authored
Signed-off-by:Stefan Bader <stefan.bader@canonical.com>
-
John Johansen authored
path_put() call dput() which might sleep on some paths. When it does sleep from these code paths, the per cpu work buffer may get reused overwriting the data that was just placed in the buffer. This causes the following mediation to fail as the work buffer no longer has valid data for the current operation. BugLink: http://bugs.launchpad.net/bugs/1634753Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by:
-
- 18 Oct, 2016 1 commit
-
-
Linus Torvalds authored
This is an ancient bug that was actually attrempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9 ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f4 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can once more try to fix it by checking the pte_dirty() bit properly (and do it better). Also, the VM has become more scalable, and what was a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by:
Phil "not Paul" Oester <kernel@linuxace.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> CVE-2016-5195 [ saf: Adjust context for missing FOLL_REMOTE ] Signed-off-by:
-
- 17 Oct, 2016 1 commit
-
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 12 Oct, 2016 2 commits
-
-
Seth Forshee authored
Signed-off-by: -
Gavin Guo authored
BugLink: http://bugs.launchpad.net/bugs/1518457 On an AWS t2.micro instance (Xeon E5-2670, 991MiB of memory). Occasionally (about once a day), kswapd0 falls into a busy loop and spins on 100% CPU usage indefinitely. Reject to do the zone balance when the memory is too small. Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Tested-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
- 11 Oct, 2016 1 commit
-
-
Seth Forshee authored
Ignore: yes Signed-off-by:
-
- 07 Oct, 2016 4 commits
-
-
Seth Forshee authored
Signed-off-by: -
Sabrina Dubroca authored
BugLink: http://bugs.launchpad.net/bugs/1631287 Currently, GRO can do unlimited recursion through the gro_receive handlers. This was fixed for tunneling protocols by limiting tunnel GRO to one level with encap_mark, but both VLAN and TEB still have this problem. Thus, the kernel is vulnerable to a stack overflow, if we receive a packet composed entirely of VLAN headers. This patch adds a recursion counter to the GRO layer to prevent stack overflow. When a gro_receive function hits the recursion limit, GRO is aborted for this skb and it is processed normally. Fixes: 9b174d88 ("net: Add Transparent Ethernet Bridging GRO support.") Fixes: 66e5133f ("vlan: Add GRO support for non hardware accelerated vlan") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Reviewed-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Steve Beattie <steve.beattie@canonical.com> [ saf: backported to xenial - Fix up gro_receive callback invocation in udb_gro_receive() - Adjust context ] CVE-2016-7039 Acked-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1631287 This patch should fix the issues seen with a recent fix to prevent tunnel-in-tunnel frames from being generated with GRO. The fix itself is correct for now as long as we do not add any devices that support NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the potential to mess things up due to the fact that the outer transport header points to the outer UDP header and not the GRE header as would be expected. Fixes: fac8e0f5 ("tunnels: Don't apply GRO to multiple layers of encapsulation.") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit c3483384) Acked-by:
-
Jesse Gross authored
BugLink: http://bugs.launchpad.net/bugs/1631287 When drivers express support for TSO of encapsulated packets, they only mean that they can do it for one layer of encapsulation. Supporting additional levels would mean updating, at a minimum, more IP length fields and they are unaware of this. No encapsulation device expresses support for handling offloaded encapsulated packets, so we won't generate these types of frames in the transmit path. However, GRO doesn't have a check for multiple levels of encapsulation and will attempt to build them. UDP tunnel GRO actually does prevent this situation but it only handles multiple UDP tunnels stacked on top of each other. This generalizes that solution to prevent any kind of tunnel stacking that would cause problems. Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack") Signed-off-by:
Jesse Gross <jesse@kernel.org> Signed-off-by:
-
- 28 Sep, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 27 Sep, 2016 2 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1626894 Commit b00a726a upstream. Fix nvme_pci_enable missing initializer accidentally omitted from Xenial backport of 30d6592f "NVMe: Don't unmap controller registers on reset" (and homogenize comment lines with the 4.4.y-stable tree). Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
-
- 26 Sep, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 23 Sep, 2016 4 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1626112 Patch a6b5058f results in -EREMOTE returned by is_path_accessible() in cifs_mount() to be ignored which breaks DFS mounting. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
Steve French <smfrench@gmail.com> (cherry picked from commit de5233745cd59cf5853d963ad216067788a87594 git://git.samba.org/sfrench/cifs-2.6.git) Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1626112 The patch fs/cifs: make share unaccessible at root level mountable makes use of prepaths when any component of the underlying path is inaccessible. When mounting 2 separate shares having different prepaths but are other wise similar in other respects, we end up sharing superblocks when we shouldn't be doing so. Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1626112 Fix memory leaks introduced by the patch fs/cifs: make share unaccessible at root level mountable Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb(). Signed-off-by:
-
- 22 Sep, 2016 3 commits
-
-
Shawn Lee authored
UBUNTU: SAUCE: i915_bpo: drm/i915/backlight: setup backlight pwm alternate increment on backlight enable BugLink: http://bugs.launchpad.net/bugs/1625932 Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 References: https://bugs.freedesktop.org/show_bug.cgi?id=67454 Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Wei Shun Chen <wei.shun.chang@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Cc: stable@vger.kernel.org # v4.4+ 32b421e7 drm/i915/backlight: setup and cache... Cc: stable@vger.kernel.org # v4.4+ Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Shawn Lee <shawn.c.lee@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com (cherry-picked from drm-intel-next-queued commit e29aff05) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Jani Nikula authored
BugLink: http://bugs.launchpad.net/bugs/1625932 This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee <shawn.c.lee@intel.com> Reviewed-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 20 Sep, 2016 1 commit
-
-
Joseph Salisbury authored
Signed-off-by:Joseph Salisbury <joseph.salisbury@canonical.com>
-
- 19 Sep, 2016 10 commits
-
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1624569 On ThunderX 88xx pass 2.x chips when TSO is offloaded to HW, HW posts a CQE for every TSO segment transmitted. Current code does handles this, but is prone to issues when segment sizes are small resulting in SW processing too many CQEs and also at times frees a SKB which is not yet transmitted. This patch handles the errata in a different way and eliminates issues with earlier approach, TSO packet is submitted to HW with post_cqe=0, so that no CQE is posted upon completion of transmission of TSO packet but a additional HDR + IMMEDIATE descriptors are added to SQ due to which a CQE is posted and will have required info to be used while cleanup in napi. This way only one CQE is posted for a TSO packet. Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1623627 There is a issue in HW where-in while sending GSO sized pkts as part of TSO, if pkt len falls below configured min packet size i.e 60, NIC will zero PAD packet and also updates IP total length. Hence set this value to lessthan min pkt size of MAC + IP + TCP headers, BGX will anyway do the padding to transmit 64 byte pkt including FCS. Signed-off-by:
-
Eric Dumazet authored
When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the tail of the write queue using tcp_add_write_queue_tail() Then it attempts to copy user data into this fresh skb. If the copy fails, we undo the work and remove the fresh skb. Unfortunately, this undo lacks the change done to tp->highest_sack and we can leave a dangling pointer (to a freed skb) Later, tcp_xmit_retransmit_queue() can dereference this pointer and access freed memory. For regular kernels where memory is not unmapped, this might cause SACK bugs because tcp_highest_sack_seq() is buggy, returning garbage instead of tp->snd_nxt, but with various debug features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel. This bug was found by Marco Grassi thanks to syzkaller. Fixes: 6859d494 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb") Reported-by:
Marco Grassi <marco.gra@gmail.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Reviewed-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
-
David Britton authored
BugLink: http://bugs.launchpad.net/bugs/1622763 This USB headset doesn't seem to support sample rate polling, similar to this issue: https://bugzilla.kernel.org/show_bug.cgi?id=95961 Every time something goes to interact with the device (playing a sound file, opening the sound panel, opening web audio/video), a 10 second pause is encountered, where dmesg prints out two messages: usb 2-1.2: 2:1: cannot get freq at ep 0x83 usb 2-1.2: 2:1: cannot get freq at ep 0x83 Once the sound is playing, everything is fine. These sample rate polls don't seem to keep happening. After waiting for maybe 30 seconds after sound is playing, future interactions will again trigger the pause. This 10 second pause can introduce other subtle problems. For instance, google hangouts will sometimes timeout waiting for the sound device to respond, and the browser tab will crash or not fully load as a result. The sound panel often also will not display the device in the list of choices, and you will have to close it out. Sometimes restart pulse audio to get it to recognize the headset again. Signed-off-by:
-
Jason Baron authored
BugLink: http://bugs.launchpad.net/bugs/1619766 Skylake adjusts some register locations, but otherwise follows the existing model quite closely. I was able to verify that the 'ce_count' increments when 'bad dimms' are used. The accounting of 'ce_count' and 'ue_count' is the primary functionality of interest for us. Tested on Intel(R) Xeon(R) CPU E3-1260L v5 @ 2.90GHz. Signed-off-by:
Jason Baron <jbaron@akamai.com> Acked-by:
Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/1462547927-22679-1-git-send-email-jbaron@akamai.comSigned-off-by:
Borislav Petkov <bp@suse.de> (cherry picked from commit 953dee9b) Signed-off-by:
-
Gabriel Krisman Bertazi authored
Pending 4.8-rc merge. BugLink: http://bugs.launchpad.net/bugs/1602724 This fixes a regression in my previous commit c21377f8 ("nvme: Suspend all queues before deletion"), which provoked an Oops in the removal path when removing a device that became IO incapable very early at probe (i.e. after a failed EEH recovery). Turns out, if the error occurred very early at the probe path, before even configuring the admin queue, we might try to suspend the uninitialized admin queue, accessing bad memory. Fixes: c21377f8 ("nvme: Suspend all queues before deletion") Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Reviewed-by:
Jay Freyensee <james_p_freyensee@linux.intel.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Jens Axboe authored
BugLink: http://bugs.launchpad.net/bugs/1620317 We do this in a few places, if the CPU is offline. This isn't allowed, though, since on multi queue hardware, we can't just move a request from one software queue to another, if they map to different hardware queues. The request and tag isn't valid on another hardware queue. This can happen if plugging races with CPU offlining. But it does no harm, since it can only happen in the window where we are currently busy freezing the queue and flushing IO, in preparation for redoing the software <-> hardware queue mappings. Signed-off-by:
-
Jens Axboe authored
BugLink: http://bugs.launchpad.net/bugs/1620317 __blk_mq_run_hw_queue() currently warns if we are running the queue on a CPU that isn't set in its mask. However, this can happen if a CPU is being offlined, and the workqueue handling will place the work on CPU0 instead. Improve the warning so that it only triggers if the batch cpu in the hardware queue is currently online. If it triggers for that case, then it's indicative of a flow problem in blk-mq, so we want to retain it for that case. Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1620317 In case a submitted request gets stuck for some reason, the block layer can prevent the request starvation by starting the scheduled timeout work. If this stuck request occurs at the same time another thread has started a queue freeze, the blk_mq_timeout_work will not be able to acquire the queue reference and will return silently, thus not issuing the timeout. But since the request is already holding a q_usage_counter reference and is unable to complete, it will never release its reference, preventing the queue from completing the freeze started by first thread. This puts the request_queue in a hung state, forever waiting for the freeze completion. This was observed while running IO to a NVMe device at the same time we toggled the CPU hotplug code. Eventually, once a request got stuck requiring a timeout during a queue freeze, we saw the CPU Hotplug notification code get stuck inside blk_mq_freeze_queue_wait, as shown in the trace below. [c000000deaf13690] [c000000deaf13738] 0xc000000deaf13738 (unreliable) [c000000deaf13860] [c000000000015ce8] __switch_to+0x1f8/0x350 [c000000deaf138b0] [c000000000ade0e4] __schedule+0x314/0x990 [c000000deaf13940] [c000000000ade7a8] schedule+0x48/0xc0 [c000000deaf13970] [c0000000005492a4] blk_mq_freeze_queue_wait+0x74/0x110 [c000000deaf139e0] [c00000000054b6a8] blk_mq_queue_reinit_notify+0x1a8/0x2e0 [c000000deaf13a40] [c0000000000e7878] notifier_call_chain+0x98/0x100 [c000000deaf13a90] [c0000000000b8e08] cpu_notify_nofail+0x48/0xa0 [c000000deaf13ac0] [c0000000000b92f0] _cpu_down+0x2a0/0x400 [c000000deaf13b90] [c0000000000b94a8] cpu_down+0x58/0xa0 [c000000deaf13bc0] [c0000000006d5dcc] cpu_subsys_offline+0x2c/0x50 [c000000deaf13bf0] [c0000000006cd244] device_offline+0x104/0x140 [c000000deaf13c30] [c0000000006cd40c] online_store+0x6c/0xc0 [c000000deaf13c80] [c0000000006c8c78] dev_attr_store+0x68/0xa0 [c000000deaf13cc0] [c0000000003974d0] sysfs_kf_write+0x80/0xb0 [c000000deaf13d00] [c0000000003963e8] kernfs_fop_write+0x188/0x200 [c000000deaf13d50] [c0000000002e0f6c] __vfs_write+0x6c/0xe0 [c000000deaf13d90] [c0000000002e1ca0] vfs_write+0xc0/0x230 [c000000deaf13de0] [c0000000002e2cdc] SyS_write+0x6c/0x110 [c000000deaf13e30] [c000000000009204] system_call+0x38/0xb4 The fix is to allow the timeout work to execute in the window between dropping the initial refcount reference and the release of the last reference, which actually marks the freeze completion. This can be achieved with percpu_refcount_tryget, which does not require the counter to be alive. This way the timeout work can do it's job and terminate a stuck request even during a freeze, returning its reference and avoiding the deadlock. Allowing the timeout to run is just a part of the fix, since for some devices, we might get stuck again inside the device driver's timeout handler, should it attempt to allocate a new request in that path - which is a quite common action for Abort commands, which need to be sent after a timeout. In NVMe, for instance, we call blk_mq_alloc_request from inside the timeout handler, which will fail during a freeze, since it also tries to acquire a queue reference. I considered a similar change to blk_mq_alloc_request as a generic solution for further device driver hangs, but we can't do that, since it would allow new requests to disturb the freeze process. I thought about creating a new function in the block layer to support unfreezable requests for these occasions, but after working on it for a while, I feel like this should be handled in a per-driver basis. I'm now experimenting with changes to the NVMe timeout path, but I'm open to suggestions of ways to make this generic. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Luke Dashjr authored
BugLink: http://bugs.launchpad.net/bugs/1619918 32-bit ioctl uses these rather than the regular FS_IOC_* versions. They can be handled in btrfs using the same code. Without this, 32-bit {ch,ls}attr fail. Signed-off-by:
Luke Dashjr <luke-jr+git@utopios.org> Cc: stable@vger.kernel.org Reviewed-by:
Josef Bacik <jbacik@fb.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
- 16 Sep, 2016 6 commits
-
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1600092 When I fixed the dp rate selection in: 092c96a8 drm/radeon: fix dp link rate selection (v2) I accidently dropped the special handling for NUTMEG DP bridge chips. They require a fixed link rate. Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Ken Wang <Qingqing.Wang@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Tested-by:
Ken Moffat <zarniwhoop@ntlworld.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit c8213a63) Signed-off-by:
-
Yuval Mintz authored
BugLink: http://bugs.launchpad.net/bugs/1623187 Module is using a binary firmware file and so should be marked as such. Signed-off-by:
Yuval Mintz <Yuval.Mintz@qlogic.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1616677 This change makes it so that we can just use function pointers instead of having to identify if a given VF is running on a Linux or Windows PF. By doing this we can avoid having to pull too much information out of the lower layers and can instead just make use of the mac_ops pointers since they should differ between the two types of VFs anyway. Signed-off-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 2f8214fe) Signed-off-by:
-
Babu Moger authored
BugLink: http://bugs.launchpad.net/bugs/1616677 We noticed performance issues with VF interface on sparc compared to PF. Setting the RX to IXGBE_DCA_RXCTRL_DATA_WRO_EN brings it on far with PF. Also this matches to the default sparc setting in PF driver. Signed-off-by:
Babu Moger <babu.moger@oracle.com> Acked-by:
Sowmini Varadhan <sowmini.varadhan@oracle.com> Tested-by:
-
KY Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1616677 On Hyper-V, the VF/PF communication is a via software mediated path as opposed to the hardware mailbox. Make the necessary adjustments to support Hyper-V. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Tested-by:
-
KY Srinivasan authored
BugLink: http://bugs.launchpad.net/bugs/1616677 Intel SR-IOV cards present different ID when running on Hyper-V. Add the device IDs presented while running on Hyper-V. Signed-off-by:
-
