John Johansen [Sun, 4 Oct 2015 22:51:45 +0000 (15:51 -0700)]
UBUNTU: SAUCE: apparmor: Fix: ensure new labels resulting from merge have a replacedby
BugLink: http://bugs.launchpad.net/bugs/1448912
Basic profile labels always have a replacedby allocated and set but
the code used to create labels from merges without a replacedby and
let label_update allocate and set those labels replacedby structs.
While the label_merge fix addressed the race between label_merge and
label_update, it still left a bug where labels from merges race
label_update so that they remain permanently stale, because they
don't have proper replacedby information that should be updated during
their replacement.
Specifically a label from a merge will not have a replacedby if it has
never been through a label_update cycle, and the direct replacement
from the label_merge fix is NOT updating the replacedby to avoid doing
allocations under lock. This results in the old label being permanently
diconnected and its references never updating correctly.
To fix this create all labels that result from a merge with a replacedby.
This results in all labels inserted into the labelset having valid
replacedby structs. In the case that the insertion of a label results
in a replacement due to it creating an updated version of the label,
the old labels replacedby will be reused and the new one can be freed.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Wed, 30 Sep 2015 11:00:22 +0000 (04:00 -0700)]
UBUNTU: SAUCE: apparmor: Fix: refcount race between locating in labelset and get
BugLink: http://bugs.launchpad.net/bugs/1448912
The labelset does not hold a refcount on the labels its contains, all
lookups are done under lock. However in the window between finding a
label in the labelset and getting its reference, where the last label
reference can be put causing the label to begin its cleanup.
Ensure the any label in the set has valid reference before returning
its reference. We do this by getting its reference and failing on
that reference if the label has begun cleanup.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Thu, 24 Sep 2015 12:22:24 +0000 (05:22 -0700)]
UBUNTU: SAUCE: apparmor: Fix: label merge handling of marking unconfined and stale
BugLink: http://bugs.launchpad.net/bugs/1448912
Fix a couple of bugs in label merge.
- the unconfined status may not be correctly set in the case of a stale
profile
- if merge(A,B) == A' where A' is revised none stale version of A then
the insertion of A' to replace A can fail.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Sat, 10 Oct 2015 01:54:57 +0000 (18:54 -0700)]
UBUNTU: SAUCE: apparmor: Fix: ensure aa_get_newest will trip debugging if the replacedby is not setup
BugLink: http://bugs.launchpad.net/bugs/1448912
While we are at it, also catch any potential refcounting errors arround
the replacedby label dereference.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Wed, 15 Oct 2014 11:04:16 +0000 (04:04 -0700)]
UBUNTU: SAUCE: apparmor: Fix: insert race between label_update and label_merge
BugLink: http://bugs.launchpad.net/bugs/1448912
it is possible for a label_merge to be racing label_update resulting
in the AA_BUG(__aa_label_remove_and_insert()) to trip. Instead check
if a version of label has already been inserted and gracefully fail
if label_update lost the race.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Sun, 17 May 2015 09:33:13 +0000 (02:33 -0700)]
UBUNTU: SAUCE: apparmor: rework retrieval of the current label in the profile update case
BugLink: http://bugs.launchpad.net/bugs/1430546
The profile update mechanism can return a stale label when an update to
the task's cred fails. Fix this so that the current label is always
returned.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Sun, 17 May 2015 09:32:13 +0000 (02:32 -0700)]
UBUNTU: SAUCE: apparmor: Disallow update of cred when then subjective != the objective cred
BugLink: http://bugs.launchpad.net/bugs/1430546 Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Wed, 15 Oct 2014 11:07:00 +0000 (04:07 -0700)]
UBUNTU: SAUCE: apparmor: Fix: oops do to invalid null ptr deref in label print fns
Passing NULL ns to label print fns is used as shorthand in the a few
places to mean default to the current ns (ie. aa_current_ns()). However
not all the print routines support this.
Instead of fixing the call sites that pass null into the label_print
fns, update all the label_print fns to support this use.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Johansen [Sat, 30 Jan 2016 00:53:15 +0000 (16:53 -0800)]
UBUNTU: SAUCE: apparmor: fix sleep from invalid context
This is a patch to an apparmor feature that is not currently upstream
BugLink: http://bugs.launchpad.net/bugs/1539349
Commit 08518549722f0c992a9e4be71a0777f37147e9d2 made it so kern_path() via
getname_kernel() may do a GFP_KERNEL based allocation which is causing the
"sleep from invalid context" lockdep warning. Rework The apparmor mount
code to move kern_path() calls outside of the get_buffers()/put_buffers()
RCU read_lock block.
Signed-off-by: John Johansen <john.johansen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Colin Ian King [Fri, 26 Feb 2016 18:55:31 +0000 (18:55 +0000)]
x86/mpx: Fix off-by-one comparison with nr_registers
In the unlikely event that regno == nr_registers then we get an array
overrun on regoff because the invalid register check is currently
off-by-one. Fix this with a check that regno is >= nr_registers instead.
Detected with static analysis using CoverityScan.
Fixes: fcc7ffd67991 "x86, mpx: Decode MPX instruction to get bound violation information" Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1456512931-3388-1-git-send-email-colin.king@canonical.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
(cherry picked from commit 9bf148cb0812595bfdf5100bd2c07e9bec9c6ef5) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
The restore_sigregs_ext32() function is used to restore the additional
elements from the user space signal frame. Among the additional elements
are the upper registers halves for 64-bit register support for 31-bit
processes. The copy_from_user that is used to retrieve the high-gprs
array from the user stack uses an incorrect length, 8 bytes instead of
64 bytes. This causes incorrect upper register halves to get loaded.
Cc: stable@vger.kernel.org # 3.8+ Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
(cherry picked from commit 342300cc9cd3428bc6bfe5809bfcc1b9a0f06702) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
I double-checked in a debugger: entries through the int80 gate do
not automatically clear AC.
Stable maintainers: I can provide a backport to 4.3 and earlier if
needed. This needs to be backported all the way to 3.10.
Reported-by: Brian Gerst <brgerst@gmail.com> Signed-off-by: Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@vger.kernel.org> # v3.10 and later Fixes: 63bcff2a307b ("x86, smap: Add STAC and CLAC instructions to control user space access") Link: http://lkml.kernel.org/r/b02b7e71ae54074be01fc171cbd4b72517055c0e.1456345086.git.luto@kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 3d44d51bd339766f0178f0cf2e8d048b4a4872aa) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Paolo Bonzini [Fri, 19 Feb 2016 17:07:21 +0000 (18:07 +0100)]
KVM: x86: fix conversion of addresses to linear in 32-bit protected mode
BugLink: http://bugs.launchpad.net/bugs/1550596
Commit e8dd2d2d641c ("Silence compiler warning in arch/x86/kvm/emulate.c",
2015-09-06) broke boot of the Hurd. The bug is that the "default:"
case actually could modify "la", but after the patch this change is
not reflected in *linear.
The bug is visible whenever a non-zero segment base causes the linear
address to wrap around the 4GB mark.
Fixes: e8dd2d2d641cb2724ee10e76c0ad02e04289c017 Cc: stable@vger.kernel.org Reported-by: Aurelien Jarno <aurelien@aurel32.net> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 0c1d77f4ba5cc9c05a29adca3d6466cdf4969b70) Signed-off-by: Colin King <colin.king@canonical.com> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Frederic Barrat [Wed, 24 Feb 2016 17:27:51 +0000 (18:27 +0100)]
cxl: Fix PSL timebase synchronization detection
BugLink: http://bugs.launchpad.net/bugs/1532914
The PSL timebase synchronization is seemingly failing for
configuration not including VIRT_CPU_ACCOUNTING_NATIVE. The driver
shows the following trace in dmesg:
PSL: Timebase sync: giving up!
The PSL timebase register is actually syncing correctly, but the cxl
driver is not detecting it. Fix is to use the proper timebase-to-time
conversion.
Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com> Cc: <stable@vger.kernel.org> # 4.3+ Acked-by: Michael Neuling <mikey@neuling.org> Reviewed-by: Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by: Ian Munsie <imunsie@au1.ibm.com> Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com> Reviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
(cherry picked from git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git commit 923adb1646d5ba739d2a1e63ee20d60574d9da8e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Hubert Chrzaniuk [Fri, 11 Dec 2015 13:21:22 +0000 (14:21 +0100)]
EDAC, sb_edac: Set fixed DIMM width on Xeon Knights Landing
BugLink: http://bugs.launchpad.net/bugs/1519631
Knights Landing does not come with register that could be used to fetch
DIMM width. However the value is fixed for this architecture so it can
be hardcoded.
Andy Whitcroft [Thu, 25 Feb 2016 22:25:55 +0000 (22:25 +0000)]
UBUNTU: [Config] Provides: virtualbox-guest-modules when appropriate
Now that we have the vbox drivers sucked into the kernel, advertise this
so that the other vbox drivers can depends on us to provide them and
avoid installing the dkms versions when not needed.
BugLink: http://bugs.launchpad.net/bugs/1540390 Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Changes since v1:
- Add a set_best_encoder helper function and update encoder_mask inside
it.
Changes since v2:
- Relax the WARN_ON(!crtc), with explanation.
- Call set_best_encoder when connector is moved between crtc's.
- Add some paranoia to steal_encoder to prevent accidentally setting
best_encoder to NULL.
The connector_mask may be used any time during the non-atomic
.crtc_disable which is called before the full atomic state is
set up and needs to be accurate for that reason.
Changes since v1:
- Update connector_mask in readout_hw_state and add a comment.
drm/atomic: Do not unset crtc when an encoder is stolen
BugLink: http://bugs.launchpad.net/bugs/1540390
While we steal the encoder away from the connector the connector may
be updated to use a different encoder.
Without this change if 2 connectors swap encoders one of them will
end up without a crtc.
Imre Deak [Thu, 28 Jan 2016 14:04:12 +0000 (16:04 +0200)]
drm/i915/bxt: update list of PCIIDs
BugLink: http://bugs.launchpad.net/bugs/1540390
Add PCIIDs for new versions of the SOC, based on BSpec. Also add the
name of the versions as code comment where this is available. The new
versions don't have any changes visible to the kernel driver.
Timo Aaltonen [Mon, 22 Feb 2016 17:02:06 +0000 (19:02 +0200)]
UBUNTU: SAUCE: i915_bpo: Support only SKL, KBL and BXT with the backport driver
BugLink: http://bugs.launchpad.net/bugs/1540390 Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Timo Aaltonen [Mon, 22 Feb 2016 17:01:54 +0000 (19:01 +0200)]
UBUNTU: SAUCE: sound/hda: Load i915_bpo from the hda driver on SKL/KBL/BXT
BugLink: http://bugs.launchpad.net/bugs/1540390 Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Takashi Iwai [Thu, 12 Nov 2015 14:23:41 +0000 (15:23 +0100)]
drm/i915: Add get_eld audio component
BugLink: http://bugs.launchpad.net/bugs/1540390
Implement a new i915_audio_component_ops, get_eld(). It's called by
the audio driver to fetch the current audio status and ELD of the
given HDMI/DP port. It returns the size of expected ELD bytes if it's
valid, zero if no valid ELD is found, or a negative error code. The
current state of audio on/off is stored in the given pointer, too.
Note that the returned size isn't limited to the given max bytes. If
the size is greater than the max bytes, it means that only a part of
ELD has been copied back.
For achieving this implementation, a new field audio_connector is
added to struct intel_digital_port. It points to the connector
assigned to the given digital port. It's set/reset at each audio
enable/disable call in intel_audio.c, and protected with av_mutex.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Takashi Iwai <tiwai@suse.de>
(cherry picked from commit cae666ceb8c3f154351f7df29c522f7a7016bdc0) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Chris Wilson [Wed, 14 Oct 2015 13:17:11 +0000 (14:17 +0100)]
drm/i915: Report context GTT size
BugLink: http://bugs.launchpad.net/bugs/1540390
Since the beginning we have conflated the size of the global GTT with
that of the per-process context sizes. In recent times (gen8+), those
are no longer the same where the global GTT is limited to 2/4GiB but the
per-process GTT may be anything up to 256TiB. Userspace knows nothing of
this discrepancy and outside of one or two hacks, uses the getaperture
ioctl to determine the maximum size it can use. Let's leave that as
reporting the global GTT and use the context reporting method to
describe the per-process value (which naturally fallsback to reporting
the aliasing or global on older platforms, so userspace can always use
this method where available).
Testcase: igt/gem_userptr_blits/minor-normal-sync
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90065 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit fa8848f27895bd19e16aed77868f464be24034e6) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1540390
It can be useful to iterate over connectors without grabbing
connection_mutex. It can also be used to see how many connectors
are on a crtc without iterating over the list.
drm/i915: Set connector_state->connector using the helper.
BugLink: http://bugs.launchpad.net/bugs/1540390
The atomic helper sets connector_state->connector, which the i915
code didn't. This will become a problem when we start using it.
Ville Syrjälä [Mon, 16 Nov 2015 15:02:36 +0000 (17:02 +0200)]
drm: Add "prefix" parameter to drm_rect_debug_print()
BugLink: http://bugs.launchpad.net/bugs/1540390
Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit c70f577a23073c33ae47c9dc2607a24bbee9aa84) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Thierry Reding [Wed, 2 Dec 2015 16:50:03 +0000 (17:50 +0100)]
drm: Implement drm_modeset_lock_all_ctx()
BugLink: http://bugs.launchpad.net/bugs/1540390
This function is like drm_modeset_lock_all(), but it takes the lock
acquisition context as a parameter rather than storing it in the DRM
device's mode_config structure.
Implement drm_modeset_{,un}lock_all() in terms of the new function for
better code reuse, and add a note to the kerneldoc that new code should
use the new functions.
v2: improve kerneldoc
v4: rename drm_modeset_lock_all_crtcs() to drm_modeset_lock_all_ctx()
and take mode_config's .connection_mutex instead of .mutex lock to
avoid lock inversion (Daniel Vetter), use drm_modeset_drop_locks()
which is now the equivalent of drm_modeset_unlock_all_ctx()
v5: do not take the dev->mode_config.connection_mutex in
drm_atomic_legacy_backoff() since drm_modeset_lock_all_ctx()
already keeps it, enhance kerneldoc for drm_modeset_lock_all_ctx()
(Daniel Vetter)
Jani Nikula [Tue, 24 Nov 2015 19:21:55 +0000 (21:21 +0200)]
drm: fix potential dangling else problems in for_each_ macros
BugLink: http://bugs.launchpad.net/bugs/1540390
We have serious dangling else bugs waiting to happen in our for_each_
style macros with ifs. Consider, for example,
if (condition)
drm_for_each_plane_mask(plane, dev, plane_mask);
else
foo();
foo() will be called for each plane *not* in plane_mask, if condition
holds, and not at all if condition doesn't hold.
Fix this by reversing the conditions in the macros, and adding an else
branch for the "for each" block, so that other if/else blocks can't
interfere. Provide a "for_each_if" helper macro to make it easier to get
this right.
Chris Wilson [Fri, 4 Dec 2015 15:58:53 +0000 (15:58 +0000)]
mm: Export nr_swap_pages
BugLink: http://bugs.launchpad.net/bugs/1540390
Some modules, like i915.ko, use swappable objects and may try to swap
them out under memory pressure (via the shrinker). Before doing so, they
want to check using get_nr_swap_pages() to see if any swap space is
available as otherwise they will waste time purging the object from the
device without recovering any memory for the system. This requires the
nr_swap_pages counter to be exported to the modules.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Goel, Akash" <akash.goel@intel.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: linux-mm@kvack.org Link: http://patchwork.freedesktop.org/patch/msgid/1449244734-25733-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Andrew Morton <akpm@linux-foundation.org> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from drm-intel-next commit fb0fec501f08a0a83af7a2b25888ec8cebab53b0) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Deepak S [Wed, 28 Oct 2015 19:19:51 +0000 (12:19 -0700)]
drm/i915/kbl: Add Kabylake PCI ID
BugLink: http://bugs.launchpad.net/bugs/1540390
v2: separate out device info into different GT (Damien)
v3: Add is_kabylake to the KBL gt3 structuer (Damien)
Sort the platforms in older -> newer order (Damien)
v4: Split platform definition since is_skylake=1 on
kabylake structure was Nacked. (Rodrigo)
v5: (Rodrigo) Rebase after commit 3cb27f38f
("drm/i915: remove an extra level of indirection in PCI ID list")
Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Deepak S <deepak.s@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446059991-17033-1-git-send-email-rodrigo.vivi@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit d97044b661d0d56b2a2ae9b2b95ab0b359b417dc) Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Jani Nikula [Wed, 28 Oct 2015 17:33:09 +0000 (19:33 +0200)]
drm/i915: remove an extra level of indirection in PCI ID list
BugLink: http://bugs.launchpad.net/bugs/1540390
Add the PCI IDs directly in the pciidlist array instead of defining an
extra macro. The minor benefit from this is neater diffs when adding to
the end of the list.
Timo Aaltonen [Mon, 22 Feb 2016 16:35:37 +0000 (18:35 +0200)]
UBUNTU: SAUCE: i915_bpo: Rename the backport driver to i915_bpo
BugLink: http://bugs.launchpad.net/bugs/1540390 Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1540390 Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Timo Aaltonen [Mon, 22 Feb 2016 16:34:58 +0000 (18:34 +0200)]
UBUNTU: SAUCE: i915_bpo: Provide a backport driver for SKL, KBL & BXT graphics
BugLink: http://bugs.launchpad.net/bugs/1540390
Provide an updated i915 driver in the ubuntu directory. In subsequent
patches we'll rename this driver to be i915_bpo and strictly limit it's
support to only Skylake, Kabylake and Broxton. Keeping the initial sync
a separate stand alone patch will allow us to easily update this driver
again later.
The driver is based on drm-intel-next-2016-02-14 tag.
Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Marc Zyngier [Fri, 15 Jan 2016 17:41:09 +0000 (17:41 +0000)]
hrtimer: Catch illegal clockids
It is way too easy to take any random clockid and feed it to
the hrtimer subsystem. At best, it gets mapped to a monotonic
base, but it would be better to just catch illegal values as
early as possible.
This patch does exactly that, mapping illegal clockids to an
illegal base index, and panicing when we detect the illegal
condition.
Marc Zyngier [Fri, 15 Jan 2016 17:41:08 +0000 (17:41 +0000)]
hrtimer: Add support for CLOCK_MONOTONIC_RAW
The KVM/ARM timer implementation arms a hrtimer when a vcpu is
blocked (usually because it is waiting for an interrupt)
while its timer is going to kick in the future.
It is essential that this timer doesn't get adjusted, or the
guest will end up being woken-up at the wrong time (NTP running
on the host seems to confuse the hell out of some guests).
In order to allow this, let's add CLOCK_MONOTONIC_RAW support
to hrtimer (it is so far only supported for posix timers). It also
has the (limited) benefit of fixing de0421d53bfb ("mac80211_hwsim:
shuffle code to prepare for dynamic radios"), which already uses
this functionnality without realizing wasn't implemented (just being
lucky...).
Paolo Pisati [Mon, 22 Feb 2016 15:02:00 +0000 (16:02 +0100)]
UBUNTU SAUCE: arm: mm: avoid calling apply_to_page_range on empty range
Calling apply_to_page_range with an empty range results in a BUG_ON
from the core code. This can be triggered by trying to load the st_drv
module with CONFIG_DEBUG_SET_MODULE_RONX enabled:
kernel BUG at mm/memory.c:1874!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 3 PID: 1764 Comm: insmod Not tainted 4.5.0-rc1+ #2
Hardware name: ARM Juno development board (r0) (DT)
task: ffffffc9763b8000 ti: ffffffc975af8000 task.ti: ffffffc975af8000
PC is at apply_to_page_range+0x2cc/0x2d0
LR is at change_memory_common+0x80/0x108
This patch fixes the issue by making change_memory_common (called by the
set_memory_* functions) a NOP when numpages == 0, therefore avoiding the
erroneous call to apply_to_page_range and bringing us into line with x86
and s390.
Cc: <stable@vger.kernel.org> Reviewed-by: Laura Abbott <labbott@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Signed-off-by: Mika Penttilä <mika.penttila@nextfour.com> BugLink: http://bugs.launchpad.net/bugs/1547718 Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> Acked-by: Brad Figg <brad.figg@canonical.com> Acked-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Andy Whitcroft <apw@canonical.com>
Seth Forshee [Thu, 21 Jan 2016 21:37:53 +0000 (15:37 -0600)]
UBUNTU: SAUCE: overlayfs: Propogate nosuid from lower and upper mounts
An overlayfs mount using an upper or lower directory from a
nosuid filesystem bypasses this restriction. Change this so
that if any lower or upper directory is nosuid at mount time the
overlayfs superblock is marked nosuid. This requires some
additions at the vfs level since nosuid currently only applies to
mounts, so a SB_I_NOSUID flag is added along with a helper
function to check a path for nosuid in both the mount and the
superblock.
Seth Forshee [Thu, 21 Jan 2016 17:52:04 +0000 (11:52 -0600)]
UBUNTU: SAUCE: overlayfs: Be more careful about copying up sxid files
When an overlayfs filesystem's lowerdir is on a nosuid filesystem
but the upperdir is not, it's possible to copy up an sxid file or
stick directory into upperdir without changing the mode by
opening the file rw in the overlayfs mount without writing to it.
This makes it possible to bypass the nosuid restriction on the
lowerdir mount.
It's a bad idea in general to let the mounter copy up a sxid file
if the mounter wouldn't have had permission to create the sxid
file in the first place. Therefore change ovl_set_xattr to
exclude these bits when initially setting the mode, then set the
full mode after setting the user for the inode. This allows copy
up for non-sxid files to work as before but causes copy up to
fail for the cases where the user could not have created the sxid
inode in upperdir.
Seth Forshee [Tue, 19 Jan 2016 19:12:02 +0000 (13:12 -0600)]
UBUNTU: SAUCE: overlayfs: Skip permission checking for trusted.overlayfs.* xattrs
The original mounter had CAP_SYS_ADMIN in the user namespace
where the mount happened, and the vfs has validated that the user
has permission to do the requested operation. This is sufficient
for allowing the kernel to write these specific xattrs, so bypass
the permission checks for these xattrs.
Seth Forshee [Tue, 19 Jan 2016 16:25:24 +0000 (10:25 -0600)]
UBUNTU: SAUCE: overlayfs: Use mounter's credentials instead of selectively raising caps
When overlayfs needs to perform internal operations which require
privileges the current user may not have, it does so by
selectively raising the required capabilities in the current set
of credentials. If the current process is in a user namespace
this doesn't always work, as operations such as setting
privileged xattrs often requires privileges in init_user_ns.
These operations really ought to be permitted, based on a couple
of facts:
1. The vfs has already verified that the current process is
allowed to perform the requested operation on the overlayfs
super block, and overlayfs has verified that the operation is
permitted in upperdir.
2. The original mounter of the overlayfs super block was
privileged enough to perform the internal overlayfs
operations required to satisfy the user's request in
upperdir.
On the other hand, if the filesystem is mounted from a user
namespace and then accessed in init_user_ns the credentials taken
will exceed those of the mounter. This could result in performing
operations that the user could not do otherwise, such as creating
files which are sxid for another user or group. Both of these
issues can be prevented by using the mounter's credentials when
performing privileged overlayfs-internal operations.
Add a new internal interface, ovl_prepare_creds(), which returns
a new set of credentials for performing privileged internal
operations that is identical to the mounter's creds. Use this
internal interface instead of using prepare_creds() and
selectively raising the needed capabilities.
Seth Forshee [Tue, 19 Jan 2016 16:20:43 +0000 (10:20 -0600)]
UBUNTU: SAUCE: cred: Add clone_cred() interface
This interface returns a new set of credentials which is an exact
copy of another set. Also update prepare_kernel_cred() to use
this function instead of duplicating code.
Mitch Williams [Thu, 18 Feb 2016 00:12:23 +0000 (16:12 -0800)]
i40e: let go of the past
BugLink: http://bugs.launchpad.net/bugs/1547674
If we reset a VF, its VSI goes away, and it gets a new one. So don't
hang on to the now-stale local VSI pointer. It just leads to suffering
and kernel panics.
Change-ID: Ia8823b4e85893e95e963acee284968022b29177a Signed-off-by: Mitch Williams <mitch.a.williams@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 35f3472a750b3549f7f914ed96f41f0c2ca284f3) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
BugLink: http://bugs.launchpad.net/bugs/1547674
We need to suspend scheduling or any pending service task during driver
unload process, so that new task will not be scheduled. This patch sets
the suspend flag bit during reload which avoids service task execution.
Change-ID: I017c57b5d6656564556e3c5387da671369a572ac Signed-off-by: Pandi Kumar Maharajan <pandi.maharajan@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit a4618ec88de95a86f290d01c74c506552f1a5d95) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Shannon Nelson [Thu, 18 Feb 2016 00:12:21 +0000 (16:12 -0800)]
i40e: Use the new rx ctl register helpers. Don't use AQ calls from clear_hw.
BugLink: http://bugs.launchpad.net/bugs/1547674
Use the new AdminQ functions for safely accessing the Rx control
registers that may be affected by heavy small packet traffic.
We can't use AdminQ calls in i40e_clear_hw() because the HW is being
initialized and the AdminQ is not alive. We recently added an AQ
related replacement for reading PFLAN_QALLOC, and this patch puts
back the original register read.
Change-ID: Ib027168c954a5733299aa3a4ce5f8218c6bb5636 Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 272cdaf2472ab7713deebe060bb90319b0382a94) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Shannon Nelson [Thu, 18 Feb 2016 00:12:20 +0000 (16:12 -0800)]
i40e: implement and use Rx CTL helper functions
BugLink: http://bugs.launchpad.net/bugs/1547674
Use the new AdminQ functions for safely accessing the Rx control
registers that may be affected by heavy small packet traffic.
Change-ID: Ibb00983e8dcba71f4b760222a609a5fcaa726f18 Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit f658137cbb1fddbe40ec7f1a2cebaf9dc9484ea7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Shannon Nelson [Thu, 18 Feb 2016 00:12:19 +0000 (16:12 -0800)]
i40e: add adminq commands for Rx CTL registers
BugLink: http://bugs.launchpad.net/bugs/1547674
Add the new opcodes and struct used for asking the firmware to update Rx
control registers that need extra care when being accessed while under
heavy traffic - e.g. sustained 64byte packets at line rate on all ports.
The firmware will take extra steps to be sure the register accesses
are successful.
Change-ID: I56c8144000da66ad99f68948d8a184b2ec2aeb3e Signed-off-by: Shannon Nelson <shannon.nelson@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 3336514381f9ef99c50e5337ae1bf36f8138679d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
John Underwood [Thu, 18 Feb 2016 17:19:24 +0000 (09:19 -0800)]
i40e: add check for null VSI
BugLink: http://bugs.launchpad.net/bugs/1547674
Return from i40e_vsi_reinit_setup() if vsi param is NULL.
This makes this code consistent with all the other code that
checks for NULL before using one of the VSI pointers accessed
with an indexed variable. (Indexed VSI pointers are
intentionally set to NULL in i40e_vsi_clear() and
i40e_remove().
Change-ID: I3bc8b909c70fd2439334eeae994d151f61480985 Signed-off-by: John Underwood <johnx.underwood@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit f534039dd8ab39cb3259e5860d2be3b0e70aacbf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
i40e: Expose some registers to program parser, FD and RSS logic
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch adds 7 new register definitions for programming the
parser, flow director and RSS blocks in the HW.
Change-ID: I31e76673125275f3c69a14c646361919d04dc987 Signed-off-by: Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit fe726082728da9f653d4e747baf0816d826fc626) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Carolyn Wyborny [Thu, 18 Feb 2016 00:12:16 +0000 (16:12 -0800)]
i40e: Fix for unexpected messaging
BugLink: http://bugs.launchpad.net/bugs/1547674
This fixes an issue where a previously removed message
has returned. Changing the message type to dev_dbg
leaves the info, if desired, but takes it out of normal
everyday usage. Also changed call to only provide port
data when its valid and not when its not (delete case).
Change-ID: Ief6f33b915f6364c24fa8e5789c2fc3168b5e2ed Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 730a8f8777e55912f445c2c29234d51cceb1dfc2) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Neerav Parikh [Thu, 18 Feb 2016 00:12:15 +0000 (16:12 -0800)]
i40e: Do not wait for Rx queue disable in DCB reconfig
BugLink: http://bugs.launchpad.net/bugs/1547674
Just like Tx queues don't wait for Rx queues to be disabled before
DCB has been reconfigured.
Check the queues are disabled only after the DCB configuration has
been applied to the VSI(s) managed by the PF driver.
In case of any timeout issue a PF reset to recover.
Change-ID: Ic51e94c25baf9a5480cee983f35d15575a88642c Signed-off-by: Neerav Parikh <neerav.parikh@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 3fe06f415b31ad06d2c2923216292057e899eb0d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Kevin Scott [Thu, 18 Feb 2016 00:12:13 +0000 (16:12 -0800)]
i40e: Increase timeout when checking GLGEN_RSTAT_DEVSTATE bit
BugLink: http://bugs.launchpad.net/bugs/1547674
When linking with particular PHY types (ex: copper PHY), the amount of
time it takes for the GLGEN_RSTAT_DEVSTATE to be set increases greatly,
which can lead to a timeout and failure to load the driver.
Change-ID: If02be0dfcd7c57fdde2d5c81cd63651260cd2029 Signed-off-by: Kevin Scott <kevin.c.scott@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 4d7cec078de864b7ba5459aa688278c4e6f3ad42) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Carolyn Wyborny [Thu, 18 Feb 2016 00:12:12 +0000 (16:12 -0800)]
i40e: Fix led blink capability for 10GBaseT PHY
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch fixes a problem where the ethtool identify adapter
functionality did not work for some copper PHY's. Without this
patch, the blink led functionality fails on some parts. This
patch adds PHY write code to blink led's on parts where this
functionality is contained in the PHY rather than the MAC.
Change-ID: Iee7b3453f61d5ffd0b3d03f720ee4f17f919fcc2 Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 31b606d0c40a1435c54bff18e4d3d3c33af1c3cf) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Carolyn Wyborny [Thu, 18 Feb 2016 00:12:11 +0000 (16:12 -0800)]
i40e: Add functions to blink led on 10GBaseT PHY
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch adds functions to blink led on devices using
10GBaseT PHY since MAC registers used in other designs
do not work in this device configuration.
Change-ID: Id4b88c93c649fd2b88073a00b42867a77c761ca3 Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit fd077cd3399b164548f538625f07f3e9f1d7ef00) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Wed, 17 Feb 2016 19:02:56 +0000 (11:02 -0800)]
i40e/i40evf: Move Tx checksum closer to TSO
BugLink: http://bugs.launchpad.net/bugs/1547674
On all of the other Intel drivers we place checksum close to TSO as they
have a significant amount in common and it can help to reduce the decision
tree for how to handle the frame as the first check in TSO is to see if
checksumming is offloaded, and if it is not we can skip _BOTH_ TSO and Tx
checksum offload based on a single check.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 3bc67973e81d5104908a4ba7c2aab98a4f7bd64e) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Wed, 17 Feb 2016 19:02:50 +0000 (11:02 -0800)]
i40e/i40evf: Rewrite logic for 8 descriptor per packet check
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch is meant to rewrite the logic for how we determine if we can
transmit the frame or if it needs to be linearized.
The previous code for this function was using a mix of division and modulus
division as a part of computing if we need to take the slow path. Instead
I have replaced this by simply working with a sliding window which will
tell us if the frame would be capable of causing a single packet to span
several descriptors.
The logic for the scan is fairly simple. If any given group of 6 fragments
is less than gso_size - 1 then it is possible for us to have one byte
coming out of the first fragment, 6 fragments, and one or more bytes coming
out of the last fragment. This gives us a total of 8 fragments
which exceeds what we can allow so we send such frames to be linearized.
Arguably the use of modulus might be more exact as the approach I propose
may generate some false positives. However the likelihood of us taking much
of a hit for those false positives is fairly low, and I would rather not
add more overhead in the case where we are receiving a frame composed of 4K
pages.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 2d37490b82afe1d1b745811e6ce0a4d16bc5e996) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Wed, 17 Feb 2016 19:02:43 +0000 (11:02 -0800)]
i40e/i40evf: Break up xmit_descriptor_count from maybe_stop_tx
BugLink: http://bugs.launchpad.net/bugs/1547674
In an upcoming patch I would like to have access to the descriptor count
used for the data portion of the frame. For this reason I am splitting up
the descriptor count function from the function that stops the ring.
Also in order to try and reduce unnecessary duplication of code I am moving
the slow-path portions of the code out of being inline calls so that we can
just jump to them and process them instead of having to build them into
each function that calls them.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 4ec441df25a686518fb369086e2b34a1cedaa6c9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Tue, 26 Jan 2016 03:32:54 +0000 (19:32 -0800)]
i40e: Add support for ATR w/ IPv6 extension headers
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch updates the code for determining the L4 protocol and L3 header
length so that when IPv6 extension headers are being used we can determine
the offset and type of the L4 protocol.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit ffcc55c0c2a85835a4ac080bc1053c3a277b88e2) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:57 +0000 (21:17 -0800)]
i40evf: Update feature flags to reflect newly enabled features
BugLink: http://bugs.launchpad.net/bugs/1547674
Recent changes should have enabled support for IPv6 based tunnels and
support for TSO with outer UDP checksums. As such we can update the
feature flags to reflect that.
In addition we can clean-up the flags that aren't needed such as SCTP and
RXCSUM since having the bits there doesn't add any value.
I also found one spot where we were setting the same flag twice. It looks
like it was probably a git merge error that resulted in the line being
duplicated. As such I have dropped it in this patch.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Acked-by: Anjali Singhai Jain <anjali.singhai@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit f608e6a60fc85e4f261daab5e7aac6225e2120d6) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:50 +0000 (21:17 -0800)]
i40e: Update feature flags to reflect newly enabled features
BugLink: http://bugs.launchpad.net/bugs/1547674
Recent changes should have enabled support for IPv6 based tunnels and
support for TSO with outer UDP checksums. As such we can update the
feature flags to reflect that.
In addition we can clean-up the flags that aren't needed such as SCTP and
RXCSUM since having the bits there doesn't add any value.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit bc5d252b363cca63b7ddc1e20dd8b8b242631006) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:43 +0000 (21:17 -0800)]
i40e: Do not drop support for IPv6 VXLAN or GENEVE tunnels
BugLink: http://bugs.launchpad.net/bugs/1547674
All of the documentation in the datasheets for the XL710 do not call out
any reason to exclude support for IPv6 based tunnels. As such I am
dropping the code that was excluding these tunnel types from having their
port numbers recognized. This way we can take advantage of things such as
checksum offload for inner headers over IPv6 based VXLAN or GENEVE
tunnels.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 84d5946d49cf9552d0f1740ad62d0f126cb3b6a9) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:36 +0000 (21:17 -0800)]
i40e: Fix ATR in relation to tunnels
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch contains a number of fixes to make certain that we are using
the correct protocols when parsing both the inner and outer headers of a
frame that is mixed between IPv4 and IPv6 for inner and outer.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Acked-by: Kiran Patil <kiran.patil@intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 6b037cd465ff6e5f6b96524658f47d59d1acc554) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:29 +0000 (21:17 -0800)]
i40e/i40evf: Enable support for SKB_GSO_UDP_TUNNEL_CSUM
BugLink: http://bugs.launchpad.net/bugs/1547674
The XL722 has support for providing the outer UDP tunnel checksum on
transmits. Make use of this feature to support segmenting UDP tunnels with
outer checksums enabled.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 5453205cd0975b845f6f8837f0c2b7c8cb80fcf8) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:22 +0000 (21:17 -0800)]
i40e/i40evf: Clean-up Rx packet checksum handling
BugLink: http://bugs.launchpad.net/bugs/1547674
This is mostly a minor clean-up for the Rx checksum path in order to avoid
some of the unnecessary conditional checks that were being applied.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit fad57330b6d0710fdf39dc1c2b28ccebb97ae8a1) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:10 +0000 (21:17 -0800)]
i40e/i40evf: Add exception handling for Tx checksum
BugLink: http://bugs.launchpad.net/bugs/1547674
Add exception handling to the Tx checksum path so that we can handle cases
of TSO where the frame is bad, or Tx checksum where we didn't recognize a
protocol
Drop I40E_TX_FLAGS_CSUM as it is unused, move the CHECKSUM_PARTIAL check
into the function itself so that we can decrease indent.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 529f1f652e3c3c6db6ab5a6e3a35469ddfd9575d) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Alexander Duyck [Mon, 25 Jan 2016 05:17:01 +0000 (21:17 -0800)]
i40e/i40evf: Do not write to descriptor unless we complete
BugLink: http://bugs.launchpad.net/bugs/1547674
This patch defers writing to the Tx descriptor bits until we know we have
successfully completed a given operation. So for example we defer updating
the tunnelling portion of the context descriptor until we have fully
identified the type.
The advantage to this approach is that we can assemble values as we go
instead of having to try and kludge everything together all at once. As a
result we can significantly clean up the tunneling configuration for
instance as we can just do a pointer walk and do the math for the distance
between each set of points.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
(cherry picked from net-next commit 475b4205aa52c16feef08d55c8fd76e815b6bee7) Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
projects / mirror_ubuntu-zesty-kernel.git / log