--- /dev/null
+From foo@baz Thu Jun 15 12:25:54 CEST 2017
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Tue, 23 May 2017 21:54:08 -0400
+Subject: drm/nouveau: prevent userspace from deleting client object
+
+From: Ben Skeggs <bskeggs@redhat.com>
+
+
+[ Upstream commit c966b6279f610a24ac1d42dcbe30e10fa61220b2 ]
+
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_usif.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_usif.c
++++ b/drivers/gpu/drm/nouveau/nouveau_usif.c
+@@ -313,7 +313,8 @@ usif_ioctl(struct drm_file *filp, void _
+ if (nvif_unpack(argv->v0, 0, 0, true)) {
+ /* block access to objects not created via this interface */
+ owner = argv->v0.owner;
+- if (argv->v0.object == 0ULL)
++ if (argv->v0.object == 0ULL &&
++ argv->v0.type != NVIF_IOCTL_V0_DEL)
+ argv->v0.owner = NVDRM_OBJECT_ANY; /* except client */
+ else
+ argv->v0.owner = NVDRM_OBJECT_USIF;
--- /dev/null
+From foo@baz Thu Jun 15 12:25:54 CEST 2017
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+Date: Tue, 23 May 2017 21:53:59 -0400
+Subject: ethtool: do not vzalloc(0) on registers dump
+
+From: Stanislaw Gruszka <sgruszka@redhat.com>
+
+
+[ Upstream commit 3808d34838184fd29088d6b3a364ba2f1c018fb6 ]
+
+If ->get_regs_len() callback return 0, we allocate 0 bytes of memory,
+what print ugly warning in dmesg, which can be found further below.
+
+This happen on mac80211 devices where ieee80211_get_regs_len() just
+return 0 and driver only fills ethtool_regs structure and actually
+do not provide any dump. However I assume this can happen on other
+drivers i.e. when for some devices driver provide regs dump and for
+others do not. Hence preventing to to print warning in ethtool code
+seems to be reasonable.
+
+ethtool: vmalloc: allocation failure: 0 bytes, mode:0x24080c2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_ZERO)
+<snip>
+Call Trace:
+[<ffffffff813bde47>] dump_stack+0x63/0x8c
+[<ffffffff811b0a1f>] warn_alloc+0x13f/0x170
+[<ffffffff811f0476>] __vmalloc_node_range+0x1e6/0x2c0
+[<ffffffff811f0874>] vzalloc+0x54/0x60
+[<ffffffff8169986c>] dev_ethtool+0xb4c/0x1b30
+[<ffffffff816adbb1>] dev_ioctl+0x181/0x520
+[<ffffffff816714d2>] sock_do_ioctl+0x42/0x50
+<snip>
+Mem-Info:
+active_anon:435809 inactive_anon:173951 isolated_anon:0
+ active_file:835822 inactive_file:196932 isolated_file:0
+ unevictable:0 dirty:8 writeback:0 unstable:0
+ slab_reclaimable:157732 slab_unreclaimable:10022
+ mapped:83042 shmem:306356 pagetables:9507 bounce:0
+ free:130041 free_pcp:1080 free_cma:0
+Node 0 active_anon:1743236kB inactive_anon:695804kB active_file:3343288kB inactive_file:787728kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:332168kB dirty:32kB writeback:0kB shmem:0kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 1225424kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
+Node 0 DMA free:15900kB min:136kB low:168kB high:200kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15984kB managed:15900kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
+lowmem_reserve[]: 0 3187 7643 7643
+Node 0 DMA32 free:419732kB min:28124kB low:35152kB high:42180kB active_anon:541180kB inactive_anon:248988kB active_file:1466388kB inactive_file:389632kB unevictable:0kB writepending:0kB present:3370280kB managed:3290932kB mlocked:0kB slab_reclaimable:217184kB slab_unreclaimable:4180kB kernel_stack:160kB pagetables:984kB bounce:0kB free_pcp:2236kB local_pcp:660kB free_cma:0kB
+lowmem_reserve[]: 0 0 4456 4456
+
+Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/ethtool.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/net/core/ethtool.c
++++ b/net/core/ethtool.c
+@@ -886,9 +886,12 @@ static int ethtool_get_regs(struct net_d
+ if (regs.len > reglen)
+ regs.len = reglen;
+
+- regbuf = vzalloc(reglen);
+- if (reglen && !regbuf)
+- return -ENOMEM;
++ regbuf = NULL;
++ if (reglen) {
++ regbuf = vzalloc(reglen);
++ if (!regbuf)
++ return -ENOMEM;
++ }
+
+ ops->get_regs(dev, ®s, regbuf);
+
--- /dev/null
+From foo@baz Thu Jun 15 12:25:54 CEST 2017
+From: David Howells <dhowells@redhat.com>
+Date: Tue, 23 May 2017 21:54:06 -0400
+Subject: FS-Cache: Initialise stores_lock in netfs cookie
+
+From: David Howells <dhowells@redhat.com>
+
+
+[ Upstream commit 62deb8187d116581c88c69a2dd9b5c16588545d4 ]
+
+Initialise the stores_lock in fscache netfs cookies. Technically, it
+shouldn't be necessary, since the netfs cookie is an index and stores no
+data, but initialising it anyway adds insignificant overhead.
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+Reviewed-by: Jeff Layton <jlayton@redhat.com>
+Acked-by: Steve Dickson <steved@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fscache/netfs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/fscache/netfs.c
++++ b/fs/fscache/netfs.c
+@@ -48,6 +48,7 @@ int __fscache_register_netfs(struct fsca
+ cookie->flags = 1 << FSCACHE_COOKIE_ENABLED;
+
+ spin_lock_init(&cookie->lock);
++ spin_lock_init(&cookie->stores_lock);
+ INIT_HLIST_HEAD(&cookie->backing_objects);
+
+ /* check the netfs type is not already present */
--- /dev/null
+From foo@baz Thu Jun 15 12:25:54 CEST 2017
+From: David Howells <dhowells@redhat.com>
+Date: Tue, 23 May 2017 21:54:05 -0400
+Subject: fscache: Clear outstanding writes when disabling a cookie
+
+From: David Howells <dhowells@redhat.com>
+
+
+[ Upstream commit 6bdded59c8933940ac7e5b416448276ac89d1144 ]
+
+fscache_disable_cookie() needs to clear the outstanding writes on the
+cookie it's disabling because they cannot be completed after.
+
+Without this, fscache_nfs_open_file() gets stuck because it disables the
+cookie when the file is opened for writing but can't uncache the pages till
+afterwards - otherwise there's a race between the open routine and anyone
+who already has it open R/O and is still reading from it.
+
+Looking in /proc/pid/stack of the offending process shows:
+
+[<ffffffffa0142883>] __fscache_wait_on_page_write+0x82/0x9b [fscache]
+[<ffffffffa014336e>] __fscache_uncache_all_inode_pages+0x91/0xe1 [fscache]
+[<ffffffffa01740fa>] nfs_fscache_open_file+0x59/0x9e [nfs]
+[<ffffffffa01ccf41>] nfs4_file_open+0x17f/0x1b8 [nfsv4]
+[<ffffffff8117350e>] do_dentry_open+0x16d/0x2b7
+[<ffffffff811743ac>] vfs_open+0x5c/0x65
+[<ffffffff81184185>] path_openat+0x785/0x8fb
+[<ffffffff81184343>] do_filp_open+0x48/0x9e
+[<ffffffff81174710>] do_sys_open+0x13b/0x1cb
+[<ffffffff811747b9>] SyS_open+0x19/0x1b
+[<ffffffff81001c44>] do_syscall_64+0x80/0x17a
+[<ffffffff8165c2da>] return_from_SYSCALL_64+0x0/0x7a
+[<ffffffffffffffff>] 0xffffffffffffffff
+
+Reported-by: Jianhong Yin <jiyin@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Acked-by: Jeff Layton <jlayton@redhat.com>
+Acked-by: Steve Dickson <steved@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fscache/cookie.c | 5 +++++
+ fs/fscache/object.c | 6 ++++++
+ 2 files changed, 11 insertions(+)
+
+--- a/fs/fscache/cookie.c
++++ b/fs/fscache/cookie.c
+@@ -542,6 +542,7 @@ void __fscache_disable_cookie(struct fsc
+ hlist_for_each_entry(object, &cookie->backing_objects, cookie_link) {
+ if (invalidate)
+ set_bit(FSCACHE_OBJECT_RETIRED, &object->flags);
++ clear_bit(FSCACHE_OBJECT_PENDING_WRITE, &object->flags);
+ fscache_raise_event(object, FSCACHE_OBJECT_EV_KILL);
+ }
+ } else {
+@@ -560,6 +561,10 @@ void __fscache_disable_cookie(struct fsc
+ wait_on_atomic_t(&cookie->n_active, fscache_wait_atomic_t,
+ TASK_UNINTERRUPTIBLE);
+
++ /* Make sure any pending writes are cancelled. */
++ if (cookie->def->type != FSCACHE_COOKIE_TYPE_INDEX)
++ fscache_invalidate_writes(cookie);
++
+ /* Reset the cookie state if it wasn't relinquished */
+ if (!test_bit(FSCACHE_COOKIE_RELINQUISHED, &cookie->flags)) {
+ atomic_inc(&cookie->n_active);
+--- a/fs/fscache/object.c
++++ b/fs/fscache/object.c
+@@ -650,6 +650,12 @@ static const struct fscache_state *fscac
+ fscache_mark_object_dead(object);
+ object->oob_event_mask = 0;
+
++ if (test_bit(FSCACHE_OBJECT_RETIRED, &object->flags)) {
++ /* Reject any new read/write ops and abort any that are pending. */
++ clear_bit(FSCACHE_OBJECT_PENDING_WRITE, &object->flags);
++ fscache_cancel_all_ops(object);
++ }
++
+ if (list_empty(&object->dependents) &&
+ object->n_ops == 0 &&
+ object->n_children == 0)
--- /dev/null
+From foo@baz Thu Jun 15 12:25:54 CEST 2017
+From: David Howells <dhowells@redhat.com>
+Date: Tue, 23 May 2017 21:54:04 -0400
+Subject: fscache: Fix dead object requeue
+
+From: David Howells <dhowells@redhat.com>
+
+
+[ Upstream commit e26bfebdfc0d212d366de9990a096665d5c0209a ]
+
+Under some circumstances, an fscache object can become queued such that it
+fscache_object_work_func() can be called once the object is in the
+OBJECT_DEAD state. This results in the kernel oopsing when it tries to
+invoke the handler for the state (which is hard coded to 0x2).
+
+The way this comes about is something like the following:
+
+ (1) The object dispatcher is processing a work state for an object. This
+ is done in workqueue context.
+
+ (2) An out-of-band event comes in that isn't masked, causing the object to
+ be queued, say EV_KILL.
+
+ (3) The object dispatcher finishes processing the current work state on
+ that object and then sees there's another event to process, so,
+ without returning to the workqueue core, it processes that event too.
+ It then follows the chain of events that initiates until we reach
+ OBJECT_DEAD without going through a wait state (such as
+ WAIT_FOR_CLEARANCE).
+
+ At this point, object->events may be 0, object->event_mask will be 0
+ and oob_event_mask will be 0.
+
+ (4) The object dispatcher returns to the workqueue processor, and in due
+ course, this sees that the object's work item is still queued and
+ invokes it again.
+
+ (5) The current state is a work state (OBJECT_DEAD), so the dispatcher
+ jumps to it - resulting in an OOPS.
+
+When I'm seeing this, the work state in (1) appears to have been either
+LOOK_UP_OBJECT or CREATE_OBJECT (object->oob_table is
+fscache_osm_lookup_oob).
+
+The window for (2) is very small:
+
+ (A) object->event_mask is cleared whilst the event dispatch process is
+ underway - though there's no memory barrier to force this to the top
+ of the function.
+
+ The window, therefore is from the time the object was selected by the
+ workqueue processor and made requeueable to the time the mask was
+ cleared.
+
+ (B) fscache_raise_event() will only queue the object if it manages to set
+ the event bit and the corresponding event_mask bit was set.
+
+ The enqueuement is then deferred slightly whilst we get a ref on the
+ object and get the per-CPU variable for workqueue congestion. This
+ slight deferral slightly increases the probability by allowing extra
+ time for the workqueue to make the item requeueable.
+
+Handle this by giving the dead state a processor function and checking the
+for the dead state address rather than seeing if the processor function is
+address 0x2. The dead state processor function can then set a flag to
+indicate that it's occurred and give a warning if it occurs more than once
+per object.
+
+If this race occurs, an oops similar to the following is seen (note the RIP
+value):
+
+BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
+IP: [<0000000000000002>] 0x1
+PGD 0
+Oops: 0010 [#1] SMP
+Modules linked in: ...
+CPU: 17 PID: 16077 Comm: kworker/u48:9 Not tainted 3.10.0-327.18.2.el7.x86_64 #1
+Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 12/27/2015
+Workqueue: fscache_object fscache_object_work_func [fscache]
+task: ffff880302b63980 ti: ffff880717544000 task.ti: ffff880717544000
+RIP: 0010:[<0000000000000002>] [<0000000000000002>] 0x1
+RSP: 0018:ffff880717547df8 EFLAGS: 00010202
+RAX: ffffffffa0368640 RBX: ffff880edf7a4480 RCX: dead000000200200
+RDX: 0000000000000002 RSI: 00000000ffffffff RDI: ffff880edf7a4480
+RBP: ffff880717547e18 R08: 0000000000000000 R09: dfc40a25cb3a4510
+R10: dfc40a25cb3a4510 R11: 0000000000000400 R12: 0000000000000000
+R13: ffff880edf7a4510 R14: ffff8817f6153400 R15: 0000000000000600
+FS: 0000000000000000(0000) GS:ffff88181f420000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 0000000000000002 CR3: 000000000194a000 CR4: 00000000001407e0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
+Stack:
+ ffffffffa0363695 ffff880edf7a4510 ffff88093f16f900 ffff8817faa4ec00
+ ffff880717547e60 ffffffff8109d5db 00000000faa4ec18 0000000000000000
+ ffff8817faa4ec18 ffff88093f16f930 ffff880302b63980 ffff88093f16f900
+Call Trace:
+ [<ffffffffa0363695>] ? fscache_object_work_func+0xa5/0x200 [fscache]
+ [<ffffffff8109d5db>] process_one_work+0x17b/0x470
+ [<ffffffff8109e4ac>] worker_thread+0x21c/0x400
+ [<ffffffff8109e290>] ? rescuer_thread+0x400/0x400
+ [<ffffffff810a5acf>] kthread+0xcf/0xe0
+ [<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
+ [<ffffffff816460d8>] ret_from_fork+0x58/0x90
+ [<ffffffff810a5a00>] ? kthread_create_on_node+0x140/0x140
+
+Signed-off-by: David Howells <dhowells@redhat.com>
+Acked-by: Jeremy McNicoll <jeremymc@redhat.com>
+Tested-by: Frank Sorenson <sorenson@redhat.com>
+Tested-by: Benjamin Coddington <bcodding@redhat.com>
+Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fscache/object.c | 26 ++++++++++++++++++++++++--
+ include/linux/fscache-cache.h | 1 +
+ 2 files changed, 25 insertions(+), 2 deletions(-)
+
+--- a/fs/fscache/object.c
++++ b/fs/fscache/object.c
+@@ -30,6 +30,7 @@ static const struct fscache_state *fscac
+ static const struct fscache_state *fscache_object_available(struct fscache_object *, int);
+ static const struct fscache_state *fscache_parent_ready(struct fscache_object *, int);
+ static const struct fscache_state *fscache_update_object(struct fscache_object *, int);
++static const struct fscache_state *fscache_object_dead(struct fscache_object *, int);
+
+ #define __STATE_NAME(n) fscache_osm_##n
+ #define STATE(n) (&__STATE_NAME(n))
+@@ -91,7 +92,7 @@ static WORK_STATE(LOOKUP_FAILURE, "LCFL"
+ static WORK_STATE(KILL_OBJECT, "KILL", fscache_kill_object);
+ static WORK_STATE(KILL_DEPENDENTS, "KDEP", fscache_kill_dependents);
+ static WORK_STATE(DROP_OBJECT, "DROP", fscache_drop_object);
+-static WORK_STATE(OBJECT_DEAD, "DEAD", (void*)2UL);
++static WORK_STATE(OBJECT_DEAD, "DEAD", fscache_object_dead);
+
+ static WAIT_STATE(WAIT_FOR_INIT, "?INI",
+ TRANSIT_TO(INIT_OBJECT, 1 << FSCACHE_OBJECT_EV_NEW_CHILD));
+@@ -229,6 +230,10 @@ execute_work_state:
+ event = -1;
+ if (new_state == NO_TRANSIT) {
+ _debug("{OBJ%x} %s notrans", object->debug_id, state->name);
++ if (unlikely(state == STATE(OBJECT_DEAD))) {
++ _leave(" [dead]");
++ return;
++ }
+ fscache_enqueue_object(object);
+ event_mask = object->oob_event_mask;
+ goto unmask_events;
+@@ -239,7 +244,7 @@ execute_work_state:
+ object->state = state = new_state;
+
+ if (state->work) {
+- if (unlikely(state->work == ((void *)2UL))) {
++ if (unlikely(state == STATE(OBJECT_DEAD))) {
+ _leave(" [dead]");
+ return;
+ }
+@@ -1077,3 +1082,20 @@ void fscache_object_mark_killed(struct f
+ }
+ }
+ EXPORT_SYMBOL(fscache_object_mark_killed);
++
++/*
++ * The object is dead. We can get here if an object gets queued by an event
++ * that would lead to its death (such as EV_KILL) when the dispatcher is
++ * already running (and so can be requeued) but hasn't yet cleared the event
++ * mask.
++ */
++static const struct fscache_state *fscache_object_dead(struct fscache_object *object,
++ int event)
++{
++ if (!test_and_set_bit(FSCACHE_OBJECT_RUN_AFTER_DEAD,
++ &object->flags))
++ return NO_TRANSIT;
++
++ WARN(true, "FS-Cache object redispatched after death");
++ return NO_TRANSIT;
++}
+--- a/include/linux/fscache-cache.h
++++ b/include/linux/fscache-cache.h
+@@ -360,6 +360,7 @@ struct fscache_object {
+ #define FSCACHE_OBJECT_IS_AVAILABLE 5 /* T if object has become active */
+ #define FSCACHE_OBJECT_RETIRED 6 /* T if object was retired on relinquishment */
+ #define FSCACHE_OBJECT_KILLED_BY_CACHE 7 /* T if object was killed by the cache */
++#define FSCACHE_OBJECT_RUN_AFTER_DEAD 8 /* T if object has been dispatched after death */
+
+ struct list_head cache_link; /* link in cache->object_list */
+ struct hlist_node cookie_link; /* link in cookie->backing_objects */
--- /dev/null
+From foo@baz Thu Jun 15 12:25:54 CEST 2017
+From: Dimitris Michailidis <dmichail@google.com>
+Date: Tue, 23 May 2017 21:54:07 -0400
+Subject: ipv6: fix flow labels when the traffic class is non-0
+
+From: Dimitris Michailidis <dmichail@google.com>
+
+
+[ Upstream commit 90427ef5d2a4b9a24079889bf16afdcdaebc4240 ]
+
+ip6_make_flowlabel() determines the flow label for IPv6 packets. It's
+supposed to be passed a flow label, which it returns as is if non-0 and
+in some other cases, otherwise it calculates a new value.
+
+The problem is callers often pass a flowi6.flowlabel, which may also
+contain traffic class bits. If the traffic class is non-0
+ip6_make_flowlabel() mistakes the non-0 it gets as a flow label and
+returns the whole thing. Thus it can return a 'flow label' longer than
+20b and the low 20b of that is typically 0 resulting in packets with 0
+label. Moreover, different packets of a flow may be labeled differently.
+For a TCP flow with ECN non-payload and payload packets get different
+labels as exemplified by this pair of consecutive packets:
+
+(pure ACK)
+Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
+ 0110 .... = Version: 6
+ .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
+ .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
+ .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
+ .... .... .... 0001 1100 1110 0100 1001 = Flow Label: 0x1ce49
+ Payload Length: 32
+ Next Header: TCP (6)
+
+(payload)
+Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
+ 0110 .... = Version: 6
+ .... 0000 0010 .... .... .... .... .... = Traffic Class: 0x02 (DSCP: CS0, ECN: ECT(0))
+ .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
+ .... .... ..10 .... .... .... .... .... = Explicit Congestion Notification: ECN-Capable Transport codepoint '10' (2)
+ .... .... .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
+ Payload Length: 688
+ Next Header: TCP (6)
+
+This patch allows ip6_make_flowlabel() to be passed more than just a
+flow label and has it extract the part it really wants. This was simpler
+than modifying the callers. With this patch packets like the above become
+
+Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
+ 0110 .... = Version: 6
+ .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
+ .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
+ .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
+ .... .... .... 1010 1111 1010 0101 1110 = Flow Label: 0xafa5e
+ Payload Length: 32
+ Next Header: TCP (6)
+
+Internet Protocol Version 6, Src: 2002:af5:11a3::, Dst: 2002:af5:11a2::
+ 0110 .... = Version: 6
+ .... 0000 0010 .... .... .... .... .... = Traffic Class: 0x02 (DSCP: CS0, ECN: ECT(0))
+ .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
+ .... .... ..10 .... .... .... .... .... = Explicit Congestion Notification: ECN-Capable Transport codepoint '10' (2)
+ .... .... .... 1010 1111 1010 0101 1110 = Flow Label: 0xafa5e
+ Payload Length: 688
+ Next Header: TCP (6)
+
+Signed-off-by: Dimitris Michailidis <dmichail@google.com>
+Acked-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/ipv6.h | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/include/net/ipv6.h
++++ b/include/net/ipv6.h
+@@ -744,6 +744,11 @@ static inline __be32 ip6_make_flowlabel(
+ {
+ u32 hash;
+
++ /* @flowlabel may include more than a flow label, eg, the traffic class.
++ * Here we want only the flow label value.
++ */
++ flowlabel &= IPV6_FLOWLABEL_MASK;
++
+ if (flowlabel ||
+ net->ipv6.sysctl.auto_flowlabels == IP6_AUTO_FLOW_LABEL_OFF ||
+ (!autolabel &&
jump-label-pass-kbuild_cflags-when-checking-for-asm-goto-support.patch
kasan-respect-proc-sys-kernel-traceoff_on_warning.patch
log2-make-order_base_2-behave-correctly-on-const-input-value-zero.patch
+ethtool-do-not-vzalloc-0-on-registers-dump.patch
+fscache-fix-dead-object-requeue.patch
+fscache-clear-outstanding-writes-when-disabling-a-cookie.patch
+fs-cache-initialise-stores_lock-in-netfs-cookie.patch
+ipv6-fix-flow-labels-when-the-traffic-class-is-non-0.patch
+drm-nouveau-prevent-userspace-from-deleting-client-object.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
